Flexible Approvals

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 User-approval block of your workflow.

To specify mandatory participants, complete the following steps:

1. Select the Mandatory Participants tab of the User-approval block properties.
2. Fill in either the Employees, Groups or Roles fields or select the Advanced checkbox to add a script.
3. Define the approval logic in the Approved when field.
4. 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 tickets; the first received approval received causes the activity to complete with an Approved result.
Everyone to approve	All the users must approve the tickets. If one of the participants rejects the ticket, the approval state changes to Canceled and the workflow activity ends with a Rejected result.
First response from anyone	The first approval or rejection received causes the activity to complete with an Approved or Rejected result. If one of the participants rejects the ticket, the approval state changes to Canceled.
Most answers	The activity is completed with an Approved or Rejected result depending on which number of tickets exceeds: approved or rejected.
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 a process requires non-mandatory participants involvement, complete the steps below:

1. Select the Non-mandatory participants checkbox when configuring your User-approval block properties. The Non-Mandatory Participants tab appears.
2. Fill in the fields.
   • You can fill in the Employees, Groups or Roles field.
3. Select the Consider non-mandatory participants checkbox to enable the participants to affect the decision and reject approvals.
4. 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: Approve it. Reject it, providing the reason.
Non-mandatory	Their reaction is not mandatory for authorization. When a non-mandatory approver receives an approval request and if they are involved in the process, they can reject it, providing the reason.

tip

It is possible to configure approval rules so that the rejection from a non-mandatory participant cancels the approval process. To do so, 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

note

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.