When should I use "Incident State" in scripts/rules

[johnsgp]

I have found two built-in Business Rules which keep State (on the task table) and Incident State (on the incident table, which extends task) that keep these fields synchronised.

"Copy State to Incident State" has order=0 which means it runs first (since newly added scripts/rules default to order=100)

"Copy Incident State to State" has order=1,000,000 which means it runs last (?)

When I write my own client scripts and business rules for incidents, I would guess that I should update Incident State rather than State, otherwise my change will be overwritten by the "Copy Incident State to State" rule.   But is this really true?   I have seen a number of business rules that update State and seem to work for incidents.

What exactly happens when I change the state a) in a client script, b) within a business rule?   Is there a correct way to do this and a wrong way, or can either State or Incident State be edited in any script/rule/etc?

The reason for my question is partly curiosity and partly that I have had intermittent reversions of state after editing it on a form, and with dozens of business rules in play, I would like to rule out potential causes before starting to edit them.

[DrewW]

Incident State is a field on the incident table and should be, in my opinion, the only state field you edit when working with an Incident.   The "State" field is on the task table and should only be used, again in my opinion, when there is no other state field for a table.   It drives me a little nuts that this is the way it is and ServiceNow did not drop the Incident State in favor of the single state field.   I suspect this is a throw back to the early days of the system.

As for the values in the state field I have found that if there is no choice list for the state field for the specific table that you need to add a value that you will delete immediately so it will create a copy of the current states for the selected table.   Otherwise you will end up editing the selections for all of the tables that do not have there own set.

[Brad Tilton]

I've seen customers use both of these fields, but in the last few releases the State field is the one that shows on the form OOB, so I would use that one if given the choice. The two business rules are there just to sync the values for customers using the incident state field and whichever you use, the value will not be written over by those sync business rules.

[DrewW]

Interesting, Sometimes I think being a customer for 6 years and upgrading many times over that time has hurt us...

[Tanaji Patil]

In my opinion you should always go with the 'Incident State' field instead of 'State' field extended from task table because you can directly modify the 'Incident Field' as you need but you can't just go and modify the extended 'State' field. If you are using 'State' and you want it a bit different then you have to use dictionary override and then do the changes.

Anyway both the fields will be in sync so its better to go with 'Incident State'.