Maximo Manage Configuration Deep Dive: Automation Scripts, Integration Framework, and Security in MAS 9.x

Maximo Manage is the core EAM application in the Maximo Application Suite, and for most organizations, it is where the majority of configuration and customization work happens. The move to MAS 9.x changed the deployment architecture, the user interface, and the AI capabilities, but the underlying configuration tools that administrators and developers use day to day remain fundamentally the same. Automation scripts, the integration framework, and the security model are the three pillars of Maximo Manage configuration, and mastering them is essential for getting the most out of the platform.

This article is a practitioner-level deep dive into these three areas in MAS 9.x. We will cover automation script patterns that work in production, the integration framework architecture and how to use it effectively, and the security model that governs access to data and functionality. Whether you are migrating from Maximo 7.6 or already on MAS 9.x, this guide covers the specific patterns, gotchas, and best practices that will save you time and prevent problems.

Automation Scripts: Patterns That Work in Production

Automation scripts are the primary extensibility mechanism in Maximo Manage. They allow you to add business logic, validate data, trigger actions, and integrate with external systems without modifying the core Maximo source code. In MAS 9.x, automation scripts run on the same Jython (Python for the Java platform) engine as in Maximo 7.6, but the execution context, launch point types, and available APIs have evolved.

There are three types of launch points in MAS 9.x: object launch points, attribute launch points, and conditional launch points. Object launch points fire when a record is created, updated, deleted, or queried in a specific Maximo business object. Attribute launch points fire when a specific attribute value changes. Conditional launch points fire when a defined condition evaluates to true. A common pattern is to combine conditional launch points with object launch points to create complex workflow logic that fires only when specific business conditions are met.

The most important production pattern for automation scripts is the guard clause. Every automation script should begin with a guard clause that checks whether the script should actually execute. Without guard clauses, scripts fire on every save, every update, and every status change, which creates performance problems and unexpected side effects. Here is a production-grade guard clause pattern:

# Guard clause: Only execute on WAPPR to APPR status change
mbo = scriptMbo
if mbo.isNull("status"):
    return
current_status = mbo.getString("status")
if current_status != "APPR":
    return
# Only run for work orders in theMaintenance org
if mbo.getString("orgid") != "THEMAINT":
    return
# Skip if already processed
if mbo.getBoolean("wsd_processed"):
    return
# Main logic starts here
wonum = mbo.getString("wonum")
assetnum = mbo.getString("assetnum")
# ... business logic ...
mbo.setValue("wsd_processed", True, 2L)

This pattern checks the status, organization, and a custom flag before executing the main logic. The 2L parameter in setValue is the access modifier flag, which tells Maximo that this is a system-level update that should not trigger additional validation rules or notifications. This prevents recursive script execution, which is one of the most common causes of automation script performance problems.

Another critical pattern is error handling. Automation scripts in Maximo do not have try-catch blocks in the traditional Python sense. Instead, you use the service.log method to log errors and the mboSet.setWarning method to display warnings to users. For critical errors that should abort the transaction, use mboSet.setError:

try:
    # Attempt to create a follow-up work order
    woSet = mbo.getMboSet("FOLLOWUP_WO")
    newWO = woSet.add()
    newWO.setValue("description", "Follow-up: " + wonum)
    newWO.setValue("assetnum", assetnum)
    newWO.setValue("siteid", mbo.getString("siteid"))
    woSet.save()
except Exception, e:
    service.log("ERROR", "Failed to create follow-up WO for " + wonum + ": " + str(e))
    mboSet.setWarning("Could not create follow-up work order. See system log for details.")

In MAS 9.x, automation scripts can also interact with the AI capabilities. You can use automation scripts to trigger Work Order Intelligence classification, send data to the Maximo Assistant, or invoke predictive models. The AI Service provides a REST API that automation scripts can call through the HTTP provider in the integration framework. This opens up possibilities like automatically classifying incoming work requests based on their description text or triggering a predictive model re-evaluation when an asset's condition data changes.

A common pitfall in MAS 9.x is the interaction between automation scripts and the new role-based applications. The role-based apps (Work Order Planning, Work Queue Manager, Dispatching Dashboard, etc.) are built on the Maximo Application Framework (MAF), which uses REST APIs to interact with the underlying business objects. Automation scripts that work correctly in the classic Maximo interface may behave differently in the role-based apps, because the MAF may save records in a different order or trigger events at different points in the lifecycle. Always test automation scripts in both the classic interface and the role-based apps to ensure consistent behavior.

