Configuring and Administering Maximo Manage 9: Scripts, Workflow, Screens, and the Admin Split

Part 11 of the MAS MANAGE series (Series Finale). Everything you learned about configuring Maximo still works — but the platform underneath it changed, and the admin job split in two. This is the post that reconciles the old skills with the new ground.

<aside>
🎯 Who this is for: Maximo administrators, developers, and consultants who already know how to write a script, build a workflow, and reconfigure a screen — and who need to know exactly what carries forward into Manage 9, what changed underneath, and who owns which lever.
</aside>

Estimated read time: 24 minutes

✅ Your Configuration Knowledge Still Works

Let us start with the most reassuring sentence in this entire series: almost everything you know about configuring Maximo still applies. If you have spent years writing automation scripts, building workflows, reconfiguring screens, and adding attributes in Database Configuration, none of that knowledge expired when you moved to MAS. The configuration applications are the same applications, doing the same jobs, in the same way.

That matters because the rest of this series has been about change — new architecture, role-based apps, AI inside Manage. It would be easy to assume the configuration layer was rewritten too. It was not. The familiar toolkit carries forward essentially unchanged:

  • Automation Scripts — still Jython or JavaScript, still launched from object, attribute, action, integration, and cron launch points, still stored in the database. The script you wrote in 7.6 is the script you write in Manage 9.
  • Workflow Designer — still graphical process modeling on objects like WORKORDER and SR, still building approvals, routing, and conditional branching with the same node types.
  • Escalations — still time- and condition-based, still able to notify, change status, or invoke scripts on a schedule.
  • Conditional Expressions — still authored in the Conditional Expression Manager as named SQL conditions, and still reused across security, the UI, escalations, and workflow.

If you can do these things today, you can do them in Manage 9 on day one. No relearning required.

<aside>
💡 Key insight: The configuration toolkit is the continuity in MAS. The platform changed dramatically, but the way you script, route, escalate, and condition is a portable skill. Lead your team with that — it lowers the fear that everything must be relearned.
</aside>

🖥️ Screens, Schema, Domains, and Security

The rest of the classic configuration surface is intact too.

Application Designer still handles classic UI customization — rearranging fields, sections, tabs, and dialogs. App definitions are stored as XML in the database and can be exported and imported between environments, exactly as before. One framing note: role-based apps and Maximo Mobile have their own configuration mechanisms (see Part 2), so Application Designer is the tool for the classic UI, not the universal screen editor it once felt like.

Database Configuration still lets you add objects, attributes, relationships, and views. The application is the same; what changed is how the change takes effect, which we cover in the next section.

Domains still come in the same three flavors:

Domain type — What it does

Synonym — Maps multiple internal values to a single behavior (e.g., status synonyms)

Table — Validates against values in another table

Crossover — Copies values from one object to another when a field is set

Security still revolves around security groups, signature options, data restrictions, and conditional security — but with one MAS-level twist: users are mapped to identity-provider (IdP) roles rather than created and authenticated purely inside Maximo. The group model you configure is familiar; where the user identity comes from is not. Hold that thought — it is the seam where the admin role splits.

<aside>
💡 Key insight: The seam between "classic Maximo" and "MAS platform" runs right through security. You still build groups and signature options the Maximo way, but identity now originates in the IdP. That single boundary is the clearest signal of the larger admin split.
</aside>

⚙️ What Actually Changed Underneath

So if the applications are the same, what is different? The answer is the platform the applications run on. Four changes matter most.

1. Database Configuration now needs a pod restart

In classic Maximo, applying structural schema changes meant a metadata reload via an app-server restart (WebSphere). In MAS, that metadata reload happens through a pod restart instead. The conceptual model is identical — you queue changes, then reload metadata to apply them — but the mechanism is OpenShift, not WebSphere.

The discipline is unchanged and still essential: test in non-production first, and avoid modifying IBM-delivered objects so your customizations survive upgrades cleanly.

