Auto-Escalating Approval Requests

When an approval request is not approved, rejected, or reassigned within the allotted time, it can be automatically reassigned to a new approver so the approval process can continue.

Note:

Auto-escalation is enabled for sub-process approval rules only. Do not set up auto-escalation on child process approval rules. For example, if an approval rule set up on a child record object (such as a line item or an agreement line item) is used as a child process, then entries in that approval rule are not auto-escalated.

Once an approval request is created, the system uses the expected time-to-complete value (days and hours) to determine when to auto-escalate the approval request. A background service periodically checks the status of approval requests and when one is flagged for exceeding that time, it triggers auto-escalation. Auto-escalation is triggered at the approval step level. If you do not want to wait for auto-escalation, you can manually escalate approval requests from the approvals related list for the object under approval. Auto-escalations can take one of two paths, single-step or multi-step, depending on the auto-escalation assignee type.


Single-step	After an approval is auto-escalated to the next user, if that user does not act on the approval in the designated time, the approval request is auto-escalated to the backup admin user. For example, if the auto-escalation assignee type is Role, and you have a "territory manager" role with three users assigned to it, the auto-escalation is assigned to the first active user assigned to that role. If that user does not decide on the request in time, the request is sent to the backup admin user. Single-step assignee types are: backup admin user, queue, related user, role, rule, and user. When the assignee type is queue or backup admin user, there is no delegate user. Note: If you select rule as an assignee type, the approval request is sent only to the first user that satisfies the filter criteria in the approval rule. If you have multiple approvers in a sequence, only the first approver is selected and assigned.
Multi-step	An auto-escalated request can move among multiple users for that assignee type before being sent to the backup admin user. For example, if the auto-escalation assignee type is "user delegated approver", the initial auto-escalation sends the approval request to that user's delegated approver, configured in their user account. If the request is not decided in time, the request is auto-escalated to the delegated approver of the user who received the auto-escalated request. This continues until that assignee type is exhausted, then it is sent to the backup admin user. Multi-step assignee types are: user approval matrix next approver, user delegated approver, and user manager.

Auto-Escalation Limitations

There are limits on the number of time-based rules per hour. The limits are as follows:
- Enterprise Edition = 500
- Developer Edition = 50
- Unlimited Edition = 1,000

Auto-escalation cannot be defined for rules used as child processes.
For an assigned request, if the expected completion time is greater than the current time, the request is auto-escalated.
If an assignee in a standard step is a rule, the assignees in the rule cannot have auto-escalation values.

Configuring Auto-Escalation

You must configure the following for this feature.


Flow rules	Flow rules supersede the deprecated Workflow Rules. These rules contain time triggers that cannot be included in a managed package and must be manually configured to provide this feature's time-based framework.
Auto-escalation reminders	Reminder emails can be sent to approvers to let them know that approval requests not approved, rejected, or reassigned will be automatically escalated.
Approvals system property	The Enable Approval Request Auto-Escalation flag indicates to the system to use auto-escalation per the configured settings.
User approver settings	Configure these settings to auto-escalate to the user-delegated approver or user-manager assignee types.
Email templates	These templates are used to generate the email notifications that are sent to the auto-escalation approvers. The system comes with escalation templates for opportunities, and term exceptions. For other objects that use approvals you must create custom templates. Attention: You must create custom email templates to use attachments with your emails. Default templates do not support attachments.
Global escalation options	These options must be configured so that if no escalation options are configured for an approval process step, the escalation process can fall back to determine when escalation begins, involving whom.

By completing this configuration, you can use auto-escalations and they will work according to the configuration; however, you will be able to override some of the options later when creating approval processes.

Setting Up Auto-Escalation Flows

To set up the auto-escalation flow:

Click the gray gear icon in the top right corner to enter Setup.
In the left navigation bar, go to Platform Tools, open Process Automation, and click Flows.
Click the New Flow button, which raises the New Flow panel.
Select Record-Triggered Flow and click Createto raise the Configure Start screen.
Select the Approval Request object.
From the Configure Trigger screen, select A record is created or updated.

Set entry conditions:

In Condition Requirements, select Custom Condition Logic is Met.
In Condition Logic, enter: 1 AND 2 AND 3 AND 4 AND 5 AND 6 AND (7 OR 8).

