Maximo Manage 9.2: Configuring the Role-Based Application Model and Admin Layer

Maximo Manage 9.2, released as part of MAS 9.2 on June 25, 2026, is the latest iteration of the core EAM application that powers asset-intensive operations worldwide. The release builds on the role-based application model introduced in 9.1, refines the administrative tooling, and adds configuration capabilities that reduce the need for Java-level customization. For administrators and configuration leads, the challenge is understanding which tool handles which function, how the admin responsibilities are split between MAS Suite and Manage, and how to configure the role-based applications for different user personas.

This deep dive walks through the admin layer in Manage 9.2, the role-based application model built on the Maximo Application Framework (MAF), the configuration tools that remain from the classic Maximo toolkit, the new tools that IBM has added, and the practical patterns for configuring applications for different user types. We will cover the Operational Dashboard, automation scripts, workflow designer, database configuration, and the in-MAS Application Configuration tool, with code examples and configuration snippets throughout.

The Admin Split: MAS Suite vs. Manage

The first thing that trips up administrators new to MAS is the split of administrative responsibilities between the MAS Suite level and the Manage application level. In classic Maximo, everything was in one place. You logged into the Maximo admin console and handled user management, database configuration, security, and application configuration from a single interface. In MAS, some functions moved to the Suite level and others stayed in Manage.

MAS Suite-level administration handles user management, licensing, workspace configuration, identity provider integration, and the overall platform health. You access these functions through the MAS admin console, which is a separate interface from the Manage application. User management in MAS uses SCIM 2.0 for synchronization with external identity providers, and you can configure multiple identity providers for the same authentication type. This means that you can have different identity providers for different user populations, which is useful for organizations with mixed internal and external users.

Manage-level administration retains the core configuration tools that Maximo practitioners know: Database Configuration, Application Designer, Security Groups, Domains, Workflow Designer, and Automation Scripts. These tools are accessed from within the Manage application, and they control how the EAM application behaves. The database configuration tool lets you add custom fields, modify indexes, and configure relationships between objects. The Application Designer lets you modify the UI layout of applications. The Workflow Designer lets you define approval workflows and status transitions.

The admin split means that some workflows span both environments. For example, when you create a new user in MAS, the user is created in the MAS user registry. But the user's permissions within Manage are controlled by the Security Groups configuration in Manage. You need to assign the user to a security group in Manage, and that group determines what the user can see and do within the Manage application.

Here is a practical example of the admin split for a common workflow:

-- Step 1: User created in MAS Suite admin console
-- (No SQL needed - done via MAS admin UI or SCIM sync)

-- Step 2: In Manage, assign user to a security group
-- This is done via Security Groups application
-- Example: Assign user 'jdoe' to 'TECHNICIAN' group

-- Step 3: Verify the user's permissions in Manage
SELECT DISTINCT g.groupname, p.appname, p.optionname
FROM maxgroups g
JOIN groupauth p ON g.groupname = p.groupname
WHERE g.groupname = 'TECHNICIAN'
ORDER BY p.appname, p.optionname;

-- Step 4: Verify user is in the group
SELECT username, groupname
FROM groupuser
WHERE username = 'jdoe' AND groupname = 'TECHNICIAN';

The in-MAS Application Configuration tool is a newer addition that allows administrators to configure application-level settings without using Application Designer. You can set UI themes, navigation options, default values, and field labels through a configuration interface rather than modifying the application XML. This is part of IBM's strategy to move configuration from code-level changes to configuration-level changes, reducing the need for Java expertise and making it easier for administrators to make changes without engaging developers.

The Role-Based Application Model: MAF and the End of Work Centers

The most significant change in Manage 9.1 was the removal of the legacy Work Centers and their replacement with role-based applications built on the Maximo Application Framework (MAF). Manage 9.2 continues this model and adds refinements. The role-based applications are designed around specific user personas: the Work Order Summary for supervisors, the Inspection Forms application for inspectors, the Asset and Location dashboard for asset managers, and the new Work Queue Manager for planners.

Each role-based application is a focused interface that shows the user what they need to do their job, without the overhead of the full Maximo application. A technician does not need to see the Database Configuration application or the Workflow Designer. A supervisor does not need to see the Automation Scripts application. The role-based model ensures that each user sees a clean, focused interface that matches their workflow.

