Mastering Maximo Manage Configuration: Automation Scripts, Workflows, and System Properties

Maximo Manage is the operational heart of the Maximo Application Suite. It is where assets are tracked, work orders are managed, preventive maintenance is scheduled, and inventory is controlled. But the out-of-the-box experience is just the starting point. Every organization customizes Maximo to match its business processes, and the depth of that customization determines whether Maximo feels like a flexible platform or a rigid constraint. The difference often comes down to how well the administrator understands the configuration layer.

This article is a technical deep dive into the three pillars of Maximo Manage configuration: automation scripts, workflow engineering, and system properties. We will explore the patterns and techniques that experienced administrators use to solve real problems without falling back on custom Java development. From complex workflow condition scripts using custom condition launch points to dynamic cache refreshes that keep environments stable without downtime, these are the tools that separate administrators from power administrators.

Whether you are on MAS 8.x or 9.x, these techniques apply. The automation scripting engine, workflow framework, and system properties infrastructure have remained consistent across the MAS versions, with incremental enhancements in each release. The examples and patterns described here are drawn from the active Maximo community and IBM documentation current as of mid-2026.

Automation Scripts: The Jython Power Tool

Automation scripts are the primary extension mechanism in Maximo Manage. They allow you to execute business logic in response to events (object save, attribute change, workflow step) without compiling or deploying Java code. Scripts are written in Jython (a Python implementation for the JVM) and run inside the Maximo application server process.

Script Types and Launch Points: Maximo supports several launch point types: - Object launch points: Trigger on save, update, delete, or add events for a specific MBO object - Attribute launch points: Trigger when a specific attribute value changes - Action launch points: Trigger from workflow actions or custom UI buttons - Custom Condition launch points: Evaluate a condition and return a boolean result for workflow routing - Integration Framework launch points: Trigger during MIF processing

The most powerful and underutilized pattern is the Custom Condition launch point. When SQL-based workflow conditions become too complex (involving multiple subqueries, cross-object logic, or dynamic thresholds), Jython scripting with the evalresult variable pattern provides a clean alternative.

Complex Workflow Condition Example: Bruno Portaluri's approach to complex workflow conditions demonstrates the pattern. Instead of building a convoluted SQL expression in the workflow condition builder, you create a Custom Condition launch point script:

```python

Launch Point: Custom Condition

Script: WOCOST_THRESHOLD_CHECK

Variables: :WORKORDERID (bound to WORKORDER.WONUM)

woset = mbo.getMboSet("WORKORDER") woset.setWhere("WONUM = :WORKORDERID") wo = woset.getMbo(0)

if wo is not None: actual_total = wo.getFloat("ACTLABCOST") + wo.getFloat("ACTMATCOST") + wo.getFloat("ACTSERVCOST") estimated_total = wo.getFloat("ESTLABCOST") + wo.getFloat("ESTMATCOST") + wo.getFloat("ESTSERVCOST")

if estimated_total > 0:
    variance = ((actual_total - estimated_total) / estimated_total) * 100
    if variance > 25:
        evalresult = True
    else:
        evalresult = False
else:
    evalresult = False

else: evalresult = False ```

This script checks whether actual costs have exceeded estimated costs by more than 25 percent. The evalresult variable is automatically read by the workflow engine to determine the branch. This is far more readable and maintainable than the equivalent SQL expression.

Exception Handling: Proper exception handling in automation scripts is critical. Bruno Portaluri's guidance on this topic resonated strongly with the community (154 reactions on LinkedIn), because silent failures in automation scripts can cascade through the system. The pattern:

```python

Proper exception handling pattern

try: woset = mbo.getMboSet("WORKORDER") wo = woset.getMbo(0)

if wo is None:
    # Log a warning instead of failing silently
    logger = MXServer.getMXServer().getLogger()
    logger.warn("WORKORDER not found for condition check")
    evalresult = False
else:
    # Business logic here
    cost_threshold = wo.getFloat("ESTTOTAL")
    actual_cost = wo.getFloat("ACTTOTAL")

    if cost_threshold > 0 and actual_cost > cost_threshold:
        evalresult = True
    else:
        evalresult = False

except Exception, e: # Log the exception with context logger = MXServer.getMXServer().getLogger() logger.error("Error in WOCOST_THRESHOLD_CHECK: " + str(e)) # Default to a safe value evalresult = False ```

Without this pattern, a script that encounters an unexpected null value or a database connection issue will fail silently. The workflow will take the default branch, and the administrator will have no idea why. The exception handling ensures the error is logged and the condition evaluates to a predictable default.

MIF JSON Mapping Workaround: Amin Chakri's technique for JSON mapping with Invocation Channels solves a real limitation in Maximo's integration framework. IBM's JSON Mapping feature supports Publish Channels and Enterprise Services but does not support Invocation Channels. The workaround uses an automation script to invoke the Maximo JSON mapper engine programmatically:

```python

Script: INVOKE_JSON_MAPPING

Purpose: Apply JSON mapping to Invocation Channel responses

from com.ibm.tivoli.maximo.integration import ExternalJSONMapper

Get the JSON mapper instance

json_mapper = ExternalJSONMapper()

Load the mapping by name

mapping_name = "MY_INVOCATION_MAPPING" json_mapper.loadMapping(mapping_name)

Get the Object Structure data

os_data = mbo.getString("RESPONSE_DATA")

Apply the mapping

mapped_json = json_mapper.mapJSON(os_data)

Return the mapped output as the outbound payload

mapped_bytes = mapped_json.getBytes("UTF-8") mbo.setValue("MAPPED_RESPONSE", String(mapped_bytes, "UTF-8")) ```

This pattern reuses existing JSON mapping configuration, avoids manual JSON construction in scripts, and maintains a clean separation between integration logic and transformation logic. It eliminates the need for custom Java development for this use case.

Workflow Engineering Beyond the Basics

Maximo's workflow engine is deceptively simple on the surface. You draw a diagram with nodes and arrows, configure conditions, and assign actions. But production workflows quickly become complex, with conditional branching, parallel task assignments, escalation handling, and interaction with automation scripts.

Conditional Branching with Custom Conditions: The workflow condition builder in Maximo provides a SQL-based expression editor. For simple conditions (checking a status, comparing a numeric field), this works fine. But for conditions that require cross-object logic, multiple aggregation steps, or dynamic thresholds, SQL expressions become unreadable and unmaintainable.

The Custom Condition launch point pattern described above is the solution. It moves the logic into a Jython script where you can use variables, loop through related MBO sets, perform calculations, and log intermediate values for debugging. The workflow diagram stays clean, and the condition logic is version-controlled and testable independently.

Task and Escalation Configuration: Workflows often include Task nodes that assign work to users or groups. Each Task node can have: - An assignment (to a person, person group, or owner group) - A duration (for escalation timing) - An escalation that fires when the task is not completed within the duration - A negative action branch that determines what happens when the escalation fires

A common pattern for supervisor approval workflows:

[Start] -> [Task: Supervisor Approval] | | (Approved) -> [Action: Set Status to APPR] -> [End] | (Rejected) -> [Action: Set Status to CAN] -> [Notification: Notify Requestor] -> [End] | (Timeout) -> [Escalation: Notify Manager] -> [Task: Manager Approval] | | (Approved) -> [Action: Set Status to APPR] | (Rejected) -> [Action: Set Status to CAN]

The escalation on the Supervisor Approval task routes to a Manager Approval task. This ensures that if the supervisor does not act within the specified timeframe, the request is not stuck indefinitely.

Workflow Performance: Workflows that involve complex conditions or large MBO set traversals can create performance issues. Each condition evaluation runs when a workflow instance reaches a decision node. If the condition triggers a SQL query that scans a large table without proper indexes, the workflow engine will block until the query completes.

Best practices for workflow performance: - Keep condition SQL simple. Use indexed columns (WONUM, SITEID, ORGID) in WHERE clauses. - Move complex logic to Custom Condition scripts where you can control the query scope. - Avoid workflow loops that re-evaluate conditions on every cycle. - Use the workflow validation tool to check for infinite loops before activating a workflow.

System Properties and Configuration Quick Wins

Maximo system properties control hundreds of configuration switches that affect how the application behaves. IBM's documentation provides a definitive reference guide to these properties, but many administrators are unaware of the quick wins available through simple property changes.

Key System Properties for Daily Administration:

| Property | Default | Purpose | Recommended Value | |----------|---------|---------|-------------------| | mxe.db.fetchResultLogThreshold | 1000 | Logs queries that return more than N rows | 500 (for better visibility) | | mxe.db.fetchStopLimit | 1000 | Stops fetching rows after N results | 2000 (if users need larger result sets) | | mxe.workflow.prefetchWorkflowNodes | true | Pre-fetches next workflow nodes for performance | true | | mxe.crontask.donotif | true | Enables email notifications from cron tasks | true (production) / false (dev) | | mxe.security.unsecurecol | false | Allows unsecure column access | false (always) |

Conditional UI for Data Accuracy: Julie Rampello's work on dynamic Conditional UI rules demonstrates how forms can adapt automatically based on data entry context. Conditional UI allows you to show, hide, require, or make read-only specific fields based on the values of other fields. This improves data accuracy and reduces user errors.

Example configuration: 1. Open the Conditional Expression Manager application 2. Create a condition: ASSETTYPE = 'LINEAR' (Expression: :ASSETTYPE = 'LINEAR') 3. Open the Application Designer for the Assets application 4. Configure the Linear Attributes section to be visible only when the condition is true 5. Deploy and test