2. Custom Java is built into the image, not dropped as a JAR

This is the biggest mental shift for anyone who extended Maximo with Java. In 7.6, you dropped custom JARs into the WebSphere deployment and rebuilt the EAR. In MAS 9, custom Java is built into the container image and referenced via the Manage Custom Resource, then deployed through operators.

┌──────────────────────────────────────────────────────────────┐
│   CUSTOM JAVA: 7.6  vs  MAS 9                                 │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│   7.6:   custom.jar ──▶ WebSphere ──▶ rebuild EAR ──▶ restart│
│                                                              │
│   MAS 9: custom code ──▶ build container image ──▶ scan      │
│                    │                                         │
│                    ▼                                         │
│          Manage Custom Resource ──▶ operator ──▶ deploy pod  │
│                                                              │
└──────────────────────────────────────────────────────────────┘

The practical consequence: you now need a CI/CD pipeline that builds, scans, and deploys images. Customization is no longer a file copy; it is a software supply-chain activity, with image scanning and versioned deployments as first-class concerns.

3. Observability moved to the platform

Logs no longer live in a WebSphere SystemOut.log you tail on a server. They come through `oc logs` and the OpenShift logging stack. Metrics come through Prometheus-based monitoring. When you are diagnosing a slow night, the two things worth watching are cron-task pods and MIF queue backlogs — the modern equivalents of the cron task and integration queues you always kept an eye on.

4. Reporting carries forward — BIRT is still here

To be explicit, because it is a common worry: BIRT is still supported. Manage 9.0-era environments continue the BIRT 4.8 line, 9.1 uses BIRT 4.16, and 9.2 uses BIRT 4.21. BIRT is not deprecated — your report investment carries forward, but you should plan report-designer version alignment and report recompiles on the upgrade path.

<aside>
⚠️ Watch out: The single most common MAS-administration mistake is treating a platform problem as a Maximo problem. A pod that will not start, an image that fails its scan, an SSO redirect loop — none of those are fixed in Security Groups or System Properties. Learn to tell a Manage problem (workflow, script, domain) from a platform problem (pod, image, CR, IdP) before you start debugging, or you will look in the wrong application for an hour.
</aside>

🆕 New Configuration Tools in Manage 9

The toolkit did not just carry forward — it grew. None of these replace what you know; they extend it.

Manage 9.0 additions:

  • Formulas application (System Configuration module) — define object and attribute formulas declaratively, instead of reaching for a script every time you need a calculated value.
  • AI Configuration application (Administration module) — the control surface for the AI capabilities now embedded in Manage (covered in Part 10).
  • KPI Manager external endpoints — a KPI can now specify an external endpoint as its source.
  • Cognos Analytics integration — connect your own licensed stand-alone Cognos Analytics server.
  • `mxe.usemasforesig` — a new system property governing the e-signature behavior.
  • Podman — introduced as a Docker alternative for the build/config tooling.

Manage 9.1 additions:

  • Application Configuration Tool from within MAS — this is the quiet quality-of-life win. You no longer need Docker or Podman on a local machine to run application configuration; the tooling is available inside MAS itself.
  • New role-based admin apps — Users, Security Groups, User Profile, Mobile Configuration, and Incident Reporter arrive as role-based applications, modernizing administration that previously lived only in the classic UI.

The pattern across both releases is consistent: declarative tools (Formulas) reduce the need for code, and administration moves into role-based, in-platform tooling — without taking away the classic apps you still rely on for deep configuration.

📊 Operational Dashboard — the New Landing Layer

Start Centers did not vanish from the Maximo memory palace, but they are no longer the only way to give a role its front door. Operational Dashboard is the modern Manage dashboard surface: a configurable landing page where managers and specialists see the state of work, act on exceptions, and jump into the applications that need attention.

Think of it as the operational layer between "a static report" and "open five list tabs":

