To make the approval process more flexible, you can separate the set of approvers by making their decisions mandatory and non-mandatory.
A mandatory approver can either approve or reject an approval ticket; a non-mandatory approver can either ignore or reject a ticket.
Flexible approvals are configured via the User-approval workflow activity.
Configure participants
To set up participants, specify approval conditions in the Approval block of your workflow.
To specify mandatory participants, complete the following steps:
Scroll down to the Mandatory Participants tab of the User-approval block properties.
- Fill in either the Employees, Groups or Roles fields or select the Advanced checkbox to add a script.
- Define the approval logic in the Approved When field.
- Click Save.
The table below describes the available options for the Approved When field:
| Choice option | Description |
|---|---|
| Anyone to approve | One of the specified users can approve; the first received approval received causes the activity to complete with an Approved result. |
| Everyone to approve | All the users must approve. If one of the participants rejects the ticket, the approval state changes to Cancelled and the workflow activity ends with a Rejected result. |
| First response from anyone | The first approval received causes the activity to complete with an Approved result. |
| Most answers | The activity will be completed with an Approved result if the number of approvals exceeds the number of rejections. |
| Conditions based on script | Each time a user approves or rejects the ticket, the Script is called to determine whether the activity should be completed. |
If your process requires non-mandatory participants involvement, complete the steps below:
- Select the Non-Mandatory Participants checkbox when configuring your User-approval block properties. The Non-mandatory participants tab appears.
- Fill in the fields.
- You can fill in either the Employees, Groups or Roles fields.
- Select the Consider non-mandatory participants checkbox to make participants able to affect the decision and reject approvals.
- Click Save.
Participant properties
The participant properties differ slightly for mandatory and non-mandatory participant in a particular process or task (for example, Change Request authorization).
| Participants | Participant properties |
|---|---|
| Mandatory | Their reaction is mandatory to authorize a request. When a mandatory approver receives an approval request, they can:
|
| Non-mandatory | Their reaction is not mandatory for authorization. When a non-mandatory approver receives an approval request and if they were involved in the process, they can reject it providing the reason. |
You can configure your approval rules so that the reject from a non-mandatory participant will cancel the approval process. For this, you need to use the specific options in your User-approval block. The table below is an example of how to populate the fields:
| Field | Value |
|---|---|
| Non-mandatory participants | true |
| Employees | John Doe, Jane Doe |
| Groups | HR |
| Roles | hr_manager |
| Consider non-mandatory participants | true |
This combination of checkboxes allows at least one of the non-mandatory participants to reject approval tickets regardless of the approval condition defined in the Approved When field.
Use case
Approval flexibility serves well, for example, in business-cases requiring a case-by-case approach, such as Change Enablement Practice.
When authorizing a change request, mandatory and non-mandatory approvers can take part in the approval process.
Both mandatory and non-mandatory approvers can be classified according to the RACI matrix.
RACI Matrix
| Procedure | Process Manager (for example, Change Manager) | Mandatory approver | Non-Mandatory approver |
|---|---|---|---|
| Approval | A | R | I, R |
The process manager is accountable for the whole process, so they are marked with A in the table.
Mandatory approvers are responsible for the request implementation, so they are marked with R in the table.
Non-mandatory approvers generally should be informed but may be responsible for one or more implementation stages, so they are marked with I and R.
