Maximo Manage Deep Dive: Work Order Intelligence, Automation Scripts, and the Integration Layer

Maximo Manage Deep Dive: Work Order Intelligence, Automation Scripts, and the Integration LayerIf 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 growing 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 deep dive covers the parts of Manage 9.x that have changed the most and the parts that experienced practitioners most often get wrong.

We will walk through Work Order Intelligence and AI-assisted failure code recommendations, the automation script patterns that have become standard in 9.x, the JSON mapper that is quietly replacing custom Java integrations, the ManageWorkspace custom resource that controls your runtime configuration, 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 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 build cycle, and how to debug a ManageWorkspace configuration that is not behaving.

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 through 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.

The critical detail is that the AI is not creating new failure codes. It is matching against the existing failure code hierarchy in your Maximo database. This 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. Before enabling Work Order Intelligence, invest time in cleaning up your failure code hierarchy. Remove duplicates, consolidate similar codes, and ensure that each code has a clear, distinct meaning.

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, which means the recommendations improve over time as your team uses the feature.

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 visibility across crews is limited.

A practical pattern for rollout: 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. Expand the pilot incrementally, adding crews and asset classes as confidence in the recommendations grows.

# Example: automation script consuming 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

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

broker.close() ```

The script above shows a pattern for consuming Work Order Intelligence outputs programmatically. In production you would add error handling, audit logging, and a guard against running on migrated records. The key insight is that Work Order Intelligence exposes its outputs as MboSets, which means you can write automation scripts against them just like any other Maximo object.

Automation Scripts: Patterns That Work in 9.x

Automation scripts have been the preferred extension mechanism in Maximo since 7.6, and they remain so in MAS 9.x. What has changed is the range of script points available and the integration with Suite-level services. In 9.x, you can attach scripts to object save events, attribute changes, workflow transitions, escalation points, and integration events. The script engine supports Python (Jython), and the available API surface includes both the traditional Maximo MBO API and newer REST-based endpoints.

One pattern that has become standard is using automation scripts as the glue between Manage and other MAS applications. For example, when a work order is completed in Manage, a script can trigger a health recalculation in Maximo Health, or kick off a prediction refresh in Maximo Predict. This cross-application orchestration was previously handled by custom Java or external middleware. In 9.x, the automation script framework handles it natively.

Another pattern is using scripts for data validation that goes beyond what conditional expressions can handle. A common example is validating that a work order's assigned labor has the required qualifications for the asset's safety plan. This requires looking up the safety plan, checking the required qualifications, and comparing them against the assigned labor's qualifications. This is a multi-object lookup that conditional expressions cannot handle, but an automation script can do it in 15 lines of code.

# Example: validate labor qualifications against safety plan requirements
from psdi.mbo import Mbo
from psdi.server import MXServer

def main(): wo = mbo assetNum = wo.getString("ASSETNUM") if not assetNum: return

safetyPlan = safetySet.getMbo(0) # Get required qualifications from the safety plan reqSet = safetyPlan.getMboSet("SPPLANHAZARDPRECAUTION") requiredQuals = set() for i in range(reqSet.count()): req = reqSet.getMbo(i) qual = req.getString("QUALIFICATION") if qual: requiredQuals.add(qual) safetySet.close()

if not requiredQuals: return

missing = requiredQuals - laborQuals if missing: # Flag the labor assignment with a warning labor.setValue("CREWID", "MISSING_QUAL:" + ",".join(missing), Mbo.NOACCESSCHECK) ```

A common pitfall with automation scripts is performance. Scripts run in the Maximo application server thread, which means a slow script blocks the user's request. Always use setWhere with specific queries rather than iterating through large MboSets. Use count() sparingly, as it can trigger a database count query. And never make external HTTP calls from a synchronous script point. If you need to call an external service, use an asynchronous escalation or a cron task instead.

The JSON Mapper: Replacing Custom Java One Integration at a Time

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 community-documented workarounds extend 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 (LDA, Migration Manager, or the MAS CLI).

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 incoming payload structure. The mapper will silently ignore fields it does not recognize, which can lead to data quality issues that are difficult to trace. Always test with a representative sample payload before deploying to production, and enable MIF message logging during the initial deployment so you can trace any mapping issues.