┌──────────────────────────────────────────────────────────────┐
│   OPERATIONAL DASHBOARD TECHNICAL MODEL                       │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│   Data sources                                               │
│   ├─ KPI Manager / KPI definitions                           │
│   ├─ Work queues and saved queries                           │
│   ├─ Manage records: WO, ASSET, SR, PR, PO, INCIDENT          │
│   └─ Industry or process templates                            │
│          │                                                   │
│          ▼                                                   │
│   Dashboard cards                                             │
│   ├─ KPI value / trend / comparison                           │
│   ├─ Work queues                                              │
│   ├─ Threshold and exception views                            │
│   ├─ Quick actions                                            │
│   └─ Shortcuts to Manage applications                         │
│          │                                                   │
│          ▼                                                   │
│   Public dashboards / private dashboards                      │
│          │                                                   │
│          ▼                                                   │
│   Security Groups + Operational Dashboard sigoptions          │
│                                                              │
└──────────────────────────────────────────────────────────────┘

What the dashboard is for

Operational Dashboard is not a replacement for Work Order Tracking, Graphical Scheduling, BIRT, or Cognos. It is a working dashboard: the place a maintenance manager, vegetation manager, reliability lead, or operations specialist can monitor a process and take action without starting from a blank application list.

Out of the box and in industry/process templates, the card model supports patterns like:

Card type — What it gives the user — Technical dependency

KPI value — Current value of a metric — KPI Manager / KPI definition

KPI trend — Movement of a metric over time — KPI history and refresh cadence

KPI comparison — Side-by-side metric comparison — Multiple KPI definitions

Work queue — A focused queue of records needing action — Work Queue Manager, saved queries, object data

Threshold / exception — Records breaching an operational threshold — KPI or query logic

Quick actions — Create or open records fast — Application security and sigoptions

Shortcuts — Jump to apps such as Assets, Service Requests, Work Orders, PRs, Scheduling Dashboard — Navigation and application access

IBM's vegetation-management dashboard is a good concrete example: it exposes quick actions such as creating a work order or purchase requisition, work queues such as waiting-for-approval work orders and unassigned approved work, and shortcuts into applications such as Assets, Service Requests, Work Orders, and Scheduling Dashboard. The same pattern applies outside vegetation: pick the role, pick the KPIs, pick the exception queues, then give users the actions they need from that surface.

<aside>
💡 Key insight: Operational Dashboard is where Start Center thinking becomes operational again. The design question is not "what charts look good?" It is "what does this role need to notice, decide, and do in the next ten minutes?"
</aside>

Public, private, and secured dashboards

Access is controlled in the Security Groups application, using the Operational Dashboard application and its signature options. This is important: dashboard governance is still a Manage security problem, not a separate BI-admin problem.

The main permission scenarios are:

Permission scenario — What it allows

Create private dashboard — User can create, edit, duplicate, view, and delete their own private dashboards

Create public dashboard — User can create, edit, duplicate, view, and delete dashboards shared publicly

Delete private dashboard — Admin can delete private dashboards created by users

Hide public dashboard — User can hide public dashboards from their own view

Read public dashboard — User can view public dashboards created by others, but not private dashboards created by others

That gives you a clean governance model:

  • Public dashboards are curated role or process dashboards — maintenance manager, storeroom supervisor, vegetation specialist, shutdown planner.
  • Private dashboards are user-level workbenches — useful for power users, but easy to let sprawl if you never review them.
  • Read-only access lets broad audiences consume a standard dashboard without changing its cards or layout.

How to build one well

The mechanics are simple: open Operational Dashboard, create a dashboard, set a name and description, optionally make it the default view, add cards from the gallery, configure each card's basic and advanced parameters, and save. The engineering discipline is in what you choose to put on it.

