A Maximo escalation looks harmless in the Escalations application. Pick an object, write a where clause, add a point, attach an action or a communication template, tick Active. In a demo, it works the first time. In a large production estate, the same escalation can quietly become the thing that shows up on the database performance report at the end of the quarter. Maximo escalations are one of the most useful automation features in Maximo Manage, and also one of the easiest to abuse. This piece sets out the design and operating patterns that keep an escalation library fast, safe, and understandable.
The audience is functional analysts and administrators who own the escalation catalogue, and the architects who inherit it during an upgrade to MAS. The point is not to discourage escalations. It is to treat them as scheduled workload against the production database, which is what they are.
What a Maximo escalation actually is
An escalation, once validated and activated, is a cron task instance. It runs on the ESCALATION cron task inside Maximo Manage on a schedule you define. On each run, it evaluates the where clause you wrote against the Maximo Business Object (MBO) you selected in Applies To, walks the matching records, checks each escalation point, and, for records that satisfy a point, executes the associated action group and any communication templates.
Two consequences follow. Every escalation is a scheduled query against production data, and it competes for database resources with everything else. The Repeat setting, the Elapsed Time Interval, and the hidden ESCSTATUS bookkeeping decide whether a record fires the action once, occasionally, or on every cycle for years.
Escalations have been part of Maximo since the early product line, and the underlying pattern has not changed. If the workload keeps growing, that is a design choice, not a limitation of the tool.
The three patterns that cause the pain
Most escalation performance and reliability issues in production trace to a small number of design decisions.
Applies To that is too broad
The Applies To object is the single most consequential field on the escalation form. It decides which table is scanned on every run. An escalation “any contract line asset whose warranty expires in 30 days” written against ASSET will evaluate every asset in the estate on every cycle, then filter. Written against CONTLINEASSET, it evaluates only rows that can plausibly qualify. On an estate with a few million assets and a few thousand contract line assets, that single choice changes the workload by three orders of magnitude.
Pick the narrowest MBO whose rows you actually want to walk, and rely on that MBO’s relationships to reach anything else the action needs.
A where clause that cannot use an index
The CONDITION column on the ESCALATION table holds a SQL fragment that becomes part of a WHERE clause. If that fragment wraps columns in functions, hides date columns in expressions, or joins to tables with no index on the join column, the database ends up scanning the full table every time the escalation fires. On a large WORKORDER or ASSET, that is what produces the “Maximo feels slow at 07:15 every morning” ticket.
Keep where clauses sargable: compare indexed columns to literal or bind values, resolve date arithmetic on the right-hand side, and test the plan in an SQL client with realistic data volumes before activating.
Repeat semantics that are misunderstood
Repeat sits on the escalation point, not the escalation. When Repeat is off, an action fires once per record and Maximo records that in ESCSTATUS so it does not fire again while the record still meets the condition. When Repeat is on, the action fires on every cycle for every record that qualifies. A daily overdue-work-order reminder with Repeat off sends one email per work order per state change. The same escalation with Repeat on can send one email per work order per day, and the mailbox is the least of the concerns: the action group runs against the database each time too.
Repeat should be a deliberate choice with a business owner behind it, not a default.
Design patterns that hold up in production
Narrow the object, then narrow the condition
The escalation catalogue we recommend as a baseline follows two rules. First, Applies To is chosen to minimise the row count the escalation walks. Second, the where clause uses only columns that are indexed on that table, expressed in a form the optimiser can use. This is the same discipline that applies to any operational SQL. It is not specific to Maximo.
Where a supporting index does not exist on a column the escalation genuinely needs, add it under change control. IBM’s Maximo performance best practice notes explicitly call out ESCALATION.condition and its underlying object columns as places where indexing decisions matter.
Prefer Elapsed Time on indexed date columns
Escalation points support an Elapsed Time Interval against a datetime attribute. This is a first-class feature of the escalation engine and is usually more efficient than embedding date arithmetic in the where clause. It also makes the intent obvious to the next person reading the configuration. Use it when the trigger is “N units after some indexed date”.
Choose the action mechanism deliberately
An escalation point can fire an action group, send a communication via a template, or trigger an automation script through a launch point. Each has a cost profile. A communication template that sends a single email is cheap. An action group that runs a series of MBO updates is not, especially when Repeat is on. A script launched from an escalation runs inside the escalation transaction and can hold locks for the duration.
Keep the action light. Move heavy work to a downstream cron task or integration if the volume warrants it. An escalation should decide that something needs to happen; it should not be the place a large business process executes.
Log the ones that matter
The Create Successful Execution Entry setting writes a row to ESCSTATUS on every run. It is off by default because it is not free. For business-critical escalations (SLA breaches, safety notifications, regulator-facing reports) turn it on to get an auditable trail without extra instrumentation. For the rest, monitor the cron task instance status and the standard logs.
Operating an escalation library
The design decisions above are half the work. The other half is running the catalogue over time.
- Catalogue them. Every active escalation needs a named business owner, a documented purpose, and a change record. Inherited escalations with no owner are the first review item.
- Deactivate rather than delete. Deleting loses the history and the schedule. Deactivation is cheap and reversible.
- Review quarterly. Filter for escalations whose last successful execution is old, whose action group no longer exists, or whose communication template points at a mailbox that has moved. Dead escalations accumulate faster than teams expect.
- Route them to the cron bundle. On MAS Manage, the
ESCALATIONcron task should run on the cron server bundle and be disabled on the UI and MEA bundles. Escalations running against the UI JVM is a common cause of interactive latency, and the fix is a configuration change, not a bigger pod. - Promote through Migration Manager. Escalations, action groups, and communication templates are configuration. Move them through environments the same way as any other configuration.
Closing position
An escalation library that is designed narrowly, indexed properly, and run on the right bundle is invisible in operational metrics. One that grew organically for a decade, with wide Applies To objects, unindexed where clauses, and Repeat left on for convenience, is a slow-moving performance and compliance problem. The mechanics have not changed materially since Maximo 6. What changes with the move to MAS Manage on OpenShift is that the cost of bad decisions is more visible, because the workloads are more separable and the platform surfaces them.
Escalations are worth investing time in. Most estates already have the ones they need. The work is in curating what is there.