Inside Maximo Manage 9.x: Work Order Intelligence, Automation Scripts, and the New Admin Split

Introduction

If you have been working with Maximo for more than a few years, the shift to Maximo Application Suite probably still feels new. The product you used to call "Maximo" is now a set of integrated applications: Maximo Manage, Maximo Health, Maximo Predict, Maximo Monitor, and a long tail of industry solutions. Manage is the one most teams spend their time in, and the one that has accumulated the most change since the move to MAS.

This article is a deep dive into Maximo Manage 9.x. We are going to walk through the parts of the application that have changed the most, and the parts that experienced practitioners most often get wrong. We will cover Work Order Intelligence and the new AI-assisted failure code recommendation, the JSON mapper that has quietly become the integration pattern of choice, the ManageWorkspace custom resource that determines how your attachments are stored, and the practical split between Suite-level and Manage-level administration that catches new administrators off guard.

The intended audience is the practitioner: the developer writing automation scripts, the consultant configuring business rules, and the integration engineer wiring Maximo into a broader landscape. We will assume you have some Maximo experience. We are not going to explain what a work order is. We are going to explain how Work Order Intelligence changes the way you think about problem codes, how the JSON mapper lets you skip the Java customization, and how to debug a ManageWorkspace configuration that is not behaving.

The goal is for you to walk away with a working mental model of the current Manage architecture, plus three or four patterns you can apply in your own environment this week.

Work Order Intelligence: AI That Lives Where the Work Lives

Work Order Intelligence is the umbrella term for a set of AI-assisted features that landed in Manage 9.0 and have continued to evolve in 9.1 and 9.2. The most visible feature is the recommended failure code, which appears on a work order when a technician describes the problem in free text. Behind the scenes, an AI broker takes the description, runs it through an inference model, and returns the top three most likely problem and failure codes. The technician sees the recommendations, picks one, and the work order is updated with the chosen code.

The operational pattern is that the AI is not creating new failure codes. It is matching against the existing failure code hierarchy in your Maximo database. This is important because it means the AI is only as good as your failure code catalog. If you have a clean, well-curated failure code hierarchy, the recommendations will be useful. If your failure code catalog is a graveyard of one-off entries from 2014, the recommendations will be noisy.

The configuration is straightforward. The AI broker is enabled in the ManageWorkspace custom resource, and the model is referenced by name. Inference happens at the moment the technician saves a long description, not at the moment the work order is created. The recommendations appear in a panel on the work order, and the technician can accept, reject, or override. The history of acceptance and rejection is stored on the work order and is fed back into the model.

A practical pattern: start with a narrow pilot. Pick a single crew, a single asset class, and a 60-day window. Measure the acceptance rate (how often the technician picks one of the top three recommendations) and the override rate (how often the technician picks something else or types free text). Acceptance above 50 percent is a good signal. Override above 30 percent is a signal that the failure code hierarchy needs work, not that the AI is broken.

The second feature in the Work Order Intelligence family is duplicate detection. When a new work order is created, the system compares it against recent work orders on the same asset, the same location, or the same problem code. If a probable duplicate is found, the technician is shown the existing work order and asked to confirm. This is a meaningful reduction in duplicate work, especially in environments where field crews raise work orders independently and the visibility across crews is limited.

# Example: an automation script that consumes Work Order Intelligence signals
# Triggered on WORKORDER save with a long description present
from psdi.mbo import Mbo
from psdi.server import MXServer
from java.util import HashMap

def main():
    wo = mbo
    longDesc = wo.getString("DESCRIPTION_LONGDESCRIPTION")
    if not longDesc:
        return

    # Query the AI broker via the standard integration endpoint
    broker = MXServer.getMXServer().getMboSet("AIINFERENCE", wo.getUserInfo())
    broker.setWhere("assetnum = '" + wo.getString("ASSETNUM") + "'")
    broker.reset()
    if broker.isEmpty():
        broker.close()
        return

    inference = broker.getMbo(0)
    topCode = inference.getString("RECOMMENDEDCODE")
    confidence = inference.getDouble("CONFIDENCE")

    # Only auto-populate when the model is highly confident
    if confidence > 0.85 and not wo.getString("PROBLEMCODE"):
        wo.setValue("PROBLEMCODE", topCode, Mbo.NOACCESSCHECK)

    broker.close()

