Adding a New Case Task State – Best Practice?

[RohitD027682673]

Hi Team,

We currently have four Case Task states: New, In Progress, Closed – Incomplete, and Closed – Complete, with several custom rules tied to these states.

One team has requested an additional state, and they do not want any actions or business rules triggered when a record is moved into this state.

• Is it acceptable to simply add this new value to the State choice list, or is there a recommended best practice for handling this scenario?

• Are there any considerations we should be aware of given the existing custom logic tied to the current states?

• Is it possible to make this state visible or selectable only for a specific team or queue?

Looking for guidance on the ideal and supportable approach.
Thanks in advance!

[Dr Atul G- LNG]

Hi @RohitD027682673 

---

Adding a new state is technically possible; however, the challenge is that it requires customization. You would also need to manage hide/show conditions based on specific scenarios.

Secondly, the OOTB (out-of-the-box) states already have built-in logic. If you introduce a new state, you will need to build the complete logic yourself or create custom logic to support it.

Additionally, you may need to update the OOTB case flow to properly incorporate the new state, especially if it affects related processes.

Bottom line: Adding a new state is not a recommended approach. It requires additional effort, development, and full regression testing of the entire OOTB process. Moreover, if ServiceNow introduces the same state in a future release, you may need to rework or reconcile your customization.

Instead, I suggest discussing with the client why a new state is required and evaluating whether the requirement can be achieved using OOTB functionality — for example, by adding validation, UI policies, or other configuration — rather than creating a completely new state.

[vaishali231]

hey @RohitD027682673 

Since you already have custom Business Rules and logic tied to the existing states, the main risk is not the new state itself — it is how your current logic is written. If you have rules that check things like state changes, numeric state values, or generic conditions such as “state changes to Closed,” those may still execute when the record moves into the new state.

Before adding it, I would suggest:

Review all Business Rules on Case Task (especially ones using state or changesTo)

Check Flow Designer flows

Check SLAs (start, pause, stop conditions)

Review any reporting or dashboards grouped by state

Search for hard-coded numeric state values

If the requirement is that absolutely no logic should trigger when moving into this new state, then your rules should be written explicitly for the states they are meant to handle, rather than using generic “state changes” conditions. In other words, make your automation intentionally target specific states and not rely on broad conditions.

Regarding visibility for only one team, yes that is possible. The common approach is:

Use a Client Script to remove that choice from the State field unless the Assignment Group matches the specific team.

Or use a write ACL on the State field to restrict who can set that value (stronger control).

Client-side removal is usually enough if the goal is just to prevent other teams from selecting it in the UI.

One more consideration: if this new value is not truly a lifecycle state but more of a classification (for example, a special handling scenario), it might be cleaner to use a Substate or a separate field instead of modifying the core State model. That keeps your lifecycle stable and avoids future maintenance issues.
*************************************************************************************************************
If this response helps, please mark it as Accept as Solution and Helpful.
Doing so helps others in the community and encourages me to keep contributing.

Regards
Vaishali Singh

[SohamTipnis]

Hi @RohitD027682673,

Yes, it is okay-ish to add choices to the state or field or any other choices field, but you have to be quite reasonable for doing that. Changes in any kind of field, whether it is a custom table or OOTB.

I would recommend considering whether this value truly belongs in the lifecycle. If it represents a special handling scenario rather than a core state, using a substate or a separate field might be cleaner. This helps keep the lifecycle stable and reduces future maintenance effort.

If you find my answer useful, please mark it as Helpful and Correct ‌😊

Regards,
Soham Tipnis
ServiceNow Developer ||  Technical Consultant
LinkedIn: www.linkedin.com/in/sohamtipnis10