How to Design an Approval Workflow That Handles Exceptions Without Escalating Everything

The escalation rules were intended to ensure nothing critical got missed. What happened instead: the VP of Operations receives 30 escalation notifications per week. She has stopped reading them. Her direct reports have learned that escalating to her gets no response, so they have started resolving exceptions informally, outside the workflow. The system that was built to govern decisions is now being bypassed because nobody trusts it to route exceptions correctly.

Research compiled across enterprise BPM programs shows that 96 percent of executives who report failed BPM initiatives cite a lack of user buy-in as a primary cause. Poorly designed exception logic is one of the most direct ways to destroy buy-in. When users experience a system that escalates routine decisions to senior managers, generates unnecessary noise, and trains approvers to ignore notifications, the workflow loses credibility. Rebuilding that credibility requires a redesign of the exception logic itself.

The over-escalation problem and why it undermines workflow trust

Over-escalation happens when exception rules are too broad, too sensitive, or too uniformly applied. The typical pattern is a rule that escalates any approval not completed within a defined window to the next management level, regardless of the nature of the request. A $500 travel reimbursement that stalls for 48 hours gets escalated to the same senior manager as a $2 million procurement decision that stalls for 48 hours. The volumes are different, the decision authority requirements are different, and the urgency is different, but the escalation logic treats them identically.

The result is an escalation queue that mixes genuinely critical exceptions with routine administrative delays. The senior managers who receive these escalations either review everything, which is an unsustainable time cost, or triage them selectively, which means critical exceptions get missed in the noise. Neither outcome was intended. Both are direct consequences of imprecise exception design.

What effective exception logic looks like in a well-designed workflow

Effective exception logic routes each exception to the lowest authority level capable of resolving it, at the fastest speed appropriate for its urgency, with the information required to make a decision without additional investigation. This sounds straightforward. In practice, it requires explicitly defining three things before configuring any escalation rules: what constitutes an exception for each process, what determines the severity and urgency of each exception type, and what resolution authority each exception type requires.

An exception is a deviation from the expected process path. Not all deviations are equal. A missing document is different from a policy violation. A stalled approval is different from a rejected request. An unusual spend amount is different from a duplicate submission. Each of these exception types requires a different response, different routing, and different urgency. Treating them all as equivalent triggers for a generic escalation rule is the root cause of over-escalation.

See Kissflow in Action

Take a guided tour of Kissflow to build apps and automate workflows.

Walk Me Through Kissflow

Categorizing exceptions by type, impact, and urgency before building any routing logic

Before configuring a single escalation rule, categorize every exception type your process can generate across three dimensions.

Type: Is this a process exception, meaning a deviation from the expected workflow path? Or is it a policy exception, meaning the request itself falls outside defined parameters? Process exceptions include stalled approvals, missing required documents, and failed integration steps. Policy exceptions include spend amounts above authorized limits, requests from restricted vendors, and submissions missing required justification fields.

Impact: What is the operational or financial consequence if this exception is not resolved within one business day? Within one week? High-impact exceptions are those where delay creates measurable operational disruption, compliance risk, or financial exposure. Low-impact exceptions are those where delay is inconvenient but has no material downstream consequence.

Urgency: Does the exception require resolution within hours, within a business day, or within a standard processing window? Urgency is not the same as impact. A compliance documentation exception may have high potential impact if unresolved over a period of weeks but does not require same-day resolution. An emergency procurement exception may have lower long-term impact but requires resolution within hours because a production line is waiting.

Tiered escalation design: routing each exception to the correct level

Gartner projects that by 2025, 80 percent of companies using BPA tools will rely on them to integrate various business services and APIs. As BPM deployments handle more complex processes, exception routing becomes correspondingly more sophisticated. Tiered escalation maps each exception category to a defined resolution path.

Tier 1 exceptions are process delays without policy violations. A standard approval that has not been completed within SLA. Route to the approver's immediate supervisor with a reminder notification and a 24-hour resolution window. If unresolved, escalate to tier 2. Keep this volume large and the management level low. Most approval delays are caused by workload, absence, or distraction, not by complexity requiring senior judgment.

Tier 2 exceptions involve judgment calls outside standard parameters. A request that falls just above an approval threshold where the requestor is making a case for an exception. A vendor approval with an outstanding risk flag. Route to a designated exception reviewer, typically a senior subject matter expert rather than a general management escalation. These are the exceptions that require specific expertise rather than general authority.

Tier 3 exceptions involve potential policy violations, compliance exposure, or decisions with material financial impact. A spend request that bypasses a required vendor qualification check. A CapEx approval that would exceed a project budget without a formal change request. These are the exceptions that warrant senior management attention. They should represent a small fraction of total exception volume. If they represent more than five percent of exceptions, your tier 1 and tier 2 categorization needs refinement.

Free ebook

The ultimate buyer’s guide to BPM

A comprehensive guide for IT leaders to understand, implement, and scale BPM. Learn how to eliminate bottlenecks, automate workflows, and drive operational efficiency with modern BPM strategies.

Thank you for downloading

