Xurrent Help

Automation Rule Example 6

Escalate Approval Task to Manager

When an approval task is assigned, the workflow does not continue until the approver approves. If the approver has not approved or rejected the task, the workflow manager can decide to escalate by reassigning the approval task to the manager of the approver. In this example the workflow manager wants to accomplish this escalation using automation rules.

The automation consists of 2 parts. The first automation rule reassigns the approval task to the manager of the approver. This automation rule is started by an ‘After delay’ trigger. The delay is defined in the second automation rule. After a delay of 2 days it starts the first rule.

The following sections describe how the workflow manager can define the key parts of these automation rules.
 

Approval Escalation

Trigger

Because the rule needs to be executed after a delay of 2 days, the option ‘After delay’ is selected in the Trigger field.
 

Expressions

The following expressions are defined for the rule so that they can subsequently be used to define the condition for the rule, as well as the actions that it needs to execute:

1. is_assigned
The expression is_assigned specifies that the Status field of the approval task is still ‘Assigned’ (if the status is ‘Rejected’ or ‘Approved’ there is no need to escalate). It is defined as follows:

  • status = assigned

2. approval

The expression approval is added to retrieve approval information. An approval task can have multiple approvers. For each approver an approval record is defined. As this approval task has only 1 approver, the first approval record is to be retrieved. This expression is defined as follows:

  • approvals[first]

2. approver

The expression approver is added to look up the approver of the approval task. The approver is needed in order to look up the approver’s manager. The approval record retrieved in the previous expression is used to get the approver. The approval record consists of the name of the approver and the approval’s status. In this expression the name of the approver is retrieved. This expression is defined as follows:

  • approval.approver

3. request

The expression request is used to look up the first request that is related to the workflow that the approval task belongs to. We need this request to retrieve the name of the product name that is specified in the request, as well as the name of the requester. It is defined as follows:

  • workflow.requests[first]

4. product

The expression product is used to identify the name of the product for which an approval is required. It can be found in the UI extension values of the request. UI extension values can be found in the custom_fields field of the request. The expression can be defined as follows:

  • request.custom_fields.name

5. requester

The expression requester looks up the name of the person for whom the workflow is to be implemented. It can be defined as follows:

  • request.requested_for.name

6. manager

The expression manager looks up manager of the approver. The approver was already defined in a previous expression. The manager can therefore be defined as follows:

  • approver.manager

7. escalated

The expression escalated checks if the approval task was not already escalated. This could have happened, for example, when an escalated approval task was rejected and the workflow manager updated the status back to ‘Assigned’ to ask for approval again. To prevent the task from being reassigned to the manager of the manager of the original approver, the automation rule adds the prefix “Escalation:” to the subject of the approval task (see later). This expression checks whether the subject starts with the text “Escalation:”. If so, the expression ‘escalated’ is true. The operator ‘starts_with’ is available for this check. This can be defined as follows:

  • subject <strong>starts_with</strong> 'Escalation:'

8. subject

The expression subject retrieves the subject of the approval task. This can be defined as follows:

  • subject

9. escalated_subject

The expression escalated_subject defines the new subject for the approval task, when the approval task is escalated. This is done by adding the prefix “Escalation:”. This can be defined as follows:

  • ‘Escalation: {{subject}}’
     

Condition

After the expressions have been defined in the rule, the condition, which needs to be met in order for the rule to be executed, can be set. In this example, two conditions need to be checked. First, the status of the task needs to be ‘Assigned’. Next, the approval task should not already have been escalated. The condition can be defined using the expressions, that are already defined. The ‘and’ operator can be used to make use of more than one expression. In this specific case, however, the escalated expression may not be true, so the ‘not’ operator is also used in the condition. The condition is defined as follows:

  • is_assigned and not escalated

 

There are three actions that need to be executed when the condition is met:

  1. Add a note to the approval task to explain to the manager of the original approver that the task has been escalated
  2. Replace the original approver with the approvers’s manager
  3. Update the subject of the approval task with the "Escalation: " prefix

Update 1

The action that needs to be executed by the rule is the addition of a note in the approval task to notify the manager of the original approver that the task has has been escalated to him/her. Because the automation rule is defined on the approval task, the Update field does not require a value. That causes it to default to the current record (i.e. the approval task).
 

Add note

The required action is ‘Add note’. That provides a rich text field in which the note can be defined. The variables in the note (the name of the manager, the name of the requester, the name of the approver and the name of the product) are already defined in an expression. The expressions are embedded in the rich text surrounded by 2 curly brackets. The note can defined as follows:
 

Dear {{manager}}, {{requester}} was waiting 2 days on approval by {{approver}} for the registration of the {{product}} product in SAP.

Update 2

The second action of the rule needs to replace the actual approver with the approver’s manager. The approval record was already defined in an expression. So the Update field can be set to this expression approval.
 

Set

The approver field of the approval record needs to be set to the manager of the current approver. To do this, the following needs to be specified in the Set field:

  • approver = manager
     

Update 3

The third action is to update the approval task subject by adding some text to it. Because the automation rule is defined on the approval task, the Update field does not require a value. That causes it to default to the current record (i.e. the approval task).
 

Set

The new prefixed subject has been defined in the expression escalated_subject. The update of the subject can therefore be specified in the Set field as follows:

  • subject = escalated_subject
     

Schedule Approval Escalation After 2 Days

Trigger

Because the Approval Escalation rule needs to be executed 2 days after the approver task has been assigned to the approver, the option ‘On status update’ is selected in the Trigger field.
 

Expressions

The following expression is defined for the rule so that it can subsequently be used to define the condition for the rule:

1. is_assigned
The expression is_assigned specifies that the Status field of the approval task is set to ‘Assigned’. It is defined as follows:

  • status = assigned

 

Condition

After the expression has been defined in the rule, the condition, which needs to be met in order for the rule to be executed, can be set. In this example, the status of the task needs to be ‘Assigned’. Since there is already an expression for this, the condition that needs to be true is simply:

  • is_assigned

That is all that needs to be entered in the Condition field of the rule.
 

Delay execution

The action that needs to be executed by the rule is a delayed action. A delayed action consists of two parts. First the duration of the delay is defined in the After field. Next, the rule that needs to be started after the delay is selected in the Start field.
 

After

The delay time must be defined. This can be done in seconds, minutes, hours, days, months are years. In this example the 2-day delay duration is defined as follows:

2.days

Start

Select an automation rule which Trigger field is set to ‘After delay’. In this example the ‘Approval Escalation’ rule is selected as follows:

Approval Escalation

 

Demo Data

This example can be found in the ‘Information Technology – Widget Europe’ account of the Xurrent demo data. It is included in the approval task template of the workflow template ‘Registration of new Widget product in SAP’. To review this example, log into your Xurrent demo instance at Xurrent-demo.com by entering the name and password of the instance. Once you have accessed your instance, select the Xurrent account ‘Information Technology – Widget Europe’. Next, log in as Sandra Huizinga (email address: sandra.huizinga@widget.com and password: Xurrent). When you are logged in as Sandra, you can open the workflow template in the Records console.