Any issue with making more states option available in tasks?

[cvillalpando]

Have a request to add some additional State options to tasks under a requested item. The act of adding these states doesn't seems difficult:

1. Right-click "State" in a task

2. Select "Configure Choices"

3. Shows "Tailoring: sc_tasks.state". The states they would like to have in tasks are a already available options that I can then move to the "Selected" table

4. Save

From reading I've been doing it sounds like some are of the opinion this is not a good practice.

Will I be breaking something by make some more states available as choices?

[AlpUtkuM]

This will be always flagged as needs review when you upgrade ServiceNow

Also, It's not good practise to customize one of the main commonly used field on the platform.

If I would be you, I would create a custom field on sc_task form called "On Hold Reason" and add options into this field.

Also, I would create UI Policy to control visibility of this new field to show It when state is Pending for example.

[Laveena-Agarwal]

Hi @cvillalpando 

Could you please let us know what is your requirement, based on that proper suggestion can be made.

Also please check in your instance if these are OOB choices or custom choices?, because I can't see them in my PDI

[Tanushree Maiti]

Hi @cvillalpando ,

Could you please elaborate the business justification of this change.

Asking because In ServiceNow (specifically in incident), the "On Hold" incident state is used when work is temporarily stalled due to external dependencies, typically pausing SLAs to avoid penalties.

Your change appears to be more significant. Do you have a plan to modify the SLA definition for SC Tasks to avoid Task SLA breaches?

Otherwise, at the fulfillment level, if a task is kept on hold indefinitely, the SLA will definitely be breached !