IdStory IdM 16.0 - Full version overview

Target audience for this page: administrators and advanced users of the application. Technical details of the upgrade (libraries, deployment) are covered by separate technical documentation.

IdM 16 completes the transition to the new approval engine, which was introduced in IdM 15 alongside the original workflow system (Activiti). The original system has been completely removed in IdM 16 - all approvals now run exclusively on the new engine and are configured in the graphical interface of the application, not by deploying BPMN files and setting configuration properties. The second fundamental change is that IdM 16 supports PostgreSQL only.

1. Settle all running approvals of the old (Activiti) type. Let the approvers finish their tasks, or cancel the requests. After the upgrade, such requests would remain permanently in the "In progress" state. Approvals already running on the new engine continue after the upgrade without interruption.
2. PostgreSQL. If you run IdM on MS SQL, the database must be migrated to PostgreSQL before the upgrade. The embedded database for the first start is no longer available.
3. Configure approvals using the new approval engine. The approval configuration from IdM 15 (role criticality mapped to workflows in the configuration, the helpdesk/manager/security steps) is not migrated. However, the complete version of the new workflow engine has been available since IdM 15 - the recommended approach is therefore to migrate fully to the new approval processes while still on IdM 15; the upgrade preserves that configuration.
4. Map out synchronizations with a custom workflow. Synchronizations that had a custom workflow selected for a situation (Linked / Unlinked / Missing entity / Missing account) will only perform the standard action after the upgrade - the custom behaviour has to be converted into a script (see News).
5. Export the approval history if you need it for evidence. The history of approvals performed by the old system (who decided, when and how) will no longer be available in the application - the data remains only in the database (the act_hi_* tables). Prepare your audit outputs before the upgrade.

For the four synchronization situations, a script is now selected instead of a workflow (the new Synchronization script category). The script runs instead of the standard action for each processed item and has the complete context available (the account, the entity, the attributes, the synchronization configuration); it can invoke the standard action itself. Two sample scripts ship with the product:

• syncActionExample - a sample script (performs the standard action),
• syncRoleLdap - a full replacement of the former workflow for synchronizing roles/groups from AD/LDAP (role catalogue, membership, role assignment), configured by the same idm.pub.acc.syncRole.* properties as before.

A script used in a synchronization cannot be deleted by mistake - the application blocks the deletion and lists the synchronization and the system where the script is used. In the synchronization log, items handled by a script are shown with the new result type "Script executed".

Limitation: the script runs synchronously inside the synchronization run - unlike a workflow, it cannot include a human approval step.

• Writing logs into the database is non-blocking - a problem with database logging no longer slows down or stalls the application (under extreme load some records in the log agenda may be dropped; the file logs are always complete).

All approval logic is now driven solely by the new approval engine. All configuration is now done directly in the IdM GUI, in Settings → Workflows and Settings → Approval processes. The full documentation of the new approval engine can be found here: New Workflow Engine.

IdM 16 contains predefined approval processes equivalent to the old approval flow; they can be used as a starting point for the configuration, or used to make the transition between versions easier.

• The configuration properties from IdM 15 (idm.sec.core.wf.role.approval.*, idm.sec.core.wf.approval.*, idm.sec.core.wf.notification.* and others) have no effect in IdM 16, even though they are still visible in the configuration.
• The Criticality field on the role detail does not trigger any approval on its own - it is evaluated as a condition inside a workflow or as a condition of an approval process.
• The Approve role removal checkbox on the role detail currently has no effect - approval of role removal is enabled by creating an approval process for the "assigned role removal" event. Removing this checkbox is planned for a later IdM 16 version.
• The new workflow engine supports changing approval processes while the application is running - definitions are versioned automatically and an approval process that has already started is always finished with the original workflow version.
• IdM 16 supports only the recertification module that uses the new approvals (see Recertification (IdM 15+)).
• Workflow definitions can be imported/exported (IdM 16.1+).

