Adding additional choices to Change Request Status field

[michaelcory]

One of our IT groups is requesting the addition of 7 more custom  Status values on Change Request form.   The additional status values would be used in workflow for this group, but may not apply to other groups that use Change Request.   My thought has always been that we should adhere to  a more global standard for all IT groups requesting changes, which means that we limit the Status selections to mostly out-of-box with a couple of exceptions.   Creating additional status values for certain groups seems to creep away from  the global standard approach.   One option I can think of to meet this group's workflow needs is to create a custom Status field that would be used by their group to drive their workflow, but not sure if this is better or if adding the 7 new Status options to the  existing 'state' field on the Change form is a  better option.

Is it  good practice to create additional Status fields on Change Request for specific groups,  or is it something that is recoommended NOT be done?   I don't know if it's something common that  other organizations do routinely, or if it leads to more congestion or  unforseen impacts.   Any guidance would be appreciated.

Thanks,

[Pradeep Sharma]

Hello Mike,

I don't see issues in adding new choice values. However, you might restrict those choice values to others users except group "XYZ".

Best Practices for State Field Choice Values:

When you configure choice values for the state field:

• Use a negative value to add a new active state field.
• Search for and study the business rules that use a state number filter on the Script and Conditions fields. You can use the Debug tool to trace the order of the business rule execution.

Customizing Choice Lists - ServiceNow Wiki

[michaelcory]

Thanks for information Pradeep!.   Helps alleviate some angst that I have in adding new State values to a current standardized CM process. The members involved that would only need to see the new state values span across multiple groups.   When creating a Change, they will be selecting a CI with a common "category" value.. I was thinking about using a Client Script with indexOf (CI.category) and g_form.removeOption to HIDE the new values for any CI's selected that don't have that Category.   Is there a better method to hide the state values?

Thanks,

[Pradeep Sharma · Accepted solution]

Thank you Mike for the update. The right solution is to use client scripts. Please also make sure you have "list_edit" ACL to prevent users from updating the records from the list.

Reference:

Client Scripts - ServiceNow Wiki

http://wiki.servicenow.com/index.php?title=Using_Access_Control_Rules

[michaelcory]

Great!   Thank you!

Mike