Transition from old to new workflows

This page is about migrating from old workflows approval processes to the new ones, for documentation on new workflows see New Workflow Engine

IdM 15 is a transitional version that allows both old and new workflows to run concurrently. The transition strategy is as follows:

1. up to IdM 14, approvals are handled by old workflows
2. after upgrading to IdM 15, old workflows are gradually replaced by new ones until there is nothing left that would be approved by old workflows, while all running approvals in new workflows are allowed to complete
3. subsequently, it will be possible to upgrade to IdM 16+, where only new workflows will be supported

The transition can be gradual because:

1. each event (role assignment, change of assigned role, removal of assigned role) is configured separately in new workflows
2. the coexistence of old and new workflows functions as follows:
   1. when an event occurs, it is evaluated whether an approval process exists for that event in the new workflows
   2. if so, an approval process with the new workflow is triggered, and the event is flagged as having been processed by the new workflow
   3. after the new workflow completes (or if it is not defined), event processing continues to the point where the triggering of the old workflow is evaluated
      1. if it is not configured, event processing continues
      2. if it is configured, but the event is flagged as already processed by the new workflow, the old workflow is not triggered and event processing continues
      3. if it is configured and the event is not flagged as already processed by the new workflow, the old workflow is triggered and the event is processed only after it completes

This ensures that at most one approval workflow is triggered for each event, with new workflows taking precedence. As new workflow configurations are added, old workflows are triggered for fewer and fewer events, until after a full transition they are no longer triggered at all because all events are covered by new workflows. At that point, an upgrade to IdM 16+ is possible.

Just as old and new workflows exist side-by-side in terms of execution, they also coexist in the user interface. Approval tasks have their own tabs in the Tasks agenda and sections on the dashboard; old and new workflows also have independent notifications (different topics and templates).

The situation for recertification is specific in that old workflows were not used for their approval; instead, the approval process was implemented differently from the ground up.

In this case, versions of the recertification module up to 14.0.1 use the old way of approval, and this version can also be used with IdM 15. Conversely, from module version 15.0.0 onwards, approval is handled exclusively through new workflows, and this version is only compatible with IdM 15+.

The transition from old recertifications to new ones therefore involves:

1. upgrading to IdM 15+ and Rec 14.0.1
2. letting existing old recertifications finish
3. upgrading the Rec module to 15+
4. configuring the new approval workflow for recertifications

At the same time, there is a fundamental difference. The old way of recertification had two types, where approval was provided either by the manager of the user to whom the role is assigned, or by the guarantor of the assigned role. These were two separate worlds, and each recertification was approved by exactly one of these methods.

With the new approval system, all recertifications share a single common workflow, and who approves can be controlled by conditions within the workflow. It is also possible to use the same workflow as for role assignments. This is what a workflow would look like, for example, where:

1. role assignments with criticality 0 do not require approval
2. role assignments with criticality 1 are approved only by the manager of the user to whom the role is assigned
3. role assignments with criticality of at least 2 are approved by the manager and subsequently by the guarantor of the assigned role

Prior to IdM 15.12.0, under certain circumstances, it could happen that a role assignment triggered approval via the new workflow, and upon its completion, triggered approval via the old workflow as well. The cause was inconsistent handling of database transactions when writing and reading the flag indicating that the event had been processed by the new workflow, combined with a reliance on the assumption that this flag would already be written to the database by the time the decision to trigger the old workflow was made.

In IdM 15.12.0, this bug was fixed using several redundant measures for greater certainty:

1. Setting up specific transactions for both writing and reading the flag.
2. The evaluation of whether an event was processed by the new workflow is now significantly more robust; it is sufficient if any one of the following conditions is met:
   1. The flag is set for the event in memory within the event pipeline.
   2. The flag is written in the database.
   3. An instance of a new workflow exists for the given event.
   4. An approval task from the new approval process exists for the given event.

Any of these conditions signifies that the event was processed by the new workflow, and the old workflow will not be triggered. Furthermore, this evaluation no longer takes place only in the decision processor, but also directly at the beginning of the method that triggers the old workflow, in case its execution is initiated from elsewhere.