Maximo Open Forum

Steven Shull posted 01-04-2022 10:18 Best Answer

Most importantly, welcome to the Maximo community. I know Maximo can be overwhelming to learn as people have been working with it for decades and it can serve so many distinct purposes. Thankfully the Maximo community is very welcoming. One of the things you'll learn about Maximo is there are often multiple ways to do something. This is one of those scenarios and the best option will vary based on the organization and the desired functionality. So I'll try to explain some of the options and the pros/cons of each.

Escalations: Escalations are great at sending notifications or invoking other actions on a set of records that you can identify with a SQL where clause. Escalations are evaluated on a schedule (every 5 minutes for example). If you want something real-time, escalations are not a good choice as you'll always have a delay. And I don't recommend going more frequently than 5 minutes for an escalation.

You need to be careful that you design the escalation in a way that won't spam your users and ensure that it meets your objective. For example, most people forget to add some logic to the where clause to exclude existing records and when they first activate the escalation it starts sending a lot of emails to their users. It's also possible to enter and leave the state between executions of the escalations causing the action to not occur. For example, if you change it from status A to status B an escalation for status A might not send if it doesn't run before the change to status B occurs. If you need the message to occur, I would choose a different approach or recommend running on WOSTATUS instead of WORKORDER to ensure that the email is sent.  

Automation Scripts: This is a large topic with a lot of different options as to how and when you run it based on the launch points. My primary feedback for automation script development is try to minimize the amount of times the script fires and try to keep your scripts legible. I've had to triage very large scripts that don't break their code into logical functions and some that even utilized the same public variable for different purposes. I always try to write a script with the assumption that someone else will have to maintain it for me so the code needs to be easy to follow. 

For this scenario I'd suggest doing an automation script Attribute launch point on WORKORDER.STATUS with the Run Action event. This is because it would fire only when the status is changed and would occur after validation has passed on the change. Other launch points (such as Object Save) you could utilize and check that the status has changed but it's easier if you just have the appropriate launch point. And it reduces the amount of code you have to write. 

Automation scripts are very powerful. You can loop through data sets, make API calls to other systems, perform conditional logic to send different communications, etc. They fire real-time on events so you don't have a delay. One of the most difficult decisions is you have to make a choice whether you want an error in your script (such as unable to send the email) to cause the transaction to fail or if you'd rather lose the communication. What I mean by that is by tying your email to a Maximo event (such as the attribute Run Action), if the script generates an error (either by you or the framework), that transaction (the change status) will typically get rolled back. You could wrap your logic in a try catch to avoid the error but then if your code failed, the communication would never be sent. An escalation since it runs on a schedule will process the record until it succeeds or it no longer matches the criteria. 

Automation scripts are not officially supported, whereas escalations and workflow are. That means if you have issues you typically won't get support from IBM support for an automation script. And as the infamous saying goes, "with great power comes great responsibility". Automation scripts can violate business rules (potentially causing data integrity issues), are more likely to impact performance (with poorly written code), and can lead to other issues (infinite loops, failure to close data sets, etc.). 

Workflow: Another common option, especially with status related progressions like this, is workflow. Some organizations depend very heavily on workflow and others honestly don't touch it. When you have a defined progression (WAPPR->Department Approval->Purchasing Approval for example) a workflow is typically a better option. You can disable status changes on the record outside of the workflow so that you ensure the records are processed as you expect. You can use conditional nodes to have different logic based on the type of record, cost, user, etc. Inside a workflow, your users can even make status changes that the user doesn't have permission to do. 

At each of those points you have workflow assignments that will show up on the users start center that they can approve or reject to progress in the workflow. You can even have workflow delegation so that when someone is unavailable (vacation for example) you can route to their delegate instead.