The MAF is the underlying framework that powers these applications. It is a low-code development platform that uses a declarative configuration model. You define the application layout, data sources, actions, and security through configuration files, not through Java code. This makes it faster to build and modify applications, and it makes the applications more portable across MAS versions.

Here is an example of how a MAF application is configured:

{
  "app": "workordersummary",
  "label": "Work Order Summary",
  "datasources": [
    {
      "name": "woList",
      "object": "WORKORDER",
      "query": "status in ('WAPPR','APPR') and owner = :user",
      "sort": "changedate desc",
      "pageSize": 50
    }
  ],
  "views": [
    {
      "name": "list",
      "type": "grid",
      "columns": ["wonum", "description", "status", "priority", "schedstart"],
      "actions": ["approve", "reject", "raiseFollowup"]
    },
    {
      "name": "detail",
      "type": "form",
      "fields": ["wonum", "description", "status", "priority", "assetnum", "location", "schedstart", "schedfinish"],
      "sections": ["worklog", "materials", "labor"]
    }
  ],
  "security": {
    "groups": ["SUPERVISOR", "MANAGER"],
    "actions": {
      "approve": "APPR",
      "reject": "WAPPR"
    }
  }
}

The configuration defines the data source (a query against the WORKORDER object), the views (a list view and a detail view), the actions available on each view, and the security groups that can access the application. This is a simplified example, but it shows the declarative nature of the MAF configuration. A developer does not need to write Java code to create or modify a MAF application. An administrator with knowledge of the Maximo data model and the MAF configuration syntax can build and maintain role-based applications.

In Manage 9.2, the MAF application configuration tool is being moved from a desktop-only tool to the MAS level. This means that the configuration tool will be accessible from the MAS admin console, not just from a local Docker container. The architectural change simplifies the configuration workflow, because administrators no longer need to install and maintain Docker on their local machines to run the configuration tool. The tool will be bundled with the MAS core image, but it will not be installed automatically on production environments where it is not needed. This requires persistent storage for the configuration files.

Operational Dashboard: Configuration and Best Practices

The Operational Dashboard is one of the most significant additions to the Manage admin toolkit. Introduced in MAS 9.0 and enhanced through 9.1 and 9.2, the dashboard provides interactive, role-specific views of key metrics and data. Unlike the classic Start Center, which was user-customizable and often inconsistent across an organization, the Operational Dashboard is administrator-configured and assigned to security groups. This ensures that users in the same role see the same dashboard, which improves consistency and reduces the support burden.

Dashboard configuration is a new admin responsibility. Administrators create dashboard templates, assign them to security groups, and configure the data sources that feed the dashboard widgets. The data sources can be SQL queries or REST API calls, and the widgets can display data in various formats: tables, charts, gauges, and lists. The dashboard is not user-customizable in 9.2, so the admin needs to design dashboards that work for each role.

Here is an example of a dashboard configuration for a maintenance supervisor:

{
  "dashboard": "supervisor_overview",
  "label": "Supervisor Overview",
  "securityGroup": "SUPERVISOR",
  "widgets": [
    {
      "type": "kpi_card",
      "title": "Open Work Orders",
      "dataSource": "count_open_wo",
      "position": {"row": 1, "col": 1, "size": "small"}
    },
    {
      "type": "kpi_card",
      "title": "Overdue PMs",
      "dataSource": "count_overdue_pm",
      "position": {"row": 1, "col": 2, "size": "small"}
    },
    {
      "type": "chart",
      "title": "Work Orders by Priority",
      "dataSource": "wo_by_priority",
      "chartType": "bar",
      "position": {"row": 2, "col": 1, "size": "medium"}
    },
    {
      "type": "table",
      "title": "Awaiting Approval",
      "dataSource": "wo_awaiting_approval",
      "columns": ["wonum", "description", "priority", "requestdate"],
      "position": {"row": 2, "col": 2, "size": "medium"}
    }
  ],
  "dataSources": [
    {
      "name": "count_open_wo",
      "type": "sql",
      "query": "SELECT COUNT(*) FROM WORKORDER WHERE STATUS IN ('WAPPR','APPR','INPRG') AND OWNER = :USER"
    },
    {
      "name": "count_overdue_pm",
      "type": "sql",
      "query": "SELECT COUNT(*) FROM WORKORDER WHERE STATUS = 'WAPPR' AND ISTASK = 0 AND PMID IS NOT NULL AND TARGSTART < SYSDATE"
    },
    {
      "name": "wo_by_priority",
      "type": "sql",
      "query": "SELECT PRIORITY, COUNT(*) AS CNT FROM WORKORDER WHERE STATUS IN ('WAPPR','APPR','INPRG') GROUP BY PRIORITY ORDER BY PRIORITY"
    },
    {
      "name": "wo_awaiting_approval",
      "type": "sql",
      "query": "SELECT WONUM, DESCRIPTION, PRIORITY, REQUESTDATE FROM WORKORDER WHERE STATUS = 'WAPPR' AND OWNER = :USER ORDER BY REQUESTDATE DESC FETCH FIRST 20 ROWS ONLY"
    }
  ]
}