Configuring thresholds that reduce noise without missing critical events

Every escalation threshold is a tradeoff between sensitivity and specificity. A threshold set too low generates excessive volume and trains recipients to ignore notifications. A threshold set too high means critical events are not surfaced in time to prevent consequences. The calibration approach that works best is to start with conservative thresholds that you can tighten over time using operational data, rather than starting tight and discovering misses.

For time-based thresholds, use percentile data from your current process to set initial windows. If your current approval cycle averages three business days, a 24-hour SLA reminder and a 48-hour escalation is a reasonable starting point. After 60 days of production data, review the distribution of escalations against outcomes. If the majority of escalations are resolved within minutes of notification, the threshold is set appropriately. If escalations frequently expire before resolution, the window is too short for the actual decision complexity.

For value-based thresholds, anchor to your delegation of authority policy rather than arbitrary round numbers. The threshold at which a different authority level is required should match the documented policy exactly. Any spend amount that requires a different approver than the standard routing is a tier 2 or tier 3 exception by definition.

How Kissflow helps

Kissflow's workflow exception handling is designed to give process owners precise control over escalation logic without requiring code changes. Its conditional branching engine allows each exception type to be routed to a specific resolution path based on configurable criteria: spend amount, document status, workflow age, approver role, or any field in the process data model. Exception rules are defined in the workflow designer by process owners, not developers.

The platform's tiered escalation model supports reminder notifications, primary escalation, and secondary escalation as distinct configurable events with independent timing windows. Escalation notifications include the full request context and a direct action link, so recipients can resolve exceptions without navigating through the platform to find the relevant request. Every escalation event is logged in the workflow audit trail.

For process owners redesigning over-escalated workflows, Kissflow's exception monitoring dashboard surfaces escalation volume by tier, resolution time by exception type, and trends over time. This data supports the threshold calibration work required to reduce noise while maintaining appropriate sensitivity to genuinely critical events.

Frequently asked questions

1. What is the difference between an exception and an escalation in a BPM approval workflow?

An exception is any deviation from the expected workflow path: a missing document, a stalled approval, a request outside standard parameters, or a failed integration step. An escalation is a specific response to an exception that routes the resolution responsibility to a higher authority level. Not every exception should trigger an escalation. Tier 1 process delays should generate reminders to the responsible party before an escalation is considered. Escalation is appropriate when the exception cannot be resolved by the person immediately responsible for the decision.

2. How many escalation tiers should a complex approval workflow typically have?

Three tiers are sufficient for most enterprise approval workflows. Tier 1 handles routine process delays routed to an immediate supervisor. Tier 2 handles judgment calls outside standard parameters routed to a designated expert reviewer. Tier 3 handles compliance exposures and material policy violations routed to senior management. More than three tiers typically indicates an over-complex escalation design that mirrors an organizational hierarchy rather than a decision routing logic. Complexity should serve resolution speed, not replicate org chart structure.

3. How do I prevent exception handling rules from creating an infinite loop in a workflow?

Define a maximum escalation ceiling for every exception path. If a tier 3 exception escalates to the COO and remains unresolved after the SLA expires, the workflow should not attempt to escalate further. Instead, it should notify a designated workflow administrator that the exception has exceeded its maximum escalation path and requires manual intervention. Every escalation rule needs a terminal state that closes the escalation loop, even if that terminal state is a manual override notification.

4. What data should an escalation notification include to give the recipient enough context to act?

An effective escalation notification should include: the request summary with key attributes such as amount, type, and requestor; the exception reason in plain language; how long the exception has been open and what SLA is active; the action required from the recipient; a direct link to the full request record; and the prior approval history if the exception involves a multi-level workflow. The recipient should be able to make a decision directly from the notification without opening the platform and searching for context.

5. How do I handle exceptions in an approval workflow that cross department boundaries?

Cross-departmental exceptions require a designated exception coordinator who has visibility across both departments and the authority or escalation rights to engage the appropriate reviewer in each. Configure the exception routing to notify this coordinator as tier 1 when a cross-departmental exception occurs, rather than routing to one department's management hierarchy and expecting them to engage the other department directly. The coordinator model prevents the exception from getting lost in inter-departmental communication.

6. Can exception logic be configured by a business user without coding in most BPM platforms?

In no-code and low-code BPM platforms, yes. Exception routing rules, SLA windows, escalation tiers, and notification content should all be configurable through a visual workflow designer without requiring developer involvement. If your current platform requires code changes to modify escalation thresholds or routing conditions, that is a direct cost driver for process improvements and a significant reason why exception logic rarely gets calibrated after initial deployment.

7. How do I know if my exception escalation rules are working correctly before going live?

Run structured test scenarios against each exception type defined in your categorization framework. For each test, verify that the correct notification is sent to the correct recipient within the defined window, that the escalation chain triggers correctly when each SLA expires, that the full request context is included in each notification, and that the workflow moves to the terminal state correctly when the escalation ceiling is reached. Document the test results as part of your UAT sign-off criteria so that exception behavior is formally validated before production deployment.