Set the Right Approver
In this exercise you will learn how to replace the approver on an approval task with another approver.
In the Widget company, each site has a parking administrator (and a backup). The parking administrator is responsible for making the parking space reservations and to approve the reservation once the parking space reservation has been done. The parking administrators (and backup) are defined in a UI extension on the Site records, with their email address. The UI extension id for the parking administrator is parking_admin
. (for the backup it is backup_parking_admin
, you will need that one in the next exercise).
You will create this automation rule as a Workflow Template Automation Rule on the ‘Automation’ task template, which is the first task in the workflow template.
Question:
Why not define this automation rule on the approval task when it gets assigned?
Before the automation rule can set the correct approver, the approval task will already be assigned to default approver, and this default approver will have got a notification. In general, it is a best practice to define task reassignments in an automation rule of the predecessor task. An ‘automation task’, which will ‘auto-complete’, should be defined as the first task in a workflow to ensure the approval is set before the approval task is assigned.
So, create a new Workflow Template Automation Rule on the Automation task, with the name ‘Set the Right Approver’. By now, you know most of the logic that is required for this automation rule:
- Execute this action when the automation task gets the status ‘Assigned’,
- Retrieve the site record based on the Site UI extension value,
- Lookup the email address of the parking administrator from the custom_fields on the site record.
Next you need to look-up the person record of the parking administrator. Up until now, you were able to get a record because it was related to a record you had access to. For example, to retrieve the person record of the ‘Requested for’ person, you will first retrieve the request record with workflow.requests[first]
and then get the person record with request.requested_for
. In this case, the parking administrator is not linked to the request, workflow or task. We need another technique to retrieve this person record.
To retrieve unrelated records, these are records that are unrelated to the record for which the automation rule is defined, Xurrent provides the 'find' function. The find function requires 2 parameters: the type of record you are looking for and the search parameter or search index. Hereunder some of the lookup functions that are available: find(person, search_index) find(ci, search_index) find(service, search_index) find(service_instance, search_index) As the search_index, you can always use the internal Xurrent id of the record. But depending on the record type, you have other options. A person record can be found based on the e-mail address, a service or service instance based on the name and a CI based on the label.
To find the person record of the parking administrator you will use the find(person, email_address)
function. This is:
parking_admin |
site.custom_fields.parking_admin |
new_approver |
find(person, parking_admin) |
You need to update the approval task, which is the successor of this ‘Automation’ task. ‘Successors’ is another example of a collection. To get the successor task of the actual task, you will use the following statement:
approval_task |
successors[first] |
Finally, you need to update the approver of the approval task. The actual approval task is assigned to a ‘virtual user’ automation.user@widget.com. This user will be replaced by the parking administrator.
An ‘approval’ is not just an attribute of an approval task. An ‘Approval’ is a record in its own right, and an approval task can have 1 or more Approval records linked to it (like a workflow can have multiple tasks and multiple requests). Each of these approval records has 2 attributes: an approver (a person record) and a status (Assigned, Approved, Rejected, etc.).
In the actions, you will update the first (and only) approval record and set the approver. You already have the person record of the approver. Get the approval record with the following expression :
approval |
approval_task.approvals[first] |
Next, you can add your action:
Update | approval |
Set | approver = new_approver |
And that’s it. Your Automation Rule should look like this:
Test and check how the approval task is set on the approver as defined in the Site records.
- Widget Data Center, Houston: Chris Ball
- Widget Headquarters, New York: Donald Larsen
- Widget Manufacturing, Chicago: Peter Robinson
- Widget Research and Development, Boston: Brendy Cleas