Overview
When a ticket needs more horsepower — a senior tech, the on-call engineer, your security team, or your systems administrators — you escalate it. PSA has two layers of escalation: automatic, SLA-driven escalation rules that fire in the background, and manual escalation actions that a technician triggers from the ticket with one click. This article covers the manual actions, including the out-of-the-box Escalate to Sys Admins action.
Manual Escalation Actions
Each ticket exposes a set of escalation buttons in its actions. Clicking one runs a configured action against the ticket and records what happened on the ticket's activity log. The built-in action types are:
| Action type | What it does |
|---|---|
| Raise priority | Bumps the ticket up the priority ladder (Low → Medium → High → Urgent), or to a specific configured priority |
| Route to queue | Reassigns the ticket to a specific queue (this is what "Escalate to Sys Admins" uses) |
| Notify on-call | Raises severity and assigns the ticket to whoever is currently on-call (from your on-call schedule), and fires an event |
| Notify security | Flags the ticket as a security incident and lets you open the dedicated security-escalation modal |
Every escalation writes an activity-log entry so you have a clear audit trail of who escalated what, when, and how.
Escalate to Sys Admins (Out of the Box)
Every organization ships with a built-in Escalate to Sys Admins action. It is a route-to-queue action pointed at the Systems Administration queue, and it is seeded automatically — both fresh orgs and existing ones get it without any setup. To use it:
- Open the ticket.
- In the ticket actions, click Escalate to Sys Admins.
- The ticket is routed to the Systems Administration queue for your sysadmin team to pick up. The move is recorded on the ticket.
Because the action is reconciled idempotently and matched on the queue it targets (not its label), renaming it won't cause a duplicate to appear, and it can't be accidentally lost on restart.
Escalating to On-Call
The Notify on-call action looks up your active on-call schedule, finds the current on-call person, raises the ticket's severity, assigns it to them, and emits a ticket.escalated_to_oncall event so downstream tools (alerting, notifications) can react. If no on-call resource is configured, the ticket's priority is still raised and the activity log notes that no on-call resource was found.
Escalating to Security
The Notify security action flags the ticket as a security incident (stamping it with a security incident ID), fires a ticket.escalated_to_security event, and surfaces a hint so you can open the dedicated security-escalation modal to capture incident details. Re-running it on an already-flagged ticket is safe — it reuses the existing incident.
Configuring Your Own Escalation Actions
Admins can add, edit, reorder, activate/deactivate, and delete escalation actions for the org from the Escalation Actions settings under the service desk. Each action has a label, icon, color, an action type, and a small JSON config (for example the target priority or queue). Inactive actions don't appear on tickets.
Automatic vs. Manual
- Automatic escalation rules fire on SLA conditions (for example, a ticket nearing or breaching its SLA) without anyone clicking. They are configured separately.
- Manual escalation actions (this article) are technician-triggered buttons. Both can coexist.
Troubleshooting
"Escalation action not found or inactive." The action was deleted or deactivated. Re-enable or recreate it under Escalation Actions settings.
On-call escalation didn't assign anyone. No active on-call schedule (or an empty rotation) was found. Set up an on-call schedule, then re-escalate.
I don't see Escalate to Sys Admins. It is reconciled on the org automatically; if the Systems Administration queue is missing it is seeded first. Reload the ticket — the action appears once the queue exists.