Add and enter the following rule criteria:


Field	Operator	Value
Active (Apttus_Approval__Active__c)	Equals	True ($GlobalConstant.True)
Auto Escalate (Apttus_Approval__AutoEscalate__c)	Equals	True
Can Escalate (Apttus_Approval__CanEscalate__c)	Equals	True
In Escalation (Apttus_Approval__InEscalation__c)	Does Not Equal	True
Escalated To Highest Level (Apttus_Approval__EscalatedToHighestLevel__c)	Equals	False
Date Escalated (Apttus_Approval__DateEscalated__c)	Is Null	False ($GlobalConstant.False)
Approval Status (Apttus_Approval__Approval_Status__c)	Equals	Reassigned (text)
Approval Status (Apttus_Approval__Approval_Status__c)	Equals	Assigned

In the "When to Run the Flow for Updated Records" section, select the Only when a record is updated to meet the condition requirements radio button.
In the "Optimize the Flow for" section, select Actions and Related Records.

Click Done. The successful exit state looks like:

With the auto-escalation flow thus established, you must add and configure scheduled path details.

To add scheduled paths

With the auto-escalation flow thus established, you must add and configure scheduled path details. Add a scheduled path to the flow map as follows:

Click the Add Scheduled Path (Optional) button, raising the Configure Scheduled Paths window.
In the scheduled path details section, enter these values:
- In Path Label, enter Time Trigger. The API Name field auto-populates with the Time_Trigger name.
- In Time Source, select Apttus_Approval__Approval_Request__c: Date Escalated from the pull-down menu.
- In Offset Number, enter 0 (numeral zero).
- In Offset Options, select Minutes After.
Do not expand the Advanced entry. Click Done.

The successful exit state looks like:

You can now add an element to the time-trigger flow.

To add a time-trigger element

You can now add an element to the time-trigger flow.

On the right (Time Trigger) fork of the Flow map, hover over the disk under Time Trigger until it changes into a plus sign:
Click the plus-sign button to raise the Add Element pop-up.
Scroll down and select Update Records, raising the New Update Records window.

In the New Update Records window:

Enter a label in the Label field. In the present example, this is Field Update.
The API Name field auto-populates with "Field_Update". This field names the element's GUI icon.
Enter a descriptor in the Description field.
This field defines the hover text for the element's GUI representation. In the illustration below, this is "ScheduledPath1Update".
In the How to Find Records to Update and Set Their Values section, select the Use the approval request record that triggered the flow radio button.
In the Set Filter Conditions section, select None—Always Update Record from the pull-down menu.

In the Set Field Values for the Approval Request Record section, use the + Add Field button to add entries, then select and enter the following values:


Field	Value
Apttus_Approval__CanEscalate__c	False($GlobalConstant.False)
Apttus_Approval__DateEscalated__c	blank
Apttus_Approval__InEscalation__c	True($GlobalConstant.True)

Click Done.
A successful exit state resembles:
Click the Save button.

To enable the approval systems property

Go to Build > Develop > Approvals System Properties and click Manage.
Beside System Properties ,click Edit.
Select Enable Approval Request Auto-Escalation and click Save.

This enables auto-escalation. Set up the required email templates and global escalation options.

To select Approver Settings

Go to Administration Setup > Manage Users > Users and select Edit for the appropriate user.

Scroll to the Approver Settings section and complete the following:


Option	Description
Delegated Approver	This can be any user, but be sure they can access the same objects as the user for whom they may receive delegated approval requests.
Manager	The user's manager.
Receive Approval Request Emails	If you select Never, the user will not receive email notifications that an auto-escalated approval request has been sent to them. They will receive notifications with any other option.

Click Save.

You can now select User Delegated Approver and User Manager as auto-escalation assignee types for this user.

Repeat this task for other users, as no batch update action is available for these settings.

Email Templates for Auto-Escalation

By default, the Conga Approvals Management package contains escalation templates for Opportunities, Agreements, and Term Exceptions.

These templates can be used as-is out of the box; however, you can also configure bespoke templates for your organization. See Setting Up Email Templates and Alerts and the Appendices for more details.

Auto-Escalation Behavior

This section outlines the behavior for auto-escalation in approval rules.