Another pitfall is script performance in high-volume environments. Automation scripts execute synchronously within the Maximo transaction, which means a slow script blocks the entire transaction. For scripts that call external systems (HTTP web services, REST APIs, database queries), use the integration framework's asynchronous processing capabilities instead of making synchronous calls within the script. The pattern is to have the automation script write a message to a JMS queue or Kafka topic, and then have a separate integration process handle the external call asynchronously. This keeps the Maximo transaction fast and prevents external system latency from degrading Maximo performance.

For scripts that perform complex data operations, use the mboSet.setWhere method to filter records before iterating, rather than iterating through all records and checking each one individually. The database is always faster than the script engine for filtering data. Here is the pattern:

# Bad: Iterate and check (slow)
assetSet = mbo.getMboSet("ASSET")
asset = assetSet.moveFirst()
while asset:
    if asset.getString("status") == "OPERATING" and asset.getInt("priority") == 1:
        # process asset
        pass
    asset = assetSet.moveNext()

# Good: Filter in database (fast)
assetSet = mbo.getMboSet("ASSET")
assetSet.setWhere("status = 'OPERATING' and priority = 1 and siteid = '" + siteid + "'")
asset = assetSet.moveFirst()
while asset:
    # process asset
    pass
    asset = assetSet.moveNext()

The difference in performance between these two patterns can be orders of magnitude, especially on large asset databases. The setWhere approach pushes the filtering to the database layer, which is optimized for this type of operation. The iterate-and-check approach pulls all records into the script engine and processes them one at a time, which is never efficient.

Integration Framework: Architecture and Best Practices

The Maximo Integration Framework (MIF) is the backbone of cross-system communication in Maximo Manage. It handles inbound integrations (external systems sending data to Maximo), outbound integrations (Maximo sending data to external systems), and enterprise services (real-time sync with ERP, HR, and other systems). The MIF architecture in MAS 9.x is fundamentally the same as in Maximo 7.6, but the deployment context, performance characteristics, and monitoring capabilities have changed.

The MIF consists of several components: integration objects (which define the data structure), integration channels (which define the transport mechanism), endpoints (which define the connection to the external system), and processing rules (which define how data is transformed). In MAS 9.x, these components are configured through the Integration Applications in Manage, but the underlying execution happens in the MAS integration runtime, which runs as a set of pods in OpenShift.

For inbound integrations, the most common pattern is the JSON REST API. Maximo provides a REST API that external systems can call to create, update, query, and delete Maximo records. The API supports both structured JSON payloads and the Maximo XML format. In MAS 9.x, the REST API has been enhanced to support the OSLC (Open Services for Lifecycle Collaboration) standard, which provides a standardized way to interact with Maximo resources.

Here is an example of an inbound REST API call to create a work order:

{
  "description": "Emergency repair: cooling tower fan motor failure",
  "assetnum": "CT-FAN-001",
  "siteid": "BRTPLANT",
  "orgid": "UTILITIES",
  "worktype": "EM",
  "priority": 1,
  "reportedby": "SCADA_SYSTEM",
  "reportdate": "2026-08-06T10:30:00-05:00",
  "failurereport": true,
  "woclass": "WORKORDER"
}

This JSON payload is sent to the Maximo REST API endpoint (/maximo/oslc/os/mxapiwo/_POST) with appropriate authentication headers. The integration framework validates the data, applies processing rules, creates the work order, and returns a response with the generated work order number and status. The entire process is synchronous and typically completes in under 500 milliseconds for a single record.

For outbound integrations, the publish channel is the primary mechanism. A publish channel monitors Maximo business objects for changes and sends the changed data to an external system. The most common use case is publishing work order status changes to an ERP system for cost tracking. In MAS 9.x, publish channels can use REST, Kafka, or JMS as the transport mechanism. Kafka is recommended for high-volume integrations, because it provides guaranteed delivery, supports multiple consumers, and decouples the producer from the consumer.

The configuration of a Kafka-based publish channel in MAS 9.x looks like this:

