The condition approach tied to domain values that Subhransu mentions is what most customers use to filter statuses. You're trying to get a condition to evaluate to true when you want it to be displayed. If you have multiple conditions we'll stop evaluating as soon as we get a match (all do not need to evaluate to true for the record). And you want these to be efficient conditions so use substitution variables like :&APPNAME& as much as possible. We try to evaluate the condition in memory when possible, then query dummy_table, then query the underlying table. If your condition is like wonum='1234' we'd try to evaluate in memory and fail, then query dummy_table which will fail because there is no wonum column on the table, then we'll query the table (workorder) like select count(*) from workorder where wonum='1234'.
I bring this up because I've seen people screw this up and do something like siteid='BEDFORD' and worktype='PM' instead of :siteid='BEDFORD' and :worktype='PM'. This results in a very different query because we will query to see if any record in the database has a site of BEDFORD and a work type of PM. We won't be confirming that the current record has those things.
For this specific scenario, also remember :&APPNAME& will NOT always be set. Think mobile applications, integrations (including REST API like work centers), etc. Make sure you handle null/empty strings as well.
You could use a retrieve list automation script on the WOCHANGESTATUS.STATUS attribute but it would take over all logic. You can't just use to filter values after the fact which makes it not a good choice.
In the latest MAS release we've added some hooks for automation scripts to interact with bean class events. I haven't had a chance to test it and it's not documented yet (it'll get posted here https://ibm-maximo-dev.github.io/maximo-autoscript-documentation/ when it is) but it could possibly solve this in the future when you get to that release.
------------------------------
Steven Shull
IBM
------------------------------