Inside Maximo Manage 9.x: Work Order Intelligence, AI Assistant, and the ManageWorkspace Configuration Guide

Inside Maximo Manage 9.x: Work Order Intelligence, AI Assistant, and the ManageWorkspace Configuration GuideMaximo Manage 9.x is not a incremental update. It is a significant evolution of the core EAM platform, with AI features woven into daily workflows, a new administrative model that splits responsibilities between the Suite level and the Manage level, and a configuration system that has moved from property files to Kubernetes custom resources. For administrators who have spent years in Maximo 7.6, the transition to Manage 9.x requires unlearning some habits and learning new patterns. This article is a practitioner's deep dive into the features and configurations that matter most in a 9.x deployment.

We will cover Work Order Intelligence and the AI-assisted failure code recommendation engine, the Maximo AI Assistant that handles natural language queries, the ManageWorkspace custom resource that controls runtime configuration, the JSON mapper that has become the integration pattern of choice, and the practical split between Suite-level and Manage-level administration that catches new administrators off guard.

Work Order Intelligence: AI-Assisted Failure Coding and Duplicate Detection

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 a 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 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 more data is collected.

Here is what the ManageWorkspace configuration looks like for enabling Work Order Intelligence:

apiVersion: mas.ibm.com/v1
kind: ManageWorkspace
metadata:
  name: manage-workspace
  namespace: mas-inst1-manage
spec:
  settings:
    workOrderIntelligence:
      enabled: true
      model: "maximo-failure-code-v2"
      confidenceThreshold: 0.65
      maxRecommendations: 3
      feedbackLoop: true
    jsonMapping:
      enabled: true
    conditionInsight:
      enabled: true
    scimSync:
      enabled: true

The confidenceThreshold field controls how confident the model must be before it presents a recommendation. A threshold of 0.65 means the model will only show recommendations where it is at least 65% confident. Setting this too low results in irrelevant recommendations that technicians will ignore. Setting it too high means the model will rarely present recommendations, reducing the feature's value. The feedbackLoop field controls whether technician acceptances and rejections are fed back into the model for continuous improvement.

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.

The duplicate detection algorithm considers asset identity, location identity, problem code, time window (typically 72 hours), and work order status. If an open work order exists for the same asset with the same problem code within the time window, the system flags it as a probable duplicate. The technician can then review the existing work order and decide whether to proceed with the new one or close it as a duplicate.

The third feature, available in 9.2, is Condition Insight integration within work orders. When a work order is generated from a condition monitoring alert, the Condition Insight summary is embedded in the work order's long description. This gives the technician context about why the work order was created, what the asset condition trends look like, and what corrective actions the AI recommends. This eliminates the need for the technician to navigate to a separate application to understand the context.

The Maximo AI Assistant: Natural Language Queries in Practice

Starting in MAS 9.1, the Maximo AI Assistant is available in Maximo Manage, Maximo Health, the Operational Dashboard, and asset dashboards. The assistant responds to natural language requests about work orders, service requests, and assets. It is powered by IBM watsonx and uses a retrieval-augmented generation approach to query the Maximo database and return results in plain language.

The assistant can handle a variety of query types. For work orders, it can show open work orders, filter by status, priority, asset, or date range, and provide summaries. For assets, it can show asset details, health scores, failure history, and open work orders. For service requests, it can show open requests and their status. Cross-category queries are also supported, such as "Show me all open work orders for assets with a health score below 60."

Here is a practical example of how a reliability engineer might use the assistant:

A reliability engineer opens the Manage application and types: "What are my top 10 at-risk assets?" The assistant queries the asset registry, joins it with the health scoring data from Maximo Health, sorts by health score ascending, and returns a table with asset number, description, health score, criticality, and open work order count. The engineer then asks: "Show me open work orders for the first asset." The assistant filters the work order registry by that asset number and status, and returns the list.

The assistant cannot create or edit data. It is a read-only tool that surfaces information. This is an important limitation to communicate to users who may expect it to function like a general-purpose AI chatbot. The assistant also cannot answer general questions about how to use Maximo or provide IBM Support information. Its scope is limited to the data in the Maximo database.

Administrators can limit what types of questions the assistant can respond to. For example, if an administrator restricts the assistant's access to asset data, it cannot answer questions about assets. This is configured through the AI Service settings in the MAS Administration interface. The administrator can also complete prompt tuning to enable the assistant to understand organization-specific abbreviations. For example, if users refer to work orders as "tags" in the field, the administrator can tune the prompt so the assistant understands "show me open tags" as "show me open work orders."

The assistant respects user permissions. It cannot provide data that the user does not have access to. If data is incomplete or contains errors, such as work orders missing descriptions, the assistant might not locate or properly represent that data. This is a data quality issue, not an AI issue, but it affects user trust in the assistant.

Here is how the AI assistant is configured at the Suite level:

