Legacy Workflows (midPoint 3.x)
|
OBSOLETE
This functionality is obsolete since version 4.0.
It is no longer supported or maintained.
|
|
MidPoint 3.9 or earlier
This page applies to midPoint 3.9 or earlier. Embedded workflow engine was removed in midPoint 4.0 and midPoint is now completely workflowless. If you still need manual processes as part of IDM interactions please see Policy-based approvals and Workflow Integration. |
MidPoint is able to postpone selected actions (for example, role assignment) until they are approved by appropriate authority or authorities. The overall process looks then like this:
-
Alice creates a role assignment to Bob.
-
After receiving the request for role assignment (via "Save" button in GUI), midPoint finds out that assignments of this role have to be approved by Chuck, who is a person (in some way) responsible for this role. Therefore, Alice gets a message that the operation execution will be postponed until approved.
-
In order to get the approval, a new approval process instance is created by midPoint. In its most simple form, the approval process consists of only one step: just asking the approver and obtaining his decision. So, in this case, a work item is created for Chuck, asking him to approve or reject the particular role assignment request. Optionally, a mail notification can be sent to Chuck, letting him know that there’s something for him to do.
-
When Chuck logs in, he can see that he has a work item to resolve. So he opens it, reads it through, and clicks on "Approve" button. (Or "Reject", as he decides.)
-
As Chuck was the only approver, the process instance ends here. The operation is executed, and Bob is assigned the requested role. Optionally, Alice and/or Bob may be notified by mail about the result.
Notes
-
The original operation may contain more changes, not only single role assignment. There are basically two approaches to executing these changes:
-
The default one is such that each of these changes must be approved (or rejected), and after all approvals are in place, the operation is carried out. Modifications that were rejected, are simply left out from the operation. Modifications that do not require approvals (e.g. changing Bob’s name or title) also wait until all approvals are done.
-
Alternatively, each change may be executed as soon as possible, i.e. changes that do not require approvals could be executed immediately, and others just after they are approved.
-
-
The approval process may involve multiple approvers, in many arrangements. E.g. After Chuck approves, there may be a requirement that Dan should approve as well. Or, either one of Chuck and Dan are sufficient to approve. Or, both Chuck and Dan must approve, but in any order (e.g. Dan before Chuck would be OK as well.)
-
Within the process, not only concrete persons might be engaged, but organization units (e.g. "board of directors") or roles (e.g. "security manager") may be as well. (This is not implemented yet - MID-1465)
-
Also, it is possible to specify an approver using an expression - like "the approver is Bob’s boss".
-
As an ultimate level of flexibility, a custom BPMN 2.0 approval process might be used. However, this option should be needed to use in only rare situations.