Use this build pattern:

  1. Start with the persona. A maintenance manager, storeroom clerk, and reliability engineer should not share the same dashboard just because they share the same site.
  2. Define the decisions. Write down the decisions the dashboard must support: approve work, rebalance backlog, chase overdue receipts, assign unowned work, review high-risk assets.
  3. Choose KPIs sparingly. Three useful KPIs beat fifteen decorative ones. Pair every KPI with a queue or action that lets the user respond.
  4. Make work queues actionable. A queue should lead to a record list the user can actually clear or improve.
  5. Wire quick actions carefully. If a dashboard lets users create work orders or PRs, the underlying application permissions and sigoptions must match the role.
  6. Separate public from private. Curate public dashboards intentionally; let private dashboards support individual preference without becoming your governance model.

<aside>
⚠️ Watch out: Operational Dashboard can expose bad KPI design faster than any report. If KPI Manager definitions are stale, saved queries are loose, or security groups grant actions the role should not have, the dashboard amplifies the problem. Build dashboards only after the underlying KPIs, queues, and permissions are clean.
</aside>

How it fits with reports and AI

Operational Dashboard, BIRT, Cognos, and the Maximo Assistant all answer different questions:

Tool — Use it when

Operational Dashboard — A role needs a live working surface for KPIs, queues, and actions

BIRT — You need operational reports, printed outputs, or established Maximo report packages

Cognos Analytics — You need enterprise analytics, governed BI, cross-domain modeling, or executive reporting

Maximo Assistant — A user needs a natural-language read over authorized Maximo data

Do not force one to do the other's job. A dashboard is for daily operation; BIRT is for transactional reporting; Cognos is for broader analytics; the Assistant is for natural-language exploration. Used together, they give users a clean path from "what is happening?" to "what should I open?" to "what action do I take?"

🔀 The Admin Split

Here is the concept that, more than any single feature, defines administering MAS Manage. The administrator role split in two. Where there used to be one "Maximo administrator" who owned everything from the database to the login page, there are now two clearly separated responsibilities — and the most valuable skill is knowing which lever lives where.

┌───────────────────────────────┬───────────────────────────────┐
│   MAS SUITE ADMINISTRATOR      │   MAXIMO / MANAGE ADMIN        │
│   (owns the environment)       │   (owns the application)      │
├───────────────────────────────┼───────────────────────────────┤
│ • Identity Provider (IdP)      │ • Security Groups             │
│ • SSO (OIDC / SAML)            │ • System Properties           │
│ • AppPoints & entitlements     │ • Database Configuration      │
│ • Suite-wide health            │ • Domains                     │
│ • OpenShift deployment via     │ • Automation Scripts          │
│   operators & Custom Resources │ • Workflow Designer           │
│   (CRs in YAML, oc/kubectl,    │ • Admin Work Center /         │
│   GitOps)                      │   MAS admin workspace         │
└───────────────────────────────┴───────────────────────────────┘

The MAS Suite administrator owns the environment: the identity provider, SSO via OIDC or SAML, AppPoints and entitlements, suite-wide health, and the OpenShift-level deployment of Manage via operators and Custom Resources — CRs authored in YAML, edited with `oc` or `kubectl`, and increasingly managed through GitOps.

The Maximo/Manage administrator keeps the application: Security Groups, System Properties, Database Configuration, Domains, Automation Scripts, and Workflow — plus the Admin Work Center / MAS admin workspace where these classic functions live.

The fastest way to internalize the split is by example:

You need to… — Where it lives

Change the application base URL — MAS-level (suite configuration)

Configure SSO / change the IdP — MAS-level

Allocate AppPoints to users — MAS-level

Scale or redeploy Manage — MAS-level (Custom Resource via operator)

Add an attribute to WORKORDER — Manage-level (Database Configuration)

Change a work-order approval routing — Manage-level (Workflow)

Restrict a field for a security group — Manage-level (Security Groups + data restrictions)

Add a synonym status value — Manage-level (Domains)

A base URL or SSO change is a MAS task. A workflow change is a Manage task. Get that distinction wrong and you will spend a frustrating afternoon in the wrong application.

