The following applies to midPoint 3.6 and later. The schema for the configuration is not stable enough yet, so some changes might occur before 3.6 release.
After the escalation feature has been introduced for approvals, it is now available also for certification campaigns. The configuration is very similar: timed actions are used.
Timed actions in certification campaigns
Main differences between timed actions in certification campaigns and the ones in approvals are:
- There are four kinds of actions: completion, notification, delegation, escalation. For approval workflows, all of them are implemented. But for certification, only escalation action can be currently used. (Completion is meaningless, because certification campaigns do a kind of "auto-completion" - closing work items with the state of 'no answer'. Other actions will be implemented later.)
- For approval work items, deadline is optional, and potentially different for all work items created at a particular approval stage. However, for certification work items, deadline is obligatory and it is the same for all the work items for all the active cases in the given certification campaign stage.This means that, at least in current implementation, the certification work item deadline is fixed. It cannot be changed as part of escalation timed action; contrary to what is usual in the case of approvals.
- In a similar way, the escalation level is the same for all work items for all active cases in the given certification campaign stage.
Here is a sample campaign definition containing automatic escalation:
The escalations themselves are defined on lines 25-50. As defined on line 27, seven days after campaign stage opening ("P7D") the first escalation takes place. The new escalation level is named "Level1", and its effect is that an reviewer of
018fe48d-4952-4f4b-8c0a-b8670ec1748e (line 31) is added (
addAssignees - line 32) to the current one.
Then, as defined on line 39, ten days after campaign stage opening ("P10D"), i.e. three days after this escalation, another one takes place. It is named "Level2", and it replaces all existing reviewers (
replaceAssignees - line 44) with the
42b48a07-e167-4fdc-baca-8eaa13d4eaad (line 43). Exactly as in approvals, the chaining of escalation levels is done using constraining of timed actions to some levels using
escalationLevelTo clauses (lines 48-49).