<endpoint>
  <name>KAFKA-WO-STATUS</name>
  <description>Publish work order status changes to Kafka</description>
  <type>KAFKA</type>
  <connectioninfo>
    <bootstrap.servers>kafka-cluster-1:9093,kafka-cluster-2:9093,kafka-cluster-3:9093</bootstrap.servers>
    <topic>maximo-wo-status</topic>
    <security.protocol>SASL_SSL</security.protocol>
    <sasl.mechanism>SCRAM-SHA-512</sasl.mechanism>
    <ssl.truststore.location>/opt/mas/secrets/kafka-truststore.jks</ssl.truststore.location>
  </connectioninfo>
</endpoint>

This configuration defines a Kafka endpoint that publishes work order status changes to a topic called maximo-wo-status. The endpoint uses SASL_SSL for authentication and encryption, which is required for production deployments. The publish channel is then configured to use this endpoint and to trigger on status changes in the Work Order Tracking application.

Enterprise services are a third integration pattern, used for real-time synchronization with enterprise systems. MAS 9.x includes pre-built connectors for SAP (using CPI), Oracle, and Workday. These connectors extend the integration framework with pre-configured integration objects, processing rules, and endpoint definitions for common integration scenarios (purchase requisitions, purchase orders, goods receipts, invoices, timesheets). The SAP connector was updated in MAS 9.2 to use SAP Cloud Platform Integration instead of the older SAP Process Orchestration, which is a necessary modernization as SAP deprecates PO.

A critical best practice for integration framework configuration in MAS 9.x is the use of processing rules for data validation. Processing rules allow you to validate, transform, and enrich data before it is committed to Maximo. For inbound integrations, processing rules can validate required fields, set default values, look up related records, and reject invalid data before it creates problems in the database. For outbound integrations, processing rules can filter records (only send work orders above a certain priority), transform data formats (convert Maximo date format to ISO 8601), and add enrichment data (include asset description and location from related records).

Security Model: Users, Groups, and Permissions

The security model in Maximo Manage is one of the most powerful and complex aspects of the platform. It controls who can see what data, who can perform what actions, and how data flows between applications. In MAS 9.x, the security model has been enhanced with the User Management and Security UI improvements, but the underlying architecture remains the same as in Maximo 7.6.

Security in Maximo is built on four layers: authentication, authorization, data restrictions, and signature requirements. Authentication verifies who the user is. Authorization determines what applications and actions the user can access. Data restrictions filter the records the user can see. Signature requirements add an additional layer of approval for sensitive actions.

Authentication in MAS 9.x is handled through MAS Core's identity service, which integrates with LDAP, Active Directory, and SAML 2.0 identity providers. The identity service provides single sign-on across all MAS applications, so a user who logs into Manage can also access Health, Predict, Monitor, and Mobile without re-authenticating. For API integrations, MAS 9.x supports API keys with configurable expiry dates and certificates, which is a significant improvement over the basic API key mechanism in earlier versions.

Authorization is managed through security groups. A security group defines which applications a user can access, which actions they can perform within those applications, and which condition-based restrictions apply to their data access. In MAS 9.x, the security group configuration has been streamlined through the improved User Management UI, but the underlying model is the same: users are assigned to one or more security groups, and each group grants application access with specific action permissions.

Here is a production example of a security group configuration for a maintenance planner role:

Security Group: MAINT_PLANNER
Applications:
  - Work Order Tracking: READ, ADD, SAVE, DELETE (conditional)
  - Work Order Planning: READ, ADD, SAVE
  - Job Plans: READ, ADD, SAVE, DELETE
  - Preventive Maintenance: READ, ADD, SAVE
  - Assignments: READ, ADD, SAVE
  - Calendar: READ
  - Labor: READ
  - Assets: READ
  - Locations: READ
Data Restrictions:
  - Site restriction: WHERE siteid IN ('BRTPLANT', 'GRDPLANT')
  - Work type restriction: WHERE worktype != 'EM' (planners do not create emergency work)
  - Status restriction: Cannot approve work orders above $50,000 (conditional on esttotalcost)
Signature Requirements:
  - Approve work order > $10,000
  - Change PM frequency
  - Delete job plan

This configuration gives the maintenance planner role access to the applications they need, restricts their data to specific sites, prevents them from creating emergency work orders, and requires electronic signatures for high-value approvals. The signature requirement creates an audit trail that shows who approved each high-value work order, when the approval was made, and what the previous and new status values were.