<aside>
💡 Key insight: The admin split is not bureaucracy — it is a separation of concerns. Platform reliability (pods, identity, entitlements) and application logic (workflow, scripts, schema) have genuinely different lifecycles, owners, and failure modes. Treating them as one job is exactly what made classic Maximo administration so brittle.
</aside>

🎯 The Commandments of Configuring and Administering Manage 9

  1. Thou shalt trust thy existing skills — scripts, workflow, escalations, and conditional expressions all carry forward.
  2. Thou shalt remember the pod restart — DB Config changes reload metadata via a pod restart, not a WebSphere restart.
  3. Thou shalt not modify IBM-delivered objects — keep customizations upgrade-safe and test in non-prod first.
  4. Thou shalt build custom Java into the image — and stand up CI/CD that builds, scans, and deploys.
  5. Thou shalt know which lever lives where — base URL and SSO are MAS; workflow and schema are Manage.
  6. Thou shalt use the new tools — Formulas for declarative calcs, the in-MAS Application Configuration Tool, and AI Configuration.
  7. Thou shalt look at the platform — oc logs, Prometheus, cron-task pods, and MIF queue backlogs when something is slow.

Key Takeaways

  • The classic configuration toolkit carries forward essentially unchanged — Automation Scripts (Jython/JavaScript), Workflow Designer, Escalations, Conditional Expressions, Application Designer, Database Configuration, domains, and security groups all work the way you remember.
  • The platform underneath changed: Database Configuration changes apply via a pod restart, observability moves to `oc logs` and Prometheus, and reporting still runs on BIRT (4.16 in 9.1, 4.21 in 9.2 — not deprecated).
  • Custom Java is built into the container image and deployed via the Manage Custom Resource through operators, so you need a CI/CD pipeline that builds, scans, and deploys images.
  • The admin role split in two: MAS Suite owns IdP, SSO (OIDC/SAML), AppPoints, suite health, and OpenShift CRs; Manage keeps Security Groups, System Properties, DB Config, Domains, Scripts, Workflow, and the Admin Work Center.
  • New tools extend the toolkit: Formulas (9.0), AI Configuration (9.0), KPI external endpoints, Cognos Analytics integration, mxe.usemasforesig, the in-MAS Application Configuration Tool (9.1), and new role-based admin apps (Users, Security Groups, User Profile, Mobile Configuration, Incident Reporter).

🏁 The End of the Road — Tying the Series Together

Eleven parts ago, this series set out to answer one question: what actually changed when Maximo became Maximo Manage on MAS? We started with the new Manage and its architecture, walked through work centers to role-based apps, and then went deep on the functional capabilities — work management, reliability strategies, inspections, assets, and the rest — before examining the AI now inside Manage.

This finale closes the loop with the most practical message of all: the change is real, but it is not a reset. Your configuration craft — scripting, routing, conditioning, schema design — is exactly as valuable in Manage 9 as it ever was. What you add to it is a platform mindset: containers and operators, identity providers and AppPoints, pods and pipelines. And what you internalize is the admin split — the discipline of knowing which lever lives where.

If there is one idea to carry out of all eleven parts, it is that Maximo Manage rewards the practitioner who pairs old depth with new ground. The functional expertise still wins; it just runs on a platform that asks you to think in deployments and identities as well as in work orders and workflows.

Thank you for reading the whole series. To revisit any part — or to send a colleague to the right starting point — head back to the Series Index.

References

IBM Official

Community

Series Navigation

Previous: — Part 10 — The AI Inside Manage

Next: — You have reached the end of the series. Head back to the Series Index.

Published by TheMaximoGuys | June 2026

About TheMaximoGuys: We help Maximo developers and teams navigate the move to MAS — from architecture and migration planning to the day-to-day work of configuring, extending, and running Maximo Manage. This series is the guide we wish we'd had.