Best practice to Adding Custom state values for catalog tasks

[Navneet3]

Hi

What is the best practice or advice to Add Custom state values for catalog tasks?

thank you

[jMarshal]

Understand the difference between "state" and "stage"! State is generally for internal (IT) purposes to support automation, triggers, lifecycle, metrics, reports, etc. Stage is a customer-facing value to give the end user information about the status of their request. Often, custom stages are used to provide more useful/specific information to the end-user about what they are waiting on, related to the fulfillment of their request. Also, don't forget to include steps in your flow, to update the RITM with your custom stage/state - if not managing that manually via process, with your technicians/agents. Hope this helps!!

[SanjivMeher]

Below link should help

https://www.servicenow.com/community/now-platform-forum/list-of-best-practices-choice-values-to-use-...

There is no such best practice. But sc_task uses choice list defined for task table. So you first need to build a choice list just for sc_task. So basically configure choice and add your values. 

Once you do that, open the dictionary and in the choices search by sc_task and you will find choices specific to sc_task.

I would try to make adjustments here. Mark any choice inactive true or try to rename few states based on my requirements. Many people don't like Close Incomplete, so that they change it to Cancelled.

[ersureshbe]

Hi, Simple practise -

1. Dont overwrite the OOB items and Create new items without disturbing OOB features

2. Order the values with Ascending

3. Display and Database values should be highlighted with proper naming conventions

4. Dont delete the OOB values instead of make it as Inactive state.

[Ryan Duce]

Hi Navneet. The out-of-box catalog task states should not need customising as the intention of a catalog task is to be a simple step in a wider more complex process. Customising the state model should be heavily challenged when requirements gathering as there is normally another way of getting what you need.

Intended use of the state fields on catalog tasks:

• Pending: task has been generated but not ready to start work yet
• Open: task is ready to start work but hasn't yet been assigned
• Work in progress: task has been assigned and an agent is actively working on it
• Closed complete: task has been completed fully and successfully
• Closed incomplete: task has been completed partially
• Closed skipped: task has been skipped completely with no work taking place on it.

What are the additional states that you are being asked to add? What business value do they add to the catalog task form, and are they worth the admin overhead of additional maintenance and support of the custom states with each new release?