The best practice for dashboard configuration is to start with the user persona. What does a supervisor need to see when they log in? They need to know how many work orders are open, how many are overdue, and which ones need approval. They need to see work orders by priority to understand the workload distribution. The dashboard should answer these questions at a glance, without requiring the user to navigate to multiple applications.

A common mistake is to put too many widgets on a single dashboard. Dashboards with 10 or 12 widgets become cluttered and hard to read. The best dashboards have 4 to 6 widgets that are focused on the most important metrics for the role. If you need to show more data, create a second dashboard and let users switch between them.

Automation Scripts and Workflow Designer: Where Each Fits

Automation Scripts and Workflow Designer are two of the most powerful configuration tools in Manage, and they serve different purposes. Understanding when to use each is essential for building maintainable configurations.

Workflow Designer is for process orchestration. It handles approval routing, status transitions, and notifications. A workflow is a visual representation of a business process, with nodes for each step and conditional branches for decision points. Workflows are ideal for processes that involve multiple people, multiple steps, and defined approval chains. The classic example is a work order approval workflow: a work order is created, routed to a supervisor for approval, if approved it is routed to a planner for scheduling, if rejected it goes back to the requestor with a reason.

Automation Scripts are for logic that runs at a specific point in the application lifecycle. An automation script can be triggered by a status change, a field update, or an object save. Scripts are written in Jython or JavaScript, and they have access to the Maximo business object model through the MBO API. Automation scripts are ideal for calculations, validations, and integrations that need to run automatically when data changes.

Here is an example of an automation script that calculates a priority based on asset criticality and failure severity:

# Automation Script: Calculate Priority
# Launch Point: WORKORDER - Before Save
# Script Type: Python (Jython)

from psdi.mbo import MboConstants

wo = mbo
assetCrit = 0
failSeverity = 0

# Get asset criticality
assetSet = wo.getMboSet("ASSET")
if not assetSet.isEmpty():
    asset = assetSet.getMbo(0)
    assetCrit = asset.getInt("CRITICALITY")

# Get failure severity from failure class
failSet = wo.getMboSet("FAILURECODE")
if not failSet.isEmpty():
    fail = failSet.getMbo(0)
    failSeverity = fail.getInt("SEVERITY")

# Calculate priority: higher criticality + severity = higher priority
combined = assetCrit + failSeverity
if combined >= 8:
    wo.setValue("PRIORITY", 1)
elif combined >= 5:
    wo.setValue("PRIORITY", 2)
elif combined >= 3:
    wo.setValue("PRIORITY", 3)
else:
    wo.setValue("PRIORITY", 4)

The script reads the asset criticality and failure severity, combines them, and sets the work order priority. This is a simple example, but it shows the power of automation scripts: you can implement business logic that would require Java customization in classic Maximo using a Jython script that is easier to write, test, and maintain.

In Manage 9.2, the workflow designer has been enhanced with new node types and better integration with automation scripts. You can now call an automation script from a workflow node, which allows you to combine the visual process modeling of workflow with the computational power of automation scripts. The recommended pattern is to use workflow for the process flow and automation scripts for the business logic at each step.