{
  "mappingName": "WO_TO_ERP_SYNC",
  "objectName": "WORKORDER",
  "direction": "OUTBOUND",
  "publishChannel": "EXTSYS1_WO_PUBLISH",
  "mappings": [
    {
      "sourceField": "WONUM",
      "targetField": "workOrderNumber",
      "transform": "UPPER"
    },
    {
      "sourceField": "STATUS",
      "targetField": "status",
      "transform": "MAP",
      "mapValues": {
        "WAPPR": "PENDING",
        "APPR": "APPROVED",
        "INPRG": "IN_PROGRESS",
        "COMP": "COMPLETED",
        "CLOSE": "CLOSED"
      }
    },
    {
      "sourceField": "ASSET.ASSETNUM",
      "targetField": "assetNumber",
      "lookup": {
        "object": "ASSET",
        "relationship": "ASSETNUM = '${ASSETNUM}'",
        "returnField": "ASSETNUM"
      }
    },
    {
      "sourceField": "ACTLABHRS",
      "targetField": "actualLaborHours",
      "transform": "DECIMAL",
      "format": "#.##"
    },
    {
      "sourceField": "LOCATION.DESCRIPTION",
      "targetField": "locationDescription",
      "lookup": {
        "object": "LOCATIONS",
        "relationship": "LOCATION = '${LOCATION}'",
        "returnField": "DESCRIPTION"
      }
    }
  ]
}

The JSON above shows a typical mapping configuration for syncing work orders to an ERP system. Note the status mapping, which translates Maximo status codes to the ERP system's status codes. This is the kind of transformation that previously required custom Java and now lives in a declarative configuration that any consultant can maintain.

ManageWorkspace: The Configuration That Controls Everything

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. Most administrators interact with it only during installation and upgrade, but understanding it is essential for troubleshooting.

The most common ManageWorkspace issue is attachment storage. In MAS 9.x, attachments can be stored in the database, in a persistent volume, or in an external S3-compatible storage system. The storage mode is set in the ManageWorkspace spec and cannot be changed after deployment without a rebuild. If you choose database storage and your users upload large files, you will see performance degradation. If you choose persistent volume storage, you need to ensure the storage class supports the required access modes and has sufficient capacity. S3-compatible storage is the recommended option for production, as it scales independently and does not consume database or volume resources.

Another ManageWorkspace setting that causes problems is the buildOptions section. This controls which applications and features are included in the Manage deployment. If you enable a feature like Calibration or Condition Monitoring during initial deployment and later want to disable it, you need to update the ManageWorkspace spec and trigger a rebuild. This is not a runtime change. Plan your build options carefully during initial deployment to avoid unnecessary rebuilds.

The Admin Split: Suite vs. Manage

One of the most common sources of confusion for administrators new to MAS is the split between Suite-level administration and Manage-level administration. In Maximo 7.x, everything was in one place. In MAS, some administrative functions live at the Suite level (MAS Core) and others live at the Manage level. Getting this split wrong leads to frustration and failed configurations.

Suite-level administration includes user management, security groups, licensing, workspace configuration, and system-wide settings. These are managed through the MAS Core UI, not the Manage UI. If you try to create a user in Manage and cannot find the option, it is because user management is a Suite-level function.

Manage-level administration includes application configuration, automation scripts, integration configuration, cron tasks, workflows, and database configuration. These are managed through the Manage UI, which looks and feels like the Maximo you are used to.

The practical implication is that administrative tasks often require switching between two UIs. A new user setup involves creating the user in MAS Core, assigning them to a security group in MAS Core, ensuring the security group has the right Manage application permissions, and then verifying the user can log in and see the expected applications. Document this workflow for your administrative team to avoid confusion.

Practical Implications

The shift to MAS 9.x has changed how practitioners work with Maximo in fundamental ways. Work Order Intelligence means that failure code quality is now an AI training issue, not just a reporting issue. The JSON mapper means that most integrations no longer require Java development, but they do require careful payload testing. ManageWorkspace configuration decisions made during deployment are expensive to reverse. And the Suite-level vs. Manage-level admin split requires updated documentation and training for administrative teams. Practitioners who adapt to these changes will find that 9.x is a more productive environment than 8.x in almost every respect. Practitioners who try to apply 7.x or 8.x patterns without modification will encounter friction.

Bottom Line

Maximo Manage 9.x is a substantially different product from its predecessors, and the practitioners who succeed are the ones who take the time to understand the new architecture. Work Order Intelligence, automation script patterns, the JSON mapper, and the ManageWorkspace custom resource are the four areas where the most has changed and where the most value is concentrated. Invest in cleaning your failure code hierarchy before enabling AI features. Use the JSON mapper for new integrations and reserve Java for genuine edge cases. Document your ManageWorkspace configuration decisions. And train your administrators on the Suite vs. Manage split before they encounter it in production. The tools are better than they have ever been. The learning curve is real, but it is worth climbing.