This ensures that linear asset fields only appear when the asset type is Linear, preventing users from accidentally entering linear data for non-linear assets.

Cache Refresh Without Restart: Suren's technique for refreshing Maximo caches dynamically is a game-changer for environments where downtime is difficult to schedule. Instead of restarting the application server after a configuration change, you can trigger a cache refresh through the Live Session Cache or the Database Configuration application:

1. Go to Database Configuration > Select Action > Refresh Live Cache 2. Select the specific cache to refresh (or select all) 3. The cache refreshes without dropping active user sessions 4. New configuration takes effect immediately

This is particularly useful after: - Adding or modifying system properties - Changing workflow definitions - Updating escalation schedules - Modifying integration configurations

Bulk Delete Without SQL: Vivek Nagre's "No SQL, No Problem" approach introduces bulk delete options that functional users can safely use without DBA intervention. Instead of writing SQL DELETE statements (which bypass Maximo's business logic and can leave orphaned records), users can: 1. Use the List View filter to select records matching criteria 2. Select all matching records 3. Use the Delete action from the toolbar

This approach respects MBO relationships, cascade rules, and audit logging. For large deletes, the process may need to run in batches to avoid timeout issues.

Accessing Log Files Without Server Access: Mohamed Ghareeb outlines two practical methods for retrieving Maximo log files without needing backend server access: 1. Use the Logging application in Maximo (System Configuration > Platform Configuration > Logging) to view and download log entries directly from the UI 2. Use the REST API to query log entries programmatically

This empowers functional administrators to troubleshoot issues without escalating to the infrastructure team, reducing resolution time for common problems.

DBC Scripts for Database Customization: Vipul Kumar's coverage of DBC (Database Configuration) scripts highlights their role in managing database customizations. DBC scripts are XML files that define structural changes to the Maximo database (adding columns, modifying indexes, creating tables). They can be version-controlled and applied consistently across environments.

```xml

Custom Field 1

```

However, as Prajwal Padmanabha noted in the community discussion, the Script Builder tool from Maximo 7.6.x does not have a direct equivalent in MAS. This gap means administrators need to write DBC scripts manually or use third-party tooling. The "Uncover the Hidden Gems of MAS" series referenced by Rahul Raju covers some alternative approaches.

Unique Server Names in MAS Manage: In multi-pod MAS deployments, the Server Sessions tab shows which pods are active. Configuring unique server/pod names (as discussed by MoreMaximo) is vital for troubleshooting. When all pods show the same name, it is impossible to determine which pod processed a specific transaction. Unique names allow you to correlate log entries with specific pods, dramatically reducing troubleshooting time.

Maintenance Mode in MAS 9.1: Andrzej Wiecław's technical insights on maintenance mode handling in MAS 9.1 provide essential guidance for system administrators. The maintenance mode feature in MAS 9.1 has been refined with better integration with the operator reconciliation process, ensuring that maintenance windows are properly communicated to the cluster and that application updates do not conflict with active maintenance periods.

Practical Implications

The configuration techniques covered in this article share a common theme: they empower administrators to solve problems without custom Java development or infrastructure-level interventions. This matters because every custom Java class in your Maximo environment adds technical debt. Every time you need a server restart for a configuration change, you lose productivity. Every time a workflow condition is unreadable, future maintenance becomes harder.

The practical takeaway is to invest in Jython scripting skills within your administration team. The automation scripting engine is the single most powerful tool for extending Maximo without code. A team that can confidently write, debug, and maintain automation scripts can handle 90 percent of customization requests without escalating to developers or consultants.

For system properties, the recommendation is to maintain a documented inventory of all non-default properties in your environment. This inventory should include the property name, current value, default value, reason for the change, and the date it was changed. This documentation becomes invaluable during upgrades and troubleshooting, when you need to understand why the system behaves differently in one environment versus another.

For workflows, the recommendation is to use Custom Condition scripts whenever a condition expression would require more than two or three SQL clauses. The readability and maintainability improvement justifies the small overhead of script execution. And always, always implement proper exception handling in scripts that participate in workflow routing.

Bottom Line

Maximo Manage's configuration layer is deep and capable. Automation scripts with proper exception handling, workflow engineering with custom condition launch points, strategic system property tuning, and techniques like dynamic cache refresh and conditional UI are the tools that make the difference between a well-tuned system and a constant source of help desk tickets. The active Maximo community in 2026 continues to produce valuable technical content, and administrators who follow these discussions and adopt these patterns will find that Maximo is far more flexible than its reputation suggests. The key is to treat configuration as engineering: document your decisions, test in non-production, and invest in the skills of your team.