Exception handling in automation scripts is a critical topic that Bruno Portaluri and other community contributors have highlighted. When an automation script encounters an error, the behavior depends on how the script handles the exception. If the script does not catch the exception, the error propagates to the user as a generic error message, and the transaction may roll back. If the script catches the exception and logs it, the error is recorded but the transaction continues, which may leave data in an inconsistent state. The best practice is to catch exceptions, log them with context, and re-raise them as user-friendly error messages.

Database Configuration and DBC Scripts: Managing Schema Changes

Database Configuration is the tool for managing schema changes in Maximo. You add custom fields, modify indexes, create custom objects, and configure relationships between objects. In MAS 9.2, the Database Configuration application retains the same interface that Maximo practitioners have used for years, but the underlying mechanism for applying changes has evolved.

DBC (Database Configuration) scripts are the mechanism for applying schema changes in a controlled, repeatable way. Instead of making changes directly in the Database Configuration application on production, you create a DBC script that defines the changes, test it in a non-production environment, and then apply it to production. DBC scripts are XML files that describe the schema changes, and they can be version-controlled and tracked in a CI/CD pipeline.

Here is an example of a DBC script that adds a custom field to the WORKORDER object:

<?xml version="1.0" encoding="UTF-8"?>
<dbc>
  <table name="WORKORDER">
    <column name="XX_VIBRATION_READING" type="DECIMAL" precision="10" scale="2">
      <title>Vibration Reading</title>
      <description>Latest vibration reading from condition monitoring</description>
      <default>0.00</default>
    </column>
  </table>
  <index name="XX_WO_VIBRATION_IDX" table="WORKORDER" unique="false">
    <column name="XX_VIBRATION_READING"/>
  </index>
  <attribute name="XX_VIBRATION_READING" object="WORKORDER">
    <domainname>MEASURE_READING</domainname>
    <required>false</required>
    <readonly>false</readonly>
  </attribute>
</dbc>

The script adds a custom field called XX_VIBRATION_READING to the WORKORDER table, creates an index on the field, and configures the attribute with a domain for measurement readings. This DBC script can be tested in development, reviewed by the team, and applied to production through the DBC script runner in the Database Configuration application.

In MAS 9.2, the DBC script runner has been enhanced to support better error reporting and rollback. If a DBC script fails partway through, the system can roll back the changes without leaving the database in an inconsistent state. This is a significant improvement over previous versions, where a failed DBC script could leave the database in a partially modified state that required manual intervention to fix.

The Script Builder gap in MAS is worth noting. In classic Maximo, the Script Builder tool provided a visual interface for creating automation scripts. This tool is not available in MAS, and practitioners have noted its absence. The workaround is to create automation scripts directly in the Automation Scripts application using the code editor, which provides a text-based interface for writing Jython and JavaScript scripts. While this is functional, it lacks the visual guidance of the Script Builder and requires more knowledge of the MBO API.

Practical Implications

For administrators configuring Manage 9.2, the practical takeaway is that the configuration toolkit is more powerful and more complex than ever. The admin split between MAS Suite and Manage means that you need to understand both environments. The role-based application model means that you need to understand the MAF configuration and how to build applications for different personas. The Operational Dashboard means that you need to understand data sources and widget configuration. And the continued use of classic tools like Database Configuration, Automation Scripts, and Workflow Designer means that you still need the Maximo configuration skills that have been valuable for years.

The teams that succeed with Manage 9.2 are the ones that invest in training. The MAF configuration model is new, and even experienced Maximo administrators need time to learn it. The Operational Dashboard requires a different skill set from the classic Start Center configuration. And the in-MAS Application Configuration tool, while simpler than Application Designer, requires knowledge of the configuration options and how they interact.

Bottom Line

Maximo Manage 9.2 is a mature, capable EAM application that preserves the depth of Maximo's asset management model while modernizing the user experience and adding configuration tools that reduce the need for Java customization. The admin layer is split between MAS Suite and Manage, which requires administrators to understand both environments. The role-based application model built on MAF delivers focused interfaces for different user personas, and the Operational Dashboard provides administrator-configured, role-specific views of key metrics. The classic configuration tools (Database Configuration, Automation Scripts, Workflow Designer) remain and have been enhanced, while new tools (in-MAS Application Configuration, MAF) provide additional options for configuring the application without code. Invest in training, document your configuration workflows, and take advantage of the new tools to reduce your reliance on Java customization.