Category

How to Automate Ticket Escalation Across L1, L2, and L3

Updated:

This article explains how to configure a ticket escalation workflow in BoldDesk where ticket Status represents the escalation level (L1 → L2 → L3). As the status changes, the ticket is reassigned to the correct escalation-level agent, while also capturing who handled the ticket at each level using lookup fields.

Use this configuration when:

  • You need escalation levels to be visible directly in the ticket’s Status.
  • You want assignments to move from L1 to L2 to L3 in a controlled way.
  • You want to record the L1/L2/L3 agents on the ticket for tracking and automation.

Escalation allows tickets to automatically move from L1 to L2 to L3 based on resolution status, SLA, or complexity—ensuring faster and more accurate issue handling.

Prerequisites

  • Admin access to configure:
    • Ticket Status values
    • Custom fields (lookup fields)
    • Workflow Automation (Update Ticket Triggers / Auto-assignment rules)
  • Your L1 agents, L2 agents, and L3 agents must exist as Agents in BoldDesk.
  • The ticket form used by agents must support adding custom fields.

Key components used in this workflow

  • Ticket Status (L1, L2, L3): Custom status values represent escalation levels.
  • Lookup fields (L1 Agent, L2 Agent, L3 Agent): Custom fields that store the agents responsible at each level.
  • Update Ticket Trigger rules: Automation rules that run when a ticket is updated (for example, when Status changes).
  • Set Assignee action: Used in automation rules to assign the ticket to a specific agent or a lookup-field value.

Lookup fields can be used as placeholders inside automation actions (including Set Assignee) so the rule can dynamically assign based on the ticket’s field value. For supported actions and lookup-field behavior, see: How to Use Lookup Fields for Approval, Activity & Email Automation.

How the escalation works (high level)

  1. Ticket is at L1 and assigned to an L1 agent.
  2. When Status is updated to L2, the workflow:
    • Stores the current (or intended) L1 handler in L1 Agent
    • Assigns the ticket to the L2 Agent (from lookup field or your routing rule)
  3. When Status is updated to L3, the workflow:
    • Stores the L2 handler in L2 Agent
    • Assigns the ticket to the L3 Agent
  4. The workflow prevents reassignment to agents outside L1/L2/L3 by controlling assignment actions via automation and conditions.

Step-by-Step Instructions

A) Create custom Status values for escalation levels

  1. Go to Admin.
  2. Open Ticket Status customization.
  3. Create (or confirm) custom statuses:
  • Escalate with Pending status category;

    1. Escalate L2
    2. Escalate L3
  • Resolved with Hold status category;

    1. L1-Resolved
    2. L2-Resolved
    3. L3-Resolved
  1. Save the status changes.

Explore more on How to Customize or Create a New Ticket Status. Additionally, if you also need brand-specific status visibility, configure Brand → Status dependency as needed How to Configure Brand-Based Ticket Statuses in BoldDesk.

B) Create three custom lookup fields (Agent type)

Create the following lookup fields in the Ticket module:

  1. Go to AdminTicket Fields (or Custom Fields for Ticket).

  2. Click Add Field.

    Option_to_Add_a_Ticket_Field.png

  3. Create these fields (repeat for each):

    1. Field name: L1 Agent
      Field type: Lookup field (Agent)
    2. Field name: L2 Agent
      Field type: Lookup field (Agent)
    3. Field name: L3 Agent
      Field type: Lookup field (Agent)
  4. Add the fields to the required Ticket Form used by your agents.

  5. Save the field and form changes.

C) Create Agent Groups

Please configure agent groups L1, L2, L3.

D) Create Auto Assignment Rules

1. Auto Assignment – L1 Agent

Trigger – On Ticket Creation

Summary_of_Setting_Assignee_to_L1.png

2. Auto Assignment – L2 Agent (when L1 escalates L2)

Trigger – On Ticket Update

Summary_of_Setting_Assignee_to_L2.png

3. Auto Assignment – L3 Agent (when L2 escalates L3)

Trigger – On Ticket Update

Summary_of_Setting_Assignee_to_L3.png