Data restrictions are particularly powerful in MAS 9.x because they apply across all access methods. A data restriction defined on the Assets application applies whether the user accesses the asset through the classic Maximo interface, through a role-based MAF application, through the REST API, or through the Maximo Assistant. This is a critical security consideration: if you rely on data restrictions to control access to sensitive asset data, those restrictions will be enforced consistently across all access points, including AI-powered queries through the Maximo Assistant.

The Maximo Assistant's security context deserves special attention. When a user asks the assistant a question, the assistant queries the database using that user's security context. This means the assistant will only return records that the user is authorized to see. However, the assistant's natural language processing may sometimes phrase responses in ways that inadvertently reveal information about restricted records. For example, if a user asks "How many work orders are open in the southern region?" and the user only has access to the northern region, the assistant will not return restricted records, but it might respond "There are no work orders visible to you in the southern region," which implicitly confirms that work orders exist in the southern region. IBM is actively working on refining the assistant's response patterns to avoid these side-channel information leaks, but administrators should be aware of this behavior when configuring assistant access for users with restricted data access.

Common Pitfalls and Field-Tested Patterns

Even experienced Maximo administrators encounter configuration issues when moving to MAS 9.x. This section covers the most common pitfalls and the patterns that have been proven in production deployments.

The first pitfall is over-reliance on Java customizations. In Maximo 7.6, many organizations built custom Java classes for business logic that could not be implemented through automation scripts or configuration. In MAS 9.x, Java customizations are still supported, but they create significant upgrade challenges. Each MAS upgrade requires rebuilding and redeploying custom Java code, which extends the upgrade timeline and introduces compatibility risk. The recommendation is to migrate Java customizations to automation scripts wherever possible. Most business logic that was implemented in Java can be replicated in Jython automation scripts, and scripts do not require rebuilding on upgrade.

The second pitfall is neglecting the cron task configuration. MAS 9.x runs several critical processes as cron tasks: the Workflow agent, the Integration listener, the PM generator, and the Inventory reorder process. In the containerized MAS environment, these cron tasks run in the Manage server pods, and their execution is affected by pod resource limits and restart cycles. If a cron task is running when a pod restarts, the task may be interrupted, and the work may not be completed. Configure cron tasks with appropriate retry logic and monitor the cron task log for incomplete executions.

The third pitfall is underestimating the effort required to configure the integration framework for high-volume integrations. The default REST API configuration in Maximo is tuned for interactive use, not for high-volume batch processing. For integrations that process thousands of records per hour, you need to configure the thread pool, connection pool, and message processing settings to handle the load. The default settings can handle approximately 100 records per minute. For higher volumes, increase the integration worker pool size and configure batch processing to group records into batches of 50 to 100 to reduce the number of database transactions.

A field-tested pattern for managing configuration across environments is to use the Maximo Configuration Manager (MCM) or a custom configuration export/import process. In MAS 9.x, configuration can be exported from one environment and imported into another using the standard MIF XML format. This allows you to maintain a development, test, and production environment with consistent configuration, and to track configuration changes through version control. The configuration export should include automation scripts, integration objects, endpoints, security groups, and conditional expressions at a minimum.

Practical Implications

Configuring Maximo Manage in MAS 9.x requires a shift in mindset from Maximo 7.6. The core tools are the same, but the context in which they operate has changed. Automation scripts now interact with AI capabilities, the integration framework runs in a containerized environment, and the security model must account for new access methods like the Maximo Assistant and the MCP Server.

For automation scripts, the key takeaway is to always use guard clauses, handle errors gracefully, and test in both the classic and role-based application interfaces. For the integration framework, the shift to Kafka for high-volume integrations and the update of the SAP connector to CPI are the most significant changes. For security, the User Management UI improvements make administration easier, but the underlying model requires the same careful planning as in Maximo 7.6.

Bottom Line

Maximo Manage in MAS 9.x is a more capable platform than its predecessors, but the configuration tools that administrators and developers use remain the same. The key to success is understanding how these tools interact with the new architecture, the AI capabilities, and the expanded access methods. Automation scripts, the integration framework, and the security model are the three pillars of Maximo Manage configuration, and mastering them in the context of MAS 9.x will determine whether your implementation delivers the value the platform promises.