Policy Reminders and Escalations

When a request is submitted on a data object that has an approval or a commit policy enabled on it, notification emails are sent to the invitees to approve or commit the request. You can also configure the policy so that reminder and escalation emails are sent if an invitee does not take action on a request or if an escalation is needed.

Note:

Reminder and escalation emails are only sent if you have configured these settings in the policy.

Reminders

After a request is submitted and notifications are sent to invitees, reminder emails can be sent if an invitee has not taken action after 24 hours. You can specify how many reminders will be sent before the request gets escalated. See Creating and Enabling Approval Policies or Creating and Enabling Commit Policies.

Escalations

There are two scenarios in which requests are escalated for resolution:

• Timeout: When an invitee has not responded to the number of reminder emails that you specified in the Approval Escalation or Commit Escalation field when you configured the policy.

  Note:

  If escalation is set to zero, requests will not be escalated for timeouts.
• Deadlock: When there are not enough policy groups or users available to satisfy a policy requirement. For example, if a user has been removed from a group and there aren't enough remaining users to satisfy the Total Required setting for that policy, the request is deadlocked.

In both scenarios, the request is escalated to users that have Data Manager permission to the data objects in the affected policy, and notifications are sent to those users so that they can intervene and resolve the timeout or conflict.

Note:

Because the Owner permission includes the Data Manager permission, requests are escalated to users with Owner permission on the data objects as well.

After a user with Data Manager permission takes action on the request, the normal request workflow is resumed.

For example, suppose you have a serial approval policy in which someone from Accounting has to approve, then Barry, and then Jane. A user in Accounting approves the policy, but Barry is out of the office and is not available to approve the request. In this case, after the reminder emails are sent to Barry, the request is then escalated to users with Data Manager permission to the data objects in the request. After one user with Data Manager permission approves the policy, it then moves to Jane for her approval.

Note:

If a request is escalated multiple times, a user with Data Manager permission has to approve the request only once.

If a request contains items that are affected by multiple approval policies and one of the policies is escalated, the other policies are not affected. For example, if a request has items from an Account dimension that has a policy that is escalated after five reminders and items from a Cost Center dimension that has a policy that is escalated after two reminders, after the second reminder the request is escalated to users with Data Manager permission on the Cost Center dimension only. Users with Data Manager permission on the Account dimension will not receive escalation notices until after the fifth reminder is sent.

Handling Out of Office Status for Approvers and Committers

Approvers and committers can mark themselves as out of the office to take themselves out of the request workflow. (See Setting Your Preferences). This status is handled as follows:

• Approvers and committers who are out of the office are still invited to approve requests. However, they are not included in the remaining approvers or committers count for the policy.
• If the remaining approvers or committers are not enough to satisfy the policy, the request is automatically escalated to a user with Data Manager permission to break the deadlock.
• The out of office approver or committer is still invited to approve or commit the request and can take action on it when they return to the office.