One great thing about being a freelance consultant is that I have the opportunity to work with many different clients and learn many cool tricks from other experts in the field. In this article, I take the liberty of sharing a few nice tricks for implementing Maximo workflow that I stole from other teams.
#1 Status-driven workflow
Designing a workflow for a complex process can be challenging, particularly when it involves multiple approval steps and status changes. In rare scenarios, the workflow may fail, requiring intervention from the Maximo administrator to manually stop it. This often results in the record needing a manual status change or being resubmitted through the workflow, which can be frustrating for users who have already reviewed and approved the record.
A status-driven workflow is an effective way to create dynamic, simple, and maintainable processes. The idea is to assign a distinct status to each key step in the process. When a record enters the workflow, its current status determines the path it follows, whether that’s routing it to the right assignee or triggering specific branching logic, as illustrated in the diagram below.
Upon being routed by the workflow assignee, the record is updated to a new status and is displayed in the Start Centre resultset of the next responsible person. With this approach, certain stages can be handled outside of the workflow by the simple status change action, and thus, the workflow design is much simpler. It also allows the administrator to redirect certain records by changing the status of a record in the rare cases that are not handled well by the workflow.
(Credit: I stole this from a national broadband company. I think it was developed by the IBM GBS team)
#2 Recursive Approval
In a typical procurement approval process, a Purchase Requisition (PR) or Purchase Order (PO) may need to pass through multiple approval levels based on its total value. For instance, an organization might define the following approval thresholds:
- Less than $1,000 – Buyer can self-approve
- Up to $10,000 – Team Leader approval
- Up to $50,000 – Line Manager approval
- Up to $250,000 – O&M Manager approval
- Over $250,000 – CEO approval
Depending on the value of the PO, it must be reviewed or endorsed by managers with increasingly higher levels of authority, as illustrated in the diagram below:
There are two main problems with implementing this process as-is in Maximo workflow designer:
- The branching logic can be significantly more complex if there are different approval levels applied to different department/cost-centre. For example, the Administrative function might only have 2 to 3 levels of approval while the Rolling Stock department might have 6-7 levels of approval.
- The value is hard-coded in each condition means it is more difficult to change
A smarter approach is to design the workflow so that it dynamically assigns the record to the supervisor of the current approver. This keeps the workflow flexible and easier to adapt, as shown in the diagram below:
When a record is routed, the workflow checks whether the total value of the PR or PO is within the router’s approval limit. If it is, the record is approved. If not, it’s escalated to the router’s supervisor. This logic repeats until someone with the required authority level approves the record.
This approach allows for an unlimited number of approval levels to be managed outside the workflow design. Approval limits are defined in the Limits and Tolerances section in the Security Groups application, while the approval hierarchy flows naturally through the Supervisor field in the People application, mirroring the organization’s reporting structure.
The key technique here is using a dynamic role in the assignment node – specifically, the role type ‘A set of data related to the login user’ – which enables the workflow to evaluate the current router’s supervisor dynamically.
For the condition, we can use the sample SQL Where condition below:
:totalcost <= (SELECT max(lt.polimit)
FROM groupuser gu
LEFT JOIN limittolerance lt ON lt.groupname = gu.groupname AND lt.orgid = 'EAGLENA'
WHERE gu.userid = :&USERNAME&)(Credit: I stole this approach from a metro operator in South Australia. I’m not sure who implemented it. Likely by their internal team)
#3 Extend standard approval logic
When approving a PO or Invoice, Maximo performs a range of complex validations before updating the record’s status to Approved. One key validation is checking the user’s Limits and Tolerances settings. However, there are cases where exceptions to standard rules are needed. For example, an organization might enforce a zero tolerance policy for invoice approval, but allow a 10% variance for certain services, such as projects.
A common approach to handle this is to set the tolerance limit to 10% and then build workflow logic to restrict its use – by calculating the variance and throwing an error if any non-project invoice exceeds 0%. But this can quickly become overly complex, as it requires checking multiple invoices and receipts to accurately mimic the standard three-way matching logic.
A much cleaner solution is to set the system-wide tolerance to 0% and use a custom Change Status automation script in the workflow. This script catches the specific “Exceeds Tolerance” exception and bypasses it when appropriate. To do this, the script reloads the record under a different security profile that has a higher variance limit, and then invokes the changeStatus method on the MBO object. An example script is shown below:
While not every organization has this exact requirement, however, the key takeaway is that you can leverage Maximo’s standard rules and restrictions, and selectively bypass specific errors by using the try/catch block.
(Credit: I stole this approach when I worked for a national gas distributor in Australia. I think the idea was originated by Biplab or someone from the BPD Zenith team)
