Automation scripts have been part of Maximo since 7.5. They let you extend behaviour with Jython or JavaScript without touching the Java stack, which is why functional teams like them: you can ship a fix or a tweak without waiting on a full product build.
The downside shows up a few years in. A live system often ends up carrying dozens, sometimes hundreds, of scripts from projects, tickets, and one-off changes. A lot of them have no description. Some step on each other. A few add latency on every save. The author may have left years ago. The script is still there, firing on events nobody remembers defining.
That is rarely a tooling failure. It is governance.
How sprawl happens
The pattern is familiar. Implementation delivers a tidy set of scripts with clear intent. After go-live, support adds more for defects and small enhancements. Later, someone drops in another script because it was faster than checking what already existed. Nothing gets removed, because nobody wants to be the person who broke production.
You then see:
- Several scripts on the same object event, interacting in ways nobody mapped.
- Logic duplicated across scripts, workflows, and escalations.
- Disabled scripts filling the Automation Scripting application.
- Save paths that chain through scripts never designed to run together.
Naming that survives contact with reality
A naming convention costs almost nothing and makes large estates legible. Four parts work well:
- Object: the MBO (WORKORDER, ASSET, PO, and so on).
- Event: how it runs (SAVE, INIT, VALIDATE, ACTION).
- Purpose: a short label (AUTOAPPROVEFLAG, LOCSYNC).
- Sequence: a numeric suffix when more than one script shares the same object and event, so order is explicit.
Examples: WORKORDER_SAVE_AUTOASSIGNCREW_01, ASSET_INIT_SETREADONLYFIELDS_01.
Anyone skimming the list can see what fires when, without opening code. You can also export a sensible inventory, which is painful when everything is called Script1 or FixForTicket4532.
Use the same idea for launch points, with an LP_ prefix.
Picking the right launch point
Object launch points run on MBO lifecycle: init, validate, save, after-save. Use them when the logic must run on every change, whether the change came from the UI, integration, workflow, or another script.
Attribute launch points run when a field changes. Good for light field logic; bad for heavy work on every keystroke in the UI.
Action launch points tie a script to an action you call from workflow, escalations, or the toolbar. Use these when the job should run only when someone (or something) explicitly triggers it.
Custom condition launch points feed workflows, conditional expressions, and data restrictions.
The usual mis-step is hanging conditional logic off a save event when an action called from the workflow would be clearer. Save hooks that only matter after approval should usually be actions, not “if status equals…” blocks on every save.
Document inside the product
At minimum, capture in the script description (where Maximo expects it):
- What business problem it solves, in a sentence or two.
- Who wrote it, when, and the change or ticket reference.
- What else it depends on (other scripts, workflows, config).
- Launch point variables and bindings.
If that lives only in a spreadsheet, the spreadsheet wins until the day it stops being updated. After that, every new consultant burns hours reverse-engineering or working around the unknown.
Treat promotion like code
Scripts run in the app server with full API access. A bad one can corrupt data, loop, or slow every user. A proportionate process:
- Build and unit test in non-production.
- Peer review from someone who scripts regularly: errors, performance, clashes with existing scripts.
- Functional sign-off with the business, including edge cases.
- Move to production via Migration Manager or a documented path. Avoid editing production scripts by hand unless you have no alternative.
MAS Manage uses the same Automation Scripting model, so the same discipline applies after you migrate.
Performance
Two hundred milliseconds on a save is nothing in a single-user test. With hundreds of planners saving, it is a problem.
- Prefer MBO relationships already in context over extra MBO fetches.
- On save, check whether the attribute you care about actually changed before doing work.
- Be wary of loops over large sets inside save paths; escalations or scheduled work may fit better.
- Map chains: updating a related MBO can fire attribute scripts there, which fire more scripts. Draw it once on paper if the behaviour feels mysterious.
When not to script
Maximo already has conditional expressions, workflow, escalations, domains, and validation rules. Script when those are not enough, not because scripting feels quicker this afternoon.
Before you add one, ask if the requirement fits one of those first. Standard config is easier for the next person to find and change than buried Jython.
Teams that work with experienced Maximo implementation partners usually agree decision rules up front so script count stays under control.
If you are already under water
Start with an inventory: export scripts and launch points, group by object and event, mark active versus disabled, tie each to a requirement if you can.
You will find redundancy, dead code, conflicts on the same attributes, and gaps where nobody wrote down why something exists. Cleaning that up before a move to MAS pays back in upgrades and support calls.
What “good enough” looks like
You do not need a committee for every line. You need a naming standard, documentation in the tool, a promotion path, and a periodic review so the estate does not rot in silence.
Scripts are configuration. They deserve the same care as any other change you would defend in an audit.