An escalation in IBM Maximo is a scheduled query that finds records matching a condition and then does something about them: changes a status, assigns an owner, or sends a notification. It is the mechanism that lets Maximo chase a late work order, warn you before an SLA breaches, or flag a preventive maintenance job that nobody has picked up. In 22 years of running EAM and CMMS platforms I have seen escalations save a contract and I have seen them get switched off entirely because they buried a manager in email. This guide walks the anatomy, three worked examples, and the tuning that separates a useful escalation from noise.
The anatomy of an escalation
Every escalation is built from the same parts. Understand these five and you can read or write any escalation in the system.
- Applies To object. The business object the escalation runs against, usually WORKORDER, SR, PM or SLARECORDS. This defines the record set and every attribute the condition and points can reference.
- Condition. A SQL where clause that filters the object down to the records that qualify. This is the single most important line in the whole escalation, and the one people get wrong most often.
- Schedule. How often the escalation runs, expressed as a cron-style interval. Every 15 minutes, hourly, once a day at 06:00, and so on.
- Escalation points. One or more thresholds. A point has an elapsed time attribute (a date field to measure from, such as REPORTDATE or TARGETFINISH), an elapsed value and interval (for example 7 days before, or 2 hours after), plus a repeat flag.
- Actions and notifications. What happens when a record hits a point. An action might change status or run a workflow; a notification sends a communication template to a role, person or email address.
The flow is simple to say and easy to get wrong: schedule fires → condition selects records → each escalation point is evaluated against its elapsed attribute → matching records trigger their actions and notifications. If you are new to the platform, my introduction to IBM Maximo sets the wider context for where escalations sit.
Example 1: SLA response breach warning at 80%
The goal is a warning email when a work order has used 80% of its response target but has not yet been started. You want the warning before the breach, not after, so the team still has time to act.
Configuration:
- Applies To: WORKORDER
- Condition:
status = 'WAPPR' or status = 'APPR'and the work order is still not in progress - Escalation point: elapsed attribute REPORTDATE, elapsed value set to 80% of the response window (if the target is 4 hours, the point fires at 3 hours 12 minutes)
- Notification: template SLAWARN to the assigned owner and their supervisor
The trick is expressing 80% cleanly. If your response target lives on the SLA record rather than being a fixed number, calculate the point against the SLA commitment date and set the elapsed value negative so it fires before TARGETSTART. Test with a record you control before you point it at live data.
Warn early, act once
An 80% warning is only useful if it fires once and stops. Its whole value is buying the team a window to respond. If it repeats every 15 minutes it stops being a warning and becomes background noise, and the one time it actually matters nobody looks.
Example 2: PM due in seven days with no assignment
Preventive maintenance that generates a work order but never gets scheduled to anyone is how compliance slips. This escalation catches PM-generated work orders that fall due within seven days and still have no labour or crew assigned.
Configuration:
- Applies To: WORKORDER
- Condition:
worktype = 'PM' and status = 'APPR' and assignedownergroup is null - Escalation point: elapsed attribute TARGETSTART, elapsed value 7 days, interval before target
- Schedule: once a day, early morning, because a daily cadence matches the seven-day horizon
- Notification: template PMUNASSIGN to the planning group
A daily schedule is deliberate. There is no value in a seven-day-horizon check running every 15 minutes; nothing changes that fast, and a slow schedule keeps the query cost trivial. Whether a PM should even run as an escalation or be handled through workflow is a wider design question I cover in configuration vs customisation.
Example 3: safety-critical work order approaching statutory date
Statutory inspections, pressure vessel checks, lifting equipment certification: these carry legal deadlines. Missing one is not an SLA slip, it is a regulatory event. This escalation escalates in stages as the statutory date approaches.
Configuration:
- Applies To: WORKORDER
- Condition: a safety-critical flag is set and status is not COMP or CLOSE
- Point 1: 14 days before the statutory date, notify the assigned engineer
- Point 2: 7 days before, notify the engineer and the maintenance manager
- Point 3: 2 days before, notify the manager and the site compliance lead, and optionally change status to flag urgency
Staged points on a single escalation are cleaner than three separate escalations, because the condition and object stay in one place. Statutory dates often live in a linked warranty or certification record; if yours do, the join logic in Maximo contracts and warranties is worth reading before you write the condition.
Tuning: keeping escalations out of the inbox flood
The difference between a working escalation and an inbox flood comes down to four settings. Get these right and people trust the alerts. Get them wrong and the whole system gets muted.
- The repeat interval. How long Maximo waits before it will fire the same point at the same record again. Set it to match how fast the situation can meaningfully change, not to the schedule frequency.
- The repeat flag. If a point is set to repeat, it will fire every cycle the record still qualifies. For a one-time warning, leave repeat off so it fires once and never again for that record.
- A condition that excludes already-notified records. The cleanest guard is to have the action set a marker (a status change, a flag, a log entry) and add that marker to the condition so notified records drop out of the next selection.
- An upper bound. Always give the escalation somewhere to stop. A closed status, a completed flag, or a hard date past which the record no longer qualifies.
The classic mistake: no upper bound
The single most common failure I clean up is an escalation with the repeat flag on, a 15-minute schedule, and no condition that ever removes the record. It emails the same manager every 15 minutes, day and night, for a week, until someone finally closes the work order or disables the escalation in frustration. Ninety-six emails a day about one late job trains everyone to ignore the source. Every escalation needs an exit: a status the record reaches, a flag the action sets, or a date it passes.
Operational settings to check on every escalation
Before I switch any escalation on in production I run down this checklist. It catches the performance problems that do not show up in a small test system but bite hard against a live WORKORDER table with hundreds of thousands of rows.
| Setting to check | What to verify | Why it bites |
|---|---|---|
| Schedule frequency vs record volume | Match cadence to how fast the condition can change and how many rows it scans. | A 15-minute schedule against a huge table runs the same heavy query 96 times a day for no benefit. |
| Cron task instance | Confirm which ESCALATION cron task instance runs it and that the instance is active and not overloaded. | All escalations share cron capacity; one slow query can delay every other escalation on that instance. |
| Condition query cost | Run the where clause as raw SQL and read the plan. Watch for full scans, functions on indexed columns, and correlated subqueries. | A poorly written condition on a large WORKORDER table can lock up the cron thread and drag the whole platform. |
| Elapsed attribute is indexed | Check the date column the point measures from carries an index. | Date comparisons on an unindexed column force a scan every cycle. |
| Repeat interval vs schedule | Confirm the repeat interval is longer than the schedule so records are not re-notified every run. | Repeat interval shorter than the schedule means duplicate notifications. |
| Notification recipients resolve | Verify the role, person group or email address resolves to real, current addresses. | A stale role sends alerts into a void, or worse, to someone who left. |
Designing communication templates
A notification is only as good as the message it carries. The most common complaint I hear is "the alert does not tell me anything", and it is usually true: the template says a work order needs attention but not which one. A good template is self-contained.
Every notification should carry:
- The work order number so the reader can find it without hunting.
- The asset so they know what is affected.
- The location so they know where.
- A direct link that opens the record in Maximo, so acting on the alert is one click, not a search.
Bind these with substitution variables such as :wonum, :assetnum and :location so the text fills in per record. For the link, build it from the record key rather than hard-coding, so it survives environment moves. Keep the subject line specific too: "WO 10432 approaching statutory date" beats "Maximo alert" every time.
On translatable templates: keep the wording in the communication template rather than concatenating strings in an action, and hold one template per language keyed to the recipient's locale where your organisation is multilingual. Avoid stitching sentences together from fragments, because word order differs across languages and fragment concatenation produces nonsense once translated. A whole-sentence template with substitution variables translates cleanly; a sentence built from glued pieces does not.
The escalation register and quarterly review
Escalations accumulate. Someone builds one for a project, the project ends, the escalation keeps running. Over a couple of years you end up with dozens, and no one remembers what half of them do. The fix is a register and a review.
Keep a simple register, a spreadsheet is fine, listing every escalation: its name, purpose, applies-to object, schedule, who receives its notifications, and the date it was last confirmed useful. Then review it quarterly. The single most valuable question in that review is: does anyone act on this? An escalation that fires reliably but changes nobody's behaviour is noise wearing a useful costume. Retire it.
In practice a quarterly pass retires two kinds of escalation: the ones nobody acts on, and the ones whose condition drifted out of relevance when a process changed. Both are pure noise, and removing them makes the survivors more credible. When an alert is rare, people respond to it.
A note on independence
I am not affiliated with IBM and receive nothing for mentioning its products. The views here come from hands-on implementation work, and the linked IBM pages are the canonical references so you can check the current behaviour of your own version.
Conclusion
Escalations are one of Maximo's most powerful features and one of its easiest to abuse. Learn the anatomy, write conditions that select tightly and exclude what is already handled, give every escalation an upper bound, design templates that carry the record with them, and review the whole set every quarter. Do that and your escalations stay trusted, which is the only state in which they are worth having. For the authoritative reference on how each setting behaves in your release, see the IBM Maximo documentation and the wider IBM Maximo Application Suite product pages.
Written by Muhammad Abbas
CMMS / CAFM Manager & Enterprise Integration Specialist · 22+ years across ERP, EAM, CAFM and enterprise integration.
Work with me