Maximo can enforce business logic in many ways. Each approach has some advantages and varying levels of technical skills to implement. Requiring a field on the screen can be approached in a few different ways.
The first approach to creating required fields in Maximo is by setting a field to “required” via Application Designer; this is an easy way to make a specific field required 100% of the time in a single application. This is an excellent option for users who only interact with a single application in Maximo and for which the field is always required. The second approach is helpful when a user wants to add conditional logic to the “required” field; this can be done by using data restrictions. These data restrictions can be implemented at a security group or global level. I find that Global Data Restrictions work well most of the time. This approach is more complex than the Application Designer change because you must write a where clause. This is a go-to solution in my tool bag since they are so versatile.
Both approaches are great because they can visibly show a field as “required” in the application. These approaches are efficient in the application while still being straightforward to implement and support. A disadvantage is that when a status on a work order is changed, a field that wasn’t required in the prior status may become required in the newly updated status. For example, a work order in WAPPR status is being moved to APPR status, and a field that wasn’t required in WAPPR status is required within APPR status; when the user goes to change the status, they will receive a generic error that a field is required. The other disadvantage is that conditional logic can only be as good as the implementor’s skills in writing a where clause.
Automation scripts shine in delivering complex logic with clear messages. Adding custom business logic on a record's status change is a great use case for automation scripts. I have used this approach on the change status of assets, work orders, service requests, purchase orders, and configuration items. I have found that automation scripts allow me to deliver targeted messages with logic that can be as complex as needed. I will share some common examples.
Utilizing an attribute-based launch point will allow the logic to fire each time the status changes. In the example below, I am implementing a validation of an asset change status. If you want to run the validation more often, you could use an object save launch point.
Pairing the automation script with a Maximo Message allows for specific and flexible messages to be given to the user. For each automation script I implement, I like to have a corresponding message with a parameter to which I can pass a message. This message is configured in Database Configuration within the Messages dialog. The “{0}” will be the parameter we pass with a custom message.
Once you have a message in the automation script, you can call an error utilizing the message. Note that the first two parameters indicate the message to be used. The third parameter is an array that gets passed to the message. When called, the “{0}” in the message will replace the first string in the array. Adding a “{1}” to your message would map to the second value in the array.
service.error(“emx”,”assetStatusValidation”,[“Address are required to move to ACTVE status.”])
if mbo.getString("STATUS")=="ACTIVE" and mbo.isNull("emxAddress"):
service.error(“emx”,”assetStatusValidation”,[“Address are required to move to ACTVE status.”])
if mbo.getString("STATUS")=="OPERATING":
mboSetAssetSpec= mbo.getMboSet("$EMXASSETSPECREQUIRED","ASSETSPEC","assetnum = :assetnum and siteid=:siteid”)
mboAssetSpec = mboSetAssetSpec.moveFirst()
while mboAssetSpec:
if mboAssetSpec.isNull("ALNVALUE") and mboAssetSpec.isNull("NUMVALUE") and mboAssetSpec.isNull("TABLEVALUE"):
service.error("emx","assetStatusValidation",["Asset Spec " + mboAssetSpec.getString("ASSETATTRID") + " is required to not be null"])
mboAssetSpec = mboSetAssetSpec.moveNext()
if (mbo.getString("STATUS") == "COMP" ):
mboSetTask = mbo.getMboSet("$EMXWOTASK","WOACTIVITY","historyflag=0 and istask=0 and status!="COMP" and parent=:wonum and siteid=:siteid")
if (not mboSetTask.isEmpty())
service.error(“emx”,”woStatusValidation”,[“This work order has “+mboSetTask .count()+“ open child work orders that must be complete to complete this work order.”])