aiService:
  enabled: true
  provider: "watsonx"
  model: "maximo-assistant-v1"
  features:
    assistant:
      manage: true
      health: true
      operationalDashboard: true
      assetDashboards: true
    failureCodeRecommendation:
      enabled: true
    conditionInsight:
      enabled: true
  restrictions:
    deniedTopics:
      - "asset_data"  # Uncomment to restrict asset queries
    allowedDataSources:
      - "WORKORDER"
      - "ASSET"
      - "SR"
      - "HEALTHSCORE"
  promptTuning:
    abbreviations:
      - { term: "tag", mapsTo: "work order" }
      - { term: "PM", mapsTo: "preventive maintenance" }

The restrictions section allows administrators to control what the assistant can and cannot access. The promptTuning section maps organization-specific terminology to standard Maximo terms. This is a simple but powerful feature that improves the assistant's usability in environments where field terminology differs from Maximo's standard vocabulary.

ManageWorkspace: The Configuration Hub and Its Pitfalls

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 ManageWorkspace custom resource is defined in YAML and applied through OpenShift. Changes to ManageWorkspace trigger a rebuild of the Manage pod, which means configuration changes cause downtime. This is a significant difference from Maximo 7.6, where many configuration changes could be made through the UI without restarting the application. In MAS 9.x, structural changes require a ManageWorkspace update and a pod rebuild.

The key sections of ManageWorkspace that administrators need to understand include:

Database Configuration: The db section controls the database connection, schema, and tablespace settings. Changes to database configuration require a pod rebuild and can cause data migration if new columns or tables are introduced. Always test database configuration changes in a non-production environment first.

Attachment Storage: The attachments section controls how attachments are stored. MAS 9.x supports file system storage, S3-compatible object storage, and IBM Cloud Object Storage. The storage type is configured at deployment time and changing it requires a migration of existing attachments. Plan the attachment storage strategy before deployment to avoid a costly migration later.

spec:
  attachments:
    storageType: "s3"
    s3:
      endpoint: "https://s3.us-east.cloud-object-storage.appdomain.cloud"
      bucket: "mas-manage-attachments"
      prefix: "inst1/"
      credentials:
        secretName: "s3-credentials"

Build Options: The build section controls which features are included in the Manage build. This includes language packs, add-ons, and optional modules. Changes to build options require a full pod rebuild, which can take 30-60 minutes depending on the environment. Plan build configuration carefully and avoid changing it frequently.

User Interface: The ui section controls UI settings including the default theme, language, and feature visibility. Some UI changes can be made without a pod rebuild, but structural changes require one.

The most common ManageWorkspace pitfall is making a change in production without testing it in a non-production environment. Because changes trigger a pod rebuild, a misconfigured ManageWorkspace can take the Manage application offline. Always test configuration changes in dev or test first, and document the change and its effects before applying it to production.

The second pitfall is not version-controlling the ManageWorkspace YAML. Because it is a Kubernetes custom resource, it can be exported and stored in a Git repository. This provides a history of configuration changes and a rollback path if a change causes issues. Use OpenShift GitOps or a similar tool to manage ManageWorkspace configurations declaratively.

The JSON Mapper: Integration Pattern of Choice

The JSON mapper in Maximo Manage 9.x has quietly become the integration pattern of choice for organizations moving to MAS. It replaces the complex XML-based integration framework of Maximo 7.6 with a streamlined JSON-based approach that is easier to configure, test, and maintain.

The JSON mapper allows administrators to define mappings between JSON payloads and Maximo business objects. The mapping is configured through the Integration Framework and supports both inbound and outbound integration. The mapper handles data transformation, validation, and error handling, and it integrates with the REST API endpoints that MAS exposes natively.

Here is an example of a JSON mapper configuration for an inbound work order integration:

{
  "mappingName": "INBOUND_WO_FROM_ERP",
  "objectStructure": "MXAPIWODETAIL",
  "direction": "INBOUND",
  "mapping": {
    "workOrderNumber": "WONUM",
    "description": "DESCRIPTION",
    "assetNumber": "ASSETNUM",
    "location": "LOCATION",
    "priority": "WOPRIORITY",
    "scheduledStart": "SCHEDSTART",
    "scheduledFinish": "SCHEDFINISH",
    "workType": "WORKTYPE",
    "craft": "CRAFT",
    "estimatedHours": "ESTDUR"
  },
  "validation": {
    "requiredFields": ["WONUM", "ASSETNUM", "WORKTYPE"],
    "fieldFormats": {
      "SCHEDSTART": "ISO8601",
      "SCHEDFINISH": "ISO8601"
    }
  },
  "errorHandling": {
    "onValidationError": "REJECT",
    "onDuplicateKey": "UPDATE",
    "logLevel": "INFO"
  }
}

