Beyond the Basics: Automation Scripts, System Properties, and the Modern Maximo Manage Toolchain

Maximo Manage has come a long way from the days of Java class files, MBO customizations, and WebSphere admin consoles. The modern Manage developer works with automation scripts, REST APIs, JSON mappings, and containerized deployments on OpenShift. The toolchain has evolved, and so have the best practices.

This article is a technical deep dive into four areas that every Maximo developer and administrator should understand in 2026: AI-assisted automation script modernization, the MIF JSON mapping workaround for Invocation Channels, system property governance, and what MAS 9.2 changes for the development workflow.

AI-Assisted Automation Script Modernization with Bob

IBM and the Maximo community have been investing heavily in AI-assisted development tooling. One of the most interesting developments in 2026 is Bob, an AI-powered building block specifically trained on Maximo coding patterns and best practices. Bob is not a replacement for Maximo developers. It is a productivity accelerator that analyzes existing automation scripts, identifies improvement opportunities, and suggests cleaner, more maintainable implementations.

How Bob Works

Bob operates through a five-stage pipeline: Discover, Analyze, Optimize, Validate, and Update. Here is what each stage does:

Discover. Bob reads all automation scripts from a Maximo instance via the Maximo MCP (Model Context Protocol) Server. This includes object launch-point scripts, action scripts, condition scripts, and integration scripts. The goal is to build a complete inventory of the automation landscape.

Analyze. Bob reviews each script for outdated, risky, or inefficient patterns. It looks for repeated code blocks, missing exception handling, logic that does not align with current Maximo standards, and performance bottlenecks. It also generates plain-language summaries of what each script does, which is invaluable for teams inheriting code they did not write.

Optimize. Based on the analysis, Bob suggests cleaner implementations. This might include simplifying complex conditional logic, extracting repeated code into reusable functions, improving variable naming, adding proper error handling, or replacing deprecated API calls with current equivalents.

Validate. This is the critical governance step. Bob checks that the optimized script still follows Maximo standards, uses the correct payload structure, and handles edge cases. In enterprise environments, you cannot just generate changes and deploy them. Validation ensures the optimization does not break existing functionality.

Update. Once recommendations are reviewed and approved by a Maximo developer or architect, the changes are written back through a governed process. Bob does not automatically overwrite production scripts. It produces recommendations that a human reviews and approves.

What Bob Looks For

Here are some of the patterns Bob identifies and the improvements it suggests:

Repeated code blocks. Many Maximo environments accumulate scripts that duplicate logic across multiple launch points. A validation that checks work order status might exist in five different object launch-point scripts with slight variations. Bob identifies these duplicates and suggests consolidating them into a shared library script.

Missing exception handling. Automation scripts that call external APIs or perform database operations without try/catch blocks are a common source of production incidents. Bob flags these and suggests appropriate error handling patterns.

Deprecated API usage. As Maximo evolves, certain APIs are deprecated in favor of newer alternatives. Bob knows the current Maximo API surface and flags scripts using deprecated methods.

Inefficient data access patterns. Scripts that load full MBO sets when they only need a single attribute, or that iterate through large collections without filtering, are flagged for optimization.

Here is a concrete example. Consider this automation script that validates work order status before allowing a status change:

// Before optimization: repeated logic, no error handling
var woStatus = mbo.getString("STATUS");
if (woStatus == "COMP") {
    errorgroup = "validation";
    errorkey = "cannotChangeCompletedWO";
}

Bob might suggest:

// After optimization: extracted validation, proper error handling
function validateWorkOrderStatus(mbo) {
    try {
        var status = mbo.getString("STATUS");
        var nonEditableStatuses = ["COMP", "CLOSE", "CAN"];

        if (nonEditableStatuses.indexOf(status) >= 0) {
            return {
                valid: false,
                errorGroup: "validation",
                errorKey: "cannotChangeCompletedWO"
            };
        }
        return { valid: true };
    } catch (e) {
        log.error("Status validation failed for WO " + mbo.getString("WONUM") + ": " + e);
        return {
            valid: false,
            errorGroup: "system",
            errorKey: "unexpectedError"
        };
    }
}

var result = validateWorkOrderStatus(mbo);
if (!result.valid) {
    errorgroup = result.errorGroup;
    errorkey = result.errorKey;
}

The optimized version is more maintainable, handles errors gracefully, and is easier to extend when new non-editable statuses are added.

Integrating Bob Into Your Workflow

