How SLA Deadlines and Escalation Work in UniAsset

How SLA deadlines and escalation work

An SLA is a promise about how fast work gets responded to. UniAsset turns that promise into a deadline on every work order, and tells you when one is about to be missed.

Requirements

• SLA engine: Odyssey, Cosmos
• Escalation: Orbit, Odyssey, Cosmos
• Roles: Owner, Admin, Manager can configure both

These are two separate features. Escalation notifies people when a job is not moving. The SLA engine computes deadlines and flags breaches. You can have escalation on Orbit without SLA deadlines.

How the deadline is calculated

Two inputs, multiplied:

deadline = base response hours (from priority) × criticality multiplier

Base response hours come from the priority. The defaults:

Criticality multipliers come from the asset. The defaults:

A worked example

An Urgent work order has a 24-hour base window.

• On a Critical asset: 24 × 50% = 12 hours
• On a Medium asset: 24 × 100% = 24 hours
• On a Low asset: 24 × 150% = 36 hours

Same priority, three different deadlines — because the same fault does not carry the same consequence on every asset.

Important This is why asset criticality is worth setting properly. It is not a label; it changes response times.

Planned work orders are the exception. Their deadline is the scheduled date you set, with no multiplier applied.

The deadline is computed when the work order is assigned.

Configuring your own values

1. Go to Dashboard → Work Order Settings, or Settings → Work Order Settings.
2. Set the base response hours for Emergency, Urgent and Routine.
3. Set the criticality multipliers. These are percentages between 10 and 500.
4. Save.

Configuration is per organization and applies to every work order raised after the change.

What happens on a breach

When a work order passes its deadline:

• The work order is flagged as breached.
• A critical notification is raised.
• On Orbit and above, critical alerts are emailed immediately rather than waiting for a digest.

Escalation

Escalation runs on elapsed time, independently of the SLA deadline. It is the mechanism that makes sure a stalled job reaches a human.

Each escalation rule defines:

• A level — first, second, third
• A delay in minutes before it fires
• The roles to notify
• An email subject prefix, so escalation mail is obvious in an inbox

Rules are configured as a chain, typically supervisor → department head → general manager.

Every firing is logged on the work order. That log is both the audit trail and the reason the same level never fires twice.

Common mistakes

Leaving every asset on Medium criticality. The multiplier then does nothing and every deadline is the base figure.

Setting Emergency to one hour with nobody on call. A deadline nobody can meet generates breach noise and gets ignored.

Configuring escalation to notify one person. If that person is on leave the chain stops. Escalate to roles, not individuals.

Expecting escalation to reassign the work. Escalation notifies people. A person still has to act.

Troubleshooting

Work orders have no SLA deadline. The SLA engine needs Odyssey or above. On Orbit, priority is recorded but no deadline is computed.

The SLA panels in Work Order Settings are locked. Same reason — the settings page opens on Orbit because you can operate work orders there, but the SLA panels inside need Odyssey.

A deadline looks wrong. Check the asset's criticality as well as the priority. A Low-criticality asset extends the window by design.

Escalation emails aren't arriving. Immediate email needs Orbit or above. Check the roles named on the rule actually have people in them, and check notification preferences.

A Planned work order has no deadline. Planned orders use their scheduled date. If no date was set, there is nothing to compute.

Related articles

• Work order settings
• Understanding work orders
• Work order lifecycle
• Assigning work orders
• How notifications and alerts work