This configuration maps a JSON payload from an external ERP system to the MXAPIWODETAIL object structure. The validation section ensures that required fields are present and that date fields are in ISO 8601 format. The errorHandling section defines what happens when validation fails (reject the payload) or when a work order with the same number already exists (update it).

The JSON mapper is particularly powerful when combined with Kafka event streams. MAS 9.x publishes domain events to Kafka topics, which external systems can subscribe to. This replaces the legacy JMS-based integration pattern and provides a more scalable, reliable integration architecture. The JSON mapper can be configured to consume events from Kafka topics and transform them into Maximo business objects.

The migration from legacy integration patterns to the JSON mapper and Kafka is not trivial, but it is worth the effort. Organizations that have completed the migration report faster integration performance, easier troubleshooting, and a significant reduction in custom integration code. The JSON mapper handles the data transformation that was previously done in custom Java code, and the Kafka event stream handles the asynchronous communication that was previously done through JMS queues.

Suite-Level vs Manage-Level Administration: The Split That Catches Everyone

One of the most confusing aspects of MAS 9.x for new administrators is the split between Suite-level administration and Manage-level administration. In Maximo 7.6, all administration was done in one place. In MAS 9.x, administrative responsibilities are divided between the MAS Suite level and the Manage application level, and understanding which settings live where is essential.

Suite-level administration includes user management, security, licensing, navigation, and the configuration of other MAS applications (Health, Predict, Monitor, Mobile, Visual Inspection). These settings are managed through the MAS Administration interface, not through the Manage application. User creation, role assignment, and security configuration are all done at the Suite level. The Suite-level admin interface also controls the AI Service configuration, including the AI Assistant and Work Order Intelligence.

Manage-level administration includes the traditional Maximo administration that administrators are familiar with: database configuration, automation scripts, integration configuration, workflows, escalations, cron tasks, and application configuration. These are managed through the Manage application's Administration module, which looks similar to the Maximo 7.6 administration interface but with some differences in navigation and available options.

The confusion arises because some settings that were in the Maximo 7.6 administration interface have moved to the Suite level, and some settings that were in property files are now in the ManageWorkspace custom resource. For example, user authentication is configured at the Suite level (using LDAP, SAML SSO, or local MAS credentials), but user security groups and their permissions are configured at the Manage level. This means that creating a new user is a two-step process: create the user at the Suite level, then assign them to security groups in Manage.

Here is a quick reference for the most common administrative tasks and where they live:

Administrative Task Level Where to Configure

User creation Suite MAS Administration > User Management

Authentication (LDAP/SSO) Suite MAS Administration > Security

AppPoints licensing Suite MAS Administration > Licensing

AI Assistant configuration Suite MAS Administration > AI Service

Security groups Manage Manage > Administration > Security Groups

Database configuration Manage Manage > Administration > Database Configuration

Automation scripts Manage Manage > Administration > Automation Scripts

Integration (JSON mapper) Manage Manage > Integration Framework

Workflows Manage Manage > Administration > Workflow Designer

ManageWorkspace settings OpenShift MaximoSuite CR / ManageWorkspace CR

Attachment storage OpenShift ManageWorkspace CR

The split is not arbitrary. It reflects the modular architecture of MAS, where the Suite provides the platform (authentication, licensing, user management) and each application provides its own business logic and configuration. Once administrators understand the split, it becomes intuitive. But during the initial transition, it is a common source of frustration.

The best practice for new MAS administrators is to create an administrative cheat sheet that maps common tasks to their location. This reduces the time spent searching for settings and helps onboard new administrators more quickly. The cheat sheet should be maintained as a living document, because the administrative interface evolves with each MAS release.

Practical Implications

Maximo Manage 9.x is a fundamentally different platform from Maximo 7.6, and the transition requires administrators to learn new patterns. Work Order Intelligence and the AI Assistant are not optional features that can be ignored; they represent the direction IBM is taking the platform. Organizations that adopt these features early gain a competitive advantage in maintenance efficiency and data quality. The ManageWorkspace custom resource is the new configuration hub, and it requires a declarative, version-controlled approach that many Maximo administrators are not accustomed to. The JSON mapper and Kafka event streams are the integration patterns of choice, replacing the legacy XML and JMS-based integrations. And the Suite-level vs Manage-level administrative split is a permanent change that reflects the modular architecture of MAS.

Bottom Line

Maximo Manage 9.x brings AI into daily maintenance workflows through Work Order Intelligence, duplicate detection, and the AI Assistant. The ManageWorkspace custom resource replaces property files and requires a declarative configuration approach. The JSON mapper and Kafka event streams replace legacy integration patterns. The administrative split between Suite-level and Manage-level is permanent and reflects the modular architecture. Administrators who embrace these changes and learn the new patterns will find that Manage 9.x is more capable, more integrated, and more maintainable than its predecessors. Those who resist the changes will spend their time fighting the platform instead of leveraging it.