Scenarios	Behavior
Auto-escalation is active. Expected hours to complete = 1 (or X, where X is a numeric variable). Auto-escalation assignee is "User".	An approval request is escalated to the "User" assignee if the original assignee does not act within 1 or X hours of the approval request's generation. If the escalated User assignee does not take action in 1 or X hours, the request is escalated to the backup admin. This behavior applies to all other assignee types.
Auto-escalation is active. Expected hours to complete = 1. Auto-escalation assignee is "Delegate Approver".	An approval request is escalated to the Conga delegate approver assignee if the original assignee does not act in 1 or X hours of the approval request's generation. If the escalated assignee does not take action in 1 or X hours, the request is escalated to the backup admin. The approval request remains with the escalated assignee for the remaining life of the request.
Auto-escalation is active. Expected hours to complete = 1. Auto-escalation assignee is "Approval Matrix".	An approval request is escalated to the first assignee in the approval matrix if the original assignee does not act in 1 or X hours of the approval request's generation. If the first assignee does not act within one hour, the request is escalated to the next assignee in the approval matrix chain. The escalation process continues until the last assignee in the approval matrix is assigned the request. If the last assignee takes no action, the approval request is reassigned to the backup admin. Note: The request ascends the approval matrix at the interval defined in the auto-escalation setup. For example, after every one hour that no action is taken on the approval request, the request is escalated to the next assignee.
Auto-escalation is active. Expected days to complete = 1 (or X, where X is a numeric variable). Auto-escalation assignee is "User".	An approval request is escalated to the assignee "User" if the original assignee does not act in 1 or X days of the approval request's generation. If the escalated assignee does not take action in 1 or X hours, the request is escalated to the backup admin. This behavior applies to all other assignee types.
Auto-escalation is active. Expected days to complete = 1. Auto-escalation assignee is "Delegate Approver".	An approval request is escalated to the Conga delegate approver assignee if the original assignee does not act in 1 or X days of the approval request's generation. If the escalated assignee does not take any action in 1 or X hours, the request is escalated to the backup admin.
Auto-escalations is active. Expected days to complete = 1. Auto-escalation assignee is "Approval Matrix".	An approval request is escalated to the first assignee in the approval matrix if the original assignee does not act in 1 or X days of the approval request's generation. If the first assignee does not act within one day, the request is escalated to next assignee in the approval matrix chain. The escalation process continues until the last assignee in the approval matrix is assigned the request. If the last assignee takes no action, the approval request is reassigned to the backup admin. Note: The request ascends the approval matrix at the interval defined in the auto-escalation setup. For example, after every one day that no action is taken on the approval request, the request is escalated to the next assignee.

Best Practices

Escalation time should be no less than one day.

Whenever escalation is set up for a specific user, role, or queue, follow the same format at every step.

If we configure a rule entry where Jim is an assignee, Mark is the escalation assignee, and the escalation time is set to one day, if Jim does not respond to a request in a day, it is escalated to Mark.

If there is any other step (standard or subprocess step) that also has Jim as an assignee, that step should also have Mark as the escalation assignee and an escalation time of 1 day.

This is also a system limitation. If a user has auto-escalation in one step, no auto-escalation in another step, and enables consolidated approvals, then escalation cannot work. In this scenario, an escalation request goes on hold.

Consolidation and Auto-Escalation Behavior

If consolidation is enabled (approvals or notifications), consolidation always takes precedence over escalation. For example, the escalation timer does not start until all requests are available (if a user has multiple requests, at least one must be in the assigned status).

Reassign and Auto-Escalation Behavior

Take, for example, an approval request that has Jim as a primary assignee, Mark as the auto-escalation assignee, and the request scheduled to escalate one day after assignment. After some time, the request is reassigned to Karl. This does not impact the escalation time. If Karl takes no action, the request escalates as expected (that is, it escalates one day after it was assigned to Jim.)

Ad Hoc Approver and Auto-Escalation Behavior

If an ad hoc approver is added, the end user does not have an option to add escalation value to the ad hoc assignee.

Auto-Approve/Auto-Complete and Auto-Escalation Behavior

Do not set up escalation on auto-approved steps.

Conga Product Documentation

Welcome to the new doc site. Some of your old bookmarks will no longer work. Please use the search bar to find your desired topic.