Bob is not a one-time cleanup tool. It is designed to be integrated into the ongoing development workflow. The recommended approach is:

1. Run Bob against your development environment weekly to catch issues early
2. Review Bob's recommendations as part of your code review process
3. Use Bob's plain-language summaries to onboard new team members
4. Run Bob before major upgrades to identify scripts that may need attention

The Maximo MCP Server is the integration layer that connects Bob to your Maximo instance. It fetches scripts, passes them to the Bob optimization skill, and returns the optimized scripts and an optimization report. The MCP Server is part of the MAS 9.2 ecosystem and is available for earlier MAS versions through the Feature Channel.

MIF JSON Mapping for Invocation Channels: The Workaround

One of the most practical technical discoveries in the Maximo community this year comes from Amin Chakri, an IBM Maximo Technical Expert. He tackled a real constraint in Maximo integration work: IBM's JSON Mapping feature supports Publish Channels and Enterprise Services but explicitly does not support Invocation Channels.

This is a significant limitation. Invocation Channels are the mechanism for inbound integrations where an external system calls into Maximo. If you want to receive a JSON payload from an external system, transform it using Maximo's JSON mapping engine, and process it through an Object Structure, you are out of luck with the standard tooling. The documented approach requires either manual JSON construction in automation scripts or custom Java development.

Chakri's workaround uses a short automation script to invoke the Maximo JSON mapper engine programmatically. Here is the pattern:

// Invoke JSON mapper programmatically for Invocation Channel processing
var ExternalJSONMapper = Java.type("psdi.iface.jms.ExternalJSONMapper");
var JSONMappingMgr = Java.type("psdi.iface.jms.JSONMappingMgr");

// Get the mapping configuration
var mappingName = "YOUR_MAPPING_NAME";
var mappingMgr = new JSONMappingMgr();
var mapping = mappingMgr.getMapping(mappingName);

// Get the Object Structure data
var osName = "MXINVENTORY";
var osData = mbo.getMboSet("YOUR_RELATIONSHIP");

// Apply the mapping
var mapper = new ExternalJSONMapper();
var jsonOutput = mapper.applyMapping(mapping, osData);

// Convert to bytes for outbound payload
var jsonBytes = jsonOutput.getBytes("UTF-8");

// Return as response
response.setContentType("application/json");
response.getOutputStream().write(jsonBytes);

The key insight is that ExternalJSONMapper and JSONMappingMgr are public APIs within the Maximo integration framework. They are the same classes that Publish Channels use internally. By instantiating them directly in an automation script, you can reuse your existing JSON Mapping configurations without duplicating transformation logic.

The benefits of this approach:

• Reuse existing JSON Mapping configuration. You do not need to rewrite your JSON transformations in JavaScript or Java. The mapping definitions you already created for Publish Channels can be reused.
• No manual JSON construction in scripts. Building JSON by string concatenation in automation scripts is error-prone and hard to maintain. The mapper engine handles all the serialization.
• No custom Java development. This is pure automation script. No compilation, no deployment, no classpath management.
• Clean separation of integration logic from transformation logic. The automation script handles the integration flow (receive request, validate, process, respond). The JSON mapping handles the data transformation. Each concern is managed separately.

This pattern is particularly valuable for organizations migrating from Maximo 7.6 to MAS. In 7.6, many integrations used XML-based MIF processing with XSL transformations. In MAS, JSON is the preferred format, and this workaround provides a bridge for teams that want to modernize their integration layer without rebuilding every transformation from scratch.

System Properties: The Hidden Governance Layer

Anneli Dolff published an important piece on the IBM Community blog about why Maximo system properties matter more than most administrators think. Her core argument: system properties are not just configuration values. They are the hidden governance layer that shapes user behavior, integration behavior, and system performance.

The problem is that most Maximo environments accumulate system properties over years of upgrades, patches, and customizations without any governance. Properties are set to solve immediate problems and then forgotten. When something breaks after an upgrade, nobody knows which property is responsible or why it was set to a particular value.

Dolff recommends creating a system property baseline. The goal is not to document every property. Maximo has hundreds of them, and many are self-explanatory defaults that never change. The goal is to identify the properties that shape behavior users actually depend on.

Here is a template for a system property baseline:

Dolff suggests starting with the areas that create the most visible impact:

Flow. Properties that affect how work moves through the system. For example, properties that control whether a work order can be closed with open labor transactions, or whether a purchase order can be received against a closed work order.