The script above is a simplified example. In production you would add error handling, audit logging, and a guard against running on migrated records. The point is the pattern: Work Order Intelligence exposes its outputs as MboSets, which means you can write automation scripts against them just like you would against any other Maximo object.

The JSON Mapper: The Integration Pattern That Finally Replaced Custom Java

For a long time, Maximo integrations came in two flavors: the Maximo Integration Framework (MIF) for declarative publish channels and enterprise services, and custom Java for anything more complex. The gap between the two was the source of enormous pain. Anything that required conditional logic, multi-object lookups, or complex transformations required a developer and a build cycle.

The JSON mapper, which matured significantly across the 8.11 and 9.x releases, closes that gap. It supports publish channels and enterprise services today, and a recent workaround documented by the Maximo community (Amin Chakri's work on invocation channels) extends it to outbound flows. The mapper is configured in the JSON Mapping application, and the resulting mappings are deployed through the standard MIF processing layer.

The mapper supports a rich set of transformation primitives. You can map fields by name, apply conditional logic, look up related objects, format dates and numbers, and compose complex nested structures. The configuration is stored in Maximo and can be moved between environments through the standard migration tools.

A field-tested pattern: use the JSON mapper for any new integration that does not have a hard requirement for a custom Java class. The mapper is faster to build, easier to maintain, and accessible to functional consultants who do not write Java. Reserve custom Java for the cases where you genuinely need it: complex validation, integration with a system that does not speak REST, or a transformation that is too complex for the mapper's primitives.

A common pitfall is using the mapper for inbound enterprise services without first validating the source payload. The mapper will faithfully transform whatever it receives, including garbage. Validate the payload at the edge (in an API gateway, in a routing rule, or in a pre-mapping script) before the mapper runs. Otherwise you will spend hours debugging why an empty string from your source system created a Maximo record with a critical field set to null.

ManageWorkspace: The Custom Resource You Cannot Afford to Misconfigure

ManageWorkspace is the custom resource that defines the runtime configuration of a Maximo Manage deployment. It controls database configuration, attachment storage, build options, and a long list of operational parameters. It is also one of the most common sources of upgrade-day surprises, because changes to ManageWorkspace are not always backward compatible.

The attachment storage setting is a good example. ManageWorkspace lets you choose between file-based storage (the default) and object-based storage (typically S3 or a compatible service). File-based storage works well for smaller deployments. Object-based storage is the right choice for any environment that needs to scale attachments into the millions, or that needs to integrate with an enterprise content management system. The choice is sticky. Migrating from file-based to object-based storage is a project, not a configuration change.

The build configuration is another important setting. In MAS 9.x, the operator can build and deploy the admin and bundle images automatically, or it can use pre-built images that you provide. For most teams, the automatic path is fine. For teams with strict change control, the pre-built path is better: you build the image in a CI pipeline, scan it, sign it, and then hand it to the operator. The trade-off is more work in the build pipeline and less work at deploy time.

# Example: ManageWorkspace configuration with object-based storage
apiVersion: mas.ibm.com/v1
kind: ManageWorkspace
metadata:
  name: mas-manage-prod
  namespace: mas-core
spec:
  attachments:
    storageType: object
    objectStore:
      provider: s3
      bucket: maximo-prod-attachments
      region: us-east-1
      credentialsSecret: mas-attach-s3
  build:
    mode: external
    imageRegistry: registry.example.com/maximo
    imageTag: 9.2.0-prod.1
  database:
    type: db2
    maximoDbName: MAXDB
    schema: maximo
  features:
    jsonMapping: enabled
    workOrderIntelligence: enabled
    conditionInsight: enabled
    scimSync: enabled
  resources:
    requests:
      cpu: "4"
      memory: "16Gi"
    limits:
      cpu: "8"
      memory: "32Gi"

The example above is a production-style ManageWorkspace. The attachment storage is object-based, the build mode is external (CI-built image), and the AI features are explicitly listed as enabled. The resources block is conservative; in production you would right-size based on your workload.

A common pitfall is changing the ManageWorkspace without documenting the change. The custom resource is the source of truth for the deployment, and the only way to reproduce a deployment is to version-control the custom resource alongside the operator configuration. If your ManageWorkspace is not in Git, your upgrade is not reproducible.

The Suite-vs-Manage Admin Split

The shift to MAS introduced a split that new administrators find confusing: some administrative functions live at the Suite level, and some live at the Manage level. The Suite level is where you manage user authentication, licensing, identity providers, and cluster-wide configuration. The Manage level is where you manage security groups, domains, automation scripts, applications, and the data model.

The rule of thumb is: if the configuration affects more than one application in the suite, it belongs at the Suite level. If the configuration affects only Manage, it belongs at the Manage level. A user account, for example, is Suite-level because the same user might log into Manage, Health, and Predict. A security group is Manage-level because the access rules are specific to Manage's object structure.

The practical implication for security is that you need to think about role assignment differently. In the old Maximo world, a security group was a one-stop shop. In MAS, a user has a Suite-level role (which determines what applications they can launch) and a Manage-level role (which determines what they can do within Manage). Both are needed. A user with only a Suite-level role can launch Manage but cannot see any records. A user with only a Manage-level role cannot launch Manage at all.

A field-tested pattern: when you onboard a new user, start at the Suite level. Create the user, assign them to the appropriate Suite-level role, and verify they can log in and launch the application. Then move to the Manage level and assign them to the appropriate security groups for the work they need to do. The two-step process catches configuration errors early, before the user starts trying to do work.

A related concern is the deprecation of features that previously lived in Manage. The Maximo Assist search function, voice inspections, and Watson Discovery integration are no longer available in MAS 9.0. If you depended on these features, you have already had to migrate. If you are on 8.11 and planning a move to 9.x, factor the migration work into your plan. The features are not coming back.

Practical Implications

The patterns in this article point to a broader truth: Maximo Manage is increasingly a platform that rewards configuration discipline over custom code. The JSON mapper lets functional consultants do work that used to require Java developers. Work Order Intelligence lets the data model do work that used to require analysts. ManageWorkspace lets the operator do work that used to require infrastructure engineers. None of this is magic, and none of it replaces the need for skilled practitioners, but it does change the skills mix that a healthy Maximo team needs.

A practical takeaway: invest in your team's ability to read and write the declarative configurations. Automation scripts, JSON mappings, ManageWorkspace custom resources, and SCIM mappings are the new core competencies. Java customizations are still needed for edge cases, but the volume is dropping.

The second takeaway is to treat ManageWorkspace as a first-class artifact. Version-control it, review it, and test changes to it in non-production before they reach production. A misconfigured ManageWorkspace is one of the most common causes of upgrade-day outages, and it is one of the most preventable.

The third takeaway is to plan your Work Order Intelligence rollout around data hygiene. The AI features surface the state of your data more publicly than any dashboard. If your data is good, the AI is a multiplier. If your data is poor, the AI is a liability. The time to fix the failure code hierarchy, the asset hierarchy, and the meter data is before you turn the AI on, not after.

Bottom Line

Maximo Manage 9.x is a meaningful evolution of the core product. Work Order Intelligence brings AI-assisted failure code recommendations and duplicate detection directly into the work order screen. The JSON mapper has matured into a viable alternative to custom Java for most integration patterns. ManageWorkspace is the source of truth for deployment configuration and must be treated as such. And the Suite-vs-Manage admin split, while initially confusing, is a cleaner separation of concerns than the old monolithic configuration. The teams that get the most out of Manage 9.x are the ones that have invested in declarative configuration skills, that treat the operator-managed resources as code, and that have a data hygiene discipline that the AI features can build on.

Field-Tested Patterns and Common Pitfalls

A field-tested pattern for JSON mapping is to keep the mappings small and composable. A single mapping that handles a 50-field object structure is hard to debug. Five mappings that each handle a logical subset of the fields are easy to debug and easy to reuse. Build the mappings like you would build functions: small, named, and tested.

A common pitfall is to rely on automation scripts that are not idempotent. An automation script that fires on save and updates a field can easily create a loop, especially if the field it updates is itself a trigger. Use the standard Mbo.setValue flags correctly, and design the script so that a second invocation with the same input is a no-op.

Another pitfall is to assume that the JSON mapper is REST-only. The mapper works with any MIF-supported transport, including JMS, file-based polling, and HTTP. If you have a legacy integration that uses a non-REST transport, the mapper can still serve it. Check the MIF documentation for the transport you need.

Finally, a field-tested pattern for ManageWorkspace changes is to always run the change in a dry-run mode first. The MAS CLI supports a dry-run flag that will show you what the operator will do without actually doing it. Use it. A misapplied ManageWorkspace change can take down a deployment, and the dry-run is the difference between a quick rollback and an outage.