What is approval escalation?

Approval escalation is what happens when an approval request is not decided within the time it was given: it moves to an upper level or an authorised manager, or is concluded under a rule defined in advance in the workflow. In corporate travel the purpose is to stop one approver's delay from putting the trip, the price and the traveler's plans at risk.

How does escalation work?

Escalation works with two settings: the level's time limit and the rule that applies when the limit runs out. The clock starts when the request reaches a level. If the approver does not decide within that time, the level closes and the request goes where the rule points. At a level with no time limit there is no escalation; the request simply waits for a decision.

Three rules are usually available when time runs out:

• Escalate to the upper level: the request moves to the next level in the workflow.
• Escalate to the company manager: an authorised manager replaces the level.
• Reject: the request is rejected because time ran out, and the traveler applies again with a new choice.

Why consider escalation together with the ticketing time limit?

Fares and seats on flights are valid only for a limited time. If a level's time is longer than that, the option may be long gone by the time approval arrives. So the level time is set together with the ticketing time limit; for requests with a short hold, the approval time must be short as well.

For example, take a request opened for a morning flight where the first level's time runs to the end of the day. If the option's validity ends at noon, waiting makes no sense; the sensible setup is to limit the level time to noon.

Escalation, delegation and reminders compared

These three concepts work against approval delay at different layers. A reminder warns the approver but does not move the request. Delegation widens who can decide when an absence is known in advance. Escalation is the last resort: when time runs out it takes the request from its level.

In the Kurumsal.pro portal no automatic reminders are sent to approvers; delegation and escalation settings are used against delay.

What to consider when setting up escalation

When choosing a rule, think about what happens at the last level of the workflow. When time runs out there, there is no upper level to carry the request, so whether it goes to a manager, is rejected or is treated as expired depends on the chosen rule. If handing over to the company manager is chosen, make sure the manager has time to take every escalation.

Frequent escalation can also be a sign that the problem is not the time setting but the structure: too many levels, the wrong approver type, or no delegation for managers who go on leave.

Example: escalation in a three-level workflow

Take a sequential three-level workflow: manager, department manager and finance. The first level's time has run out and the rule is "escalate to upper level". The request moves to the department manager and the manager's level closes as escalated. If the department manager approves, the request moves on to finance.

If time also runs out at the finance level, there is no upper level to take the request and it moves to "expired". Had the same workflow been built with "escalate to company manager", every level whose time ran out would pass to the company manager; with "reject", the request would be rejected at the first timeout. Which rule suits depends on the company manager's capacity and on whether the company follows a "no decision, no trip" principle.

Approval escalation in Kurumsal.pro

In the Kurumsal.pro portal that your agency offers its corporate clients, the level time and the action when time runs out are chosen by the company administrator in the approval workflow: escalate to the upper level, escalate to the company manager, or reject.

• If the request's expiry (the validity of the cart sent for approval) is sooner than the level time, the approval time is limited to that expiry.
• A request whose expiry has passed is closed, and its owner sees "expired" on the request status screen.
• Timeouts are not processed by a background timer; they are processed when the approvals list, the pending approvals counter or the live feed is opened.
• Escalation is published in the portal as an in-app notification, and the status of levels (escalated, approved, expired) is followed in the approval history.

For all level and time settings see travel approval workflow, and for the general structure of the process see approval workflow.