• The Tasks menu has two tabs (Tasks to approve (WF), All tasks (WF)) and requires the APPROVALTASK_READ permission (the default userRole role grants it). Custom roles built on the old WORKFLOWTASK_* permissions have to be adjusted - the old permission no longer grants access to anything.
• The approver has two decisions: Approve / Reject. The "return to requester" option from the old system does not exist - a rejected request has to be submitted again. By default, a justification is mandatory when rejecting (the idm.pub.workflow.task.note.required property). We expect the "return the request" functionality to come back in a later IdM 16 version.
• Bulk approve/reject actions and manual task delegation are available; the task detail shows notes from previous approval rounds and the delegation history.
• If the requester is one of the approvers of a step, the task is approved automatically. This behaviour is now global; it can be turned off using idm.sec.core.processor.approval-task-autoapprove-by-implementer-processor.enabled=false.
• If no approvers are found for a given approval step (for example they are disabled identities, or none are defined), the approval task falls to the holders of the superAdmin role, to prevent requests from being completed without approval by mistake.

• The "new task to approve" e-mail, the bulk summary and the reminders of open tasks work as before (the same templates and topics).
• E-mails tied to the old approval system are no longer sent:
  • the notification about a task of the old type (replaced by the new notification about an approval task assignment)
  • the "request has been executed on the systems" e-mail to the requester/applicant (replaced by the e-mails about the request result and account provisioning, available since IdM 15)
  • the e-mails about approval/rejection of a role definition change (no replacement)

The corresponding topics are still visible in the notification configuration, but they have no effect; they will be removed in one of the following IdM 16 versions.

• Create the approval processes (at least for assigning/changing/removing roles) - until then, role requests go through without approval.
• Synchronizations: find the configurations that used a workflow (the old values remain in the *_action_wf columns of the sys_sync_config table) and set a script for them.
• Delegations: go through the Delegations agenda - delete the records with an empty type (formerly "by manager") and create them again with the Default delegation for all tasks type.
• Scheduler: remove the task for deleting workflow history; for the HR processes (contract start/end/exclusion) clear the "Workflow definition" parameter - with the parameter filled in, the task finishes "successfully" but processes nothing.
• Requests: check the requests agenda with the filter set to the "In progress" state - cancel any leftovers from before the upgrade with the Delete bulk action. Check the event queue as well (Audit → Events).
• Permissions: in custom roles, replace WORKFLOWTASK_* with APPROVALTASK_*.
• Configuration: if you set idm.pub.core.workflows.wfengine.enabled=false in IdM 15, delete the property - otherwise the approval task dashboard is not displayed. The dead spring.activiti.* and idm.sec.core.wf.* properties can be deleted.
• Users: inform them that the old tabs and the links in old e-mails no longer work; they will find their tasks in the Tasks menu.

1. ⚠️ System export/import does not transfer the scripts of synchronizations. When transferring a system configuration between environments, the action script settings of the synchronization situations are silently lost (the import finishes successfully). Workaround: after every import, check and set the scripts again on the Synchronization tab of the target environment.
2. There is no overview of running workflow instances. The progress of an approval can only be followed through the task list (the "Approval process id" filter) and the notes of the approval rounds; a graphical view of the process run is not available yet.
3. Transferring workflow definitions between environments (export/import) is not supported yet - a definition has to be created manually in the target environment. The feature is being prepared.
4. Administrators may see a "WF process" link on request details pointing to a removed page (error 404). The link will be removed/fixed.
5. Items with no effect remain in the configuration and code lists (the topics of the old notifications, the idm.sec.core.wf.* properties, the WORKFLOWTASK permission) - they will be cleaned up gradually.

Java 21, Spring Boot 4 / Spring Security 7, Hibernate 7, Tomcat 11, Jackson 3, Groovy 5; database PostgreSQL only. No visible impact for end users; for operations it mainly means a new version of the application server and the PostgreSQL requirement.