The rules must be maintained in the following order for the automation to function as intended.

Auto_Assignment_Page.png

D) Create Update Ticket Trigger rules for L1 → L2 escalation

  1. Go to Admin SettingsTicket Automation.
  2. Open Update Ticket Triggers.
  3. Click Add Rule.

1. L1 Agent status changed to Any (Set L1 lookup field)

L1 Agent status changed to Any.png

2. L2 Agent status changed to Any (Set L2 lookup field)

L2 Agent status changed to Any.png

3. L3 Agent status changed to Any (Set L3 lookup field)

L3 Agent status changed to Any.png

4. When status changed to L1 - Set Assignee from L1 Lookup

When status changed to L1 - Set Assignee.png

5. When status changed to L2 - Set Assignee from L2 Lookup

When status changed to L2 - Set Assignee.png

6. When status changed to L3 - Set Assignee from L3 Lookup

When status changed to L3 - Set Assignee from L3 Lookup.png

7. When status changed to L1 – Remove L1

When status changed to L1 – Remove L1 .png

8. When status changed to L2 – Remove L2

When status changed to L2 – Remove L2 .png

9. When status changed to L3 – Remove L3

When status changed to L3 – Remove L3.png

10. When status changed to Solved

When status changed to Solved .png

The update ticket trigger rules must be maintained in the following order for the automation to function as intended.

image.png

Use Cases

Escalate from L1 to L2 with controlled reassignment

  • An agent updates Status from L1 to L2.
  • The L1 → L2 rule runs:
    • Captures the L1 handler in L1 Agent (based on your configured action/logic).
    • Assigns the ticket to the agent stored in L2 Agent.

Escalate from L2 to L3 and preserve prior handlers

  • An L2 agent updates Status to L3.
  • The L2 → L3 rule runs:
    • Sets L2 Agent (if not already set).
    • Assigns the ticket to L3 Agent.

Prevent escalation if the next-level agent is not defined

  • Status is set to L2, but L2 Agent is empty.
  • The rule does not assign (based on conditions), keeping the ticket from being escalated without a valid target.

Troubleshooting Common Errors

Ticket escalated to L2/L3 but did not reassign

  • Confirm the Update Ticket Trigger rule is enabled.
  • Verify the ticket met all conditions (especially “Status changed to L2/L3” and “L2/L3 Agent is not empty”).
  • Confirm the lookup field type is Agent and not a different lookup source.

Ticket keeps getting reassigned repeatedly

  • Add a condition to prevent re-processing (example: run only if L1 Agent is empty when moving to L2, or use a dedicated flag field like “Escalation processed”).
  • Ensure no other automation rule also changes Assignee on the same status change.

Status options (L1/L2/L3) are not visible for some tickets

Frequently Asked Questions

  1. Can I assign the ticket using a lookup field value?
    Yes. Lookup fields can be used as placeholders in automation actions including Set Assignee, so the ticket can be assigned dynamically based on the ticket’s lookup field value.

  2. What trigger type should I use for status-based escalation?
    Use Update Ticket Trigger, because escalation happens when an existing ticket is updated (for example, when Status changes).

  3. Can this setup ensure only L1/L2/L3 agents handle the ticket?
    Yes, if you restrict assignment changes to:

    • Initial routing (auto-assignment) for L1, and
    • Status-based escalation rules (Update Ticket Triggers) for L2 and L3
      Also ensure there are no other rules that assign tickets outside this flow.
  4. Do Update Ticket Triggers run on automation-driven updates?
    Yes. Update Ticket Triggers can activate when a ticket is updated through agent actions, automation rules, or API-driven updates.

  5. What happens if the L2 Agent or L3 Agent field is empty?
    If your rule conditions require L2 Agent / L3 Agent is not empty, the reassignment action will not run. This prevents escalation to a level without a defined assignee.

Related Articles

Was this article useful?
Like
Dislike
Help us improve this page
Please provide feedback or comments
Comments (0)
Access denied
Access denied
Access denied
Access denied

No articles or sections found
No articles or sections found