Trust. Properties that affect data integrity. For example, properties that control whether duplicate asset tags are allowed, or whether meter readings can be entered outside expected ranges.

Documentation. Properties that affect what users see. For example, properties that control which fields appear on printed work orders, or whether long descriptions are included in reports.

Hierarchy understanding. Properties that affect how the system navigates relationships. For example, properties that control whether a location's GL account overrides an asset's GL account.

Automation. Properties that affect script and workflow behavior. For example, properties that control whether automation scripts can send email, or whether workflows can call external services.

Governance. Properties that affect security and compliance. For example, properties that control session timeout, password complexity, or audit logging.

The baseline should be a living document. Review it quarterly. Update it after every upgrade. Include it in your change management process. When someone proposes a system property change, the baseline tells you what else might be affected.

What MAS 9.2 Changes for Developers

MAS 9.2 brings several changes that directly affect the development workflow:

User management consolidation. As covered in the MAS Platform article, user records move entirely into Manage. For developers, this means automation scripts that reference user attributes should use the Manage user object rather than the MAS Core identity layer. If you have scripts that call MAS Core APIs for user information, those will need to be updated.

Communication template integration. In 9.2, all email flows through Manage's communication template engine. This means automation scripts can trigger communication templates with full substitution variable support. A script that creates a work order can also trigger a notification email with work order details, asset information, and assigned technician contact info, all using the communication template engine rather than manual email construction.

Operational Dashboard custom actions. The new custom action framework in Operational Dashboards lets you wire dashboard buttons to automation scripts. This opens up new patterns for supervisor and dispatcher workflows. A dashboard showing overdue work orders could include a "Reassign All" button that triggers a script to redistribute work based on technician availability.

MCP Server for AI integration. The Model Context Protocol Server in MAS 9.2 provides a standardized interface for AI agents to interact with Maximo Manage APIs. This is the integration layer that tools like Bob use to fetch scripts and push optimizations. For organizations building their own AI integrations, the MCP Server provides a documented, supported interface rather than requiring direct REST API calls.

Table download limits. A small but important change: MAS 9.2 caps table downloads at 200 records out of the box, down from unlimited in previous versions. This is a performance and security improvement, but it may affect integrations or reporting tools that relied on downloading large result sets. If you have scripts or integrations that pull large tables, test them against the 200-record limit and plan for pagination.

Practical Implications

Adopt AI-assisted code review. Even if you are not using Bob specifically, the pattern of AI-assisted script analysis is becoming standard practice. Start by inventorying your automation scripts. Identify duplicates, missing error handling, and deprecated API usage. If you have access to Bob or similar tools, run them against a development environment and review the recommendations.

Implement the JSON mapping workaround for Invocation Channels. If you are building inbound integrations that receive JSON payloads, use the ExternalJSONMapper pattern instead of manual JSON construction. It is cleaner, more maintainable, and reuses your existing mapping configurations.

Create a system property baseline this quarter. Start with the high-impact areas: flow, trust, documentation, hierarchy, automation, and governance. Document at least the properties that have been changed from defaults. Review the baseline with your team. Make it part of your change management process.

Prepare your scripts for MAS 9.2. Audit your automation scripts for dependencies on MAS Core user APIs. Update them to use Manage user objects. Test your email-triggering scripts against the communication template engine. Review your integration scripts for table download limits.

Invest in the MCP Server. If you are planning AI integrations with Maximo, the MCP Server is the supported integration path. Start exploring it in your development environment. Understand what it exposes and how to secure it.

Bottom Line

The modern Maximo Manage toolchain is more powerful and more complex than ever. Automation scripts have replaced Java customizations as the primary extension mechanism. AI-assisted tools like Bob are changing how teams approach code quality and modernization. The MIF JSON mapping workaround solves a real integration constraint without custom Java. System property governance is the difference between a stable environment and one that breaks unpredictably after every upgrade.

MAS 9.2 amplifies all of these trends. The user management consolidation simplifies the identity model but requires script updates. The communication template integration makes email more powerful but changes how scripts trigger notifications. The MCP Server opens the door to AI integration but requires new skills.

The common thread is governance. Whether you are managing automation scripts, system properties, integration mappings, or AI tooling, the organizations that succeed are the ones that treat these as managed assets rather than ad-hoc configurations. Document what you have. Review it regularly. Update it deliberately. Your future self, and your successor, will thank you.