Skip to content
Help Center
Submit a request Sign in


Configure escalation workflows and verify the complete handoff

An escalation workflow defines the configured response when a case needs additional attention or is ready to return. In Core, a matching Escalated workflow is a prerequisite for an ordinary escalation to be committed. This makes escalation setup part of the actual handoff process—not just an optional notification after someone clicks an escalation button.

At a glance

For: support operations administrators, escalation owners and team leads. Applies to: Supportbench Core.

Start here: Settings → Configuration → Workflows

Agree what escalation should accomplish  ·  Create the matching escalation rule  ·  Write a template that helps a specialist act  ·  Test the agent handoff and the return  ·  Example: a specialist investigation with an accountable return  ·  Troubleshoot escalation setup

Agree what escalation should accomplish

Start with a real support situation: a customer’s production service is unavailable and the first team needs a specialist’s next diagnostic decision. Identify the receiving responsibility, what information must be supplied, who communicates with the customer and what makes the case ready to return. Avoid using escalation merely to move difficult work out of a team’s list.

ElementRole in the process
Escalation criteriaYour operating agreement for when additional attention is needed. These are recommendations and team rules, not universal built-in severity thresholds.
Escalation typeA configured category and supported handoff assistance/scope. Maintain types separately from workflow rules.
Escalation workflowA Case event rule with conditions and actions that determine the configured processing.
Handoff activityThe case-specific evidence, impact, question and next responsibility recorded by the agent.
Customer updateA separate appropriate customer-facing activity; internal escalation details do not replace it.

You need workflow administration permission. The agents who perform the handoff also need the applicable case and escalation permissions. Review queue/agent eligibility, type scope and existing workflow rules before changing routing.

Create the matching escalation rule

  1. Open Settings → Configuration → Workflows. Create a focused rule or edit the existing intended escalation rule.
  2. In Details, choose a name that describes the receiving purpose and review active state and priority. Record the rule’s intended customer/service scope.
  3. On Trigger, select scope Case and event Escalated. For a return rule, use the separate De-escalated event.
  4. Add the supported conditions that distinguish the intended case, escalation type or service situation. Requirements must all match; Conditionals provide an at-least-one group. Verify the chosen fields and values in the current editor.
  5. In Actions, configure the available routing, field changes or notifications appropriate to the handoff. Do not assume that escalation automatically raises priority or selects your preferred team.
  6. Review the event-specific Template Escalation text when used. This is authored text for the supported Escalated/De-escalated Case events, not a selector for an unrelated template ID. Keep prompts useful and remove promises that cannot be made for every case.
  7. Review action order, workflow priority and Stop processing. Save and reopen the rule to confirm the stored configuration.

An ordinary escalation needs a matching rule

When no Escalated workflow matches an ordinary escalation request, the current lifecycle returns without changing the case or creating the escalation activity. A configured type by itself does not establish a matching workflow. Test the full agent operation and verify the saved activity and state.

Write a template that helps a specialist act

Use the escalation text to request useful facts: business impact, affected environment or asset, symptoms and timing, actions already attempted, evidence links, the exact decision needed, current workaround and the next customer update commitment. Make clear which details the agent must complete for the specific case.

A template should prompt judgment rather than manufacture it. “Confirm the customer impact” is useful; a fixed sentence stating that every case is a critical production outage is not. Keep credentials, personal data and irrelevant copied correspondence out of the handoff. Review generated or prefilled text before submitting it.

If responsibility for customer communication stays with a different person from technical investigation, record both responsibilities clearly. Add relevant watchers or use supported collaboration tools deliberately. A queue assignment alone does not tell a specialist which question to answer first.

Test the agent handoff and the return

  1. Choose an approved test case that satisfies the intended conditions. Record its current owner, queue, priority, escalation state and relevant service deadlines.
  2. As an eligible agent, open the normal escalation action, select the intended type if applicable, complete Details and submit the ordinary escalation.
  3. Verify a saved internal activity, changed escalation state and the intended final assignment. Inspect any priority or other field changes caused by workflows.
  4. Repeat with a case that should not match. Confirm that the absence of a matching workflow is handled as expected and does not produce a misleading completed handoff.
  5. Test the intended de-escalation path separately. Review the returned owner and queue behavior using the current escalation guide; do not assume it simply restores every previous field.
  6. Where Escalate back to {name} is offered, test it separately from ordinary Escalate. With the type blank, it offers the most recent eligible historical recipient and reuses that escalation type; selecting a type restricts the return to its history. Verify the escalation state, internal activity, audit and named assignment. Escalation workflows must not evaluate or run on this path, even when their conditions match. General case-update, ownership and watcher handling remain active, with the named owner protected from competing routing. Use ordinary Escalate when you want the standard escalation-workflow path to evaluate matching rules again.
  7. Send or draft a separate appropriate customer update in the test process only when authorized. Confirm that internal escalation content was not treated as a customer email.

Example: a specialist investigation with an accountable return

A recurring equipment restart affects several contacts at the same manufacturer. The escalation rule applies to the intended support area and specialist process. The agent records the affected installation, observed restart pattern, attempted firmware checks and the requested next diagnostic decision. After submission, the team verifies the specialist responsibility and retains an explicit customer update owner.

When the specialist has a reviewed next action, the return includes the result, evidence, remaining risk and who will perform the next customer-facing step. The operational benefit is continuity: the receiving agent can continue without reconstructing why the case was escalated. Track handoff completeness and missed update commitments through your normal review process rather than assuming the workflow guarantees a faster resolution.

Troubleshoot escalation setup

SymptomCheck and correction
No activity or state change after ordinary escalationLook for an active matching Escalated Case workflow and inspect all conditions. The escalation type alone is insufficient.
Owner or priority did not changeConfirm the applicable actions and their supported values; ordinary escalation does not promise either change automatically.
Handoff text is missing or unsuitableReview event-specific Template Escalation text and type assistance separately, then test the agent dialog.
Another workflow undoes the destinationReview priority, Stop processing and later events produced by actions. Test the final case state.
De-escalation routes unexpectedlyInspect the separate De-escalated rule and current return behavior. Confirm an eligible individual receives responsibility.
The customer is unaware of progressRecord and send an appropriate customer update through the normal case reply process.

Was this article helpful?