# Escalation Rules
URL: /response-workflows/escalation-rules
Type: howto
Description: Define conditions where a workflow should not respond and instead flag the ticket for human review.
Keywords: escalation, human review, do not respond, guardrails
Escalation rules are guardrails that prevent a workflow from responding when a human needs to be involved. They're evaluated before the AI generates a response — if any rule matches, the workflow stops and the ticket is flagged for agent review.

Why escalation rules matter [#why-escalation-rules-matter]

Even the best-configured workflow shouldn't handle every situation. Escalation rules give you confidence that automated responses won't be sent in cases where:

* The financial stakes are too high (large orders, high-value customers)
* The situation requires specialized knowledge (legal, technical, compliance)
* The data indicates something unusual (disputed transactions, fraud signals)
* Company policy requires human review for specific scenarios

How they work [#how-they-work]

Escalation rules are checked against the data fetched by your workflow's connected tools (e.g., Shopify order data). Each rule defines:

* **Field** — what data to check (e.g., order total, fulfillment status)
* **Condition** — how to evaluate it (equals, greater than, contains, etc.)
* **Reason** — why this should escalate (logged for visibility)

Rules are evaluated in order. If any rule matches, the workflow stops immediately — the AI is never called, and the response is never generated.

Available conditions [#available-conditions]

| Condition    | What it checks                     | Example                            |
| ------------ | ---------------------------------- | ---------------------------------- |
| Equals       | Field matches an exact value       | Financial status equals "disputed" |
| Not equals   | Field does not match a value       | Status not equals "delivered"      |
| Contains     | Field contains a substring         | Customer notes contain "VIP"       |
| Greater than | Field is above a numeric threshold | Order total greater than 500       |
| Less than    | Field is below a numeric threshold | Order total less than 0 (refunded) |
| Is missing   | Field is not present in the data   | Tracking number is missing         |

Common escalation rules [#common-escalation-rules]

By order value [#by-order-value]

Escalate high-value orders to ensure a human reviews the response:

| Field       | Condition    | Value | Reason                                 |
| ----------- | ------------ | ----- | -------------------------------------- |
| Order total | Greater than | 500   | High-value order requires human review |

By financial status [#by-financial-status]

Prevent automated responses for disputed or potentially fraudulent orders:

| Field            | Condition | Value    | Reason                                 |
| ---------------- | --------- | -------- | -------------------------------------- |
| Financial status | Equals    | disputed | Disputed orders require human review   |
| Financial status | Equals    | refunded | Already refunded — agent should verify |

By missing data [#by-missing-data]

Escalate when the workflow can't find the data it needs to respond:

| Field        | Condition  | Value | Reason                              |
| ------------ | ---------- | ----- | ----------------------------------- |
| Order number | Is missing | —     | Cannot find order for this customer |

What happens when a rule triggers [#what-happens-when-a-rule-triggers]

When an escalation rule matches:

1. The workflow execution stops — no response is generated
2. The execution is recorded with status "escalation triggered" and the rule's reason
3. If background automation is enabled, an "escalated" tag is added to the ticket so agents can filter and prioritize
4. The ticket remains in the queue for an agent to handle manually

Escalation is visible in the workflow's execution history, so you can track how often each rule fires and adjust thresholds over time.

Tips [#tips]

* **Start conservative.** It's better to escalate too often at first and reduce thresholds as you build confidence. A missed escalation is worse than an unnecessary one.
* **Combine with "when to use" rules.** Escalation rules check data *after* tool data is fetched. If you want to prevent the workflow from running entirely based on ticket attributes (tags, status, channel), use conditions in the workflow's activation settings instead.
* **Review escalation frequency.** If a rule fires on more than 30-40% of tickets, the workflow's "when to use" description may need tightening — it's matching tickets it shouldn't be handling at all.

Related [#related]

* [Conditions](/response-workflows/conditions)
* [Actions](/response-workflows/actions)
* [Progressive Automation](/response-workflows/progressive-automation)