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.

[Brad Tilton]

I disagree here. Using dictionary overrides and personalizing choices/labels per table, there's not really anything I can think of you can do with incident state that you can't do with the task state field. You're also using that state field on pretty much every other table extended from task, so it's a bit simpler to do it for incident as well.

[DrewW]

I agree with Brad, if ServiceNow is using the State field out of the box on the incident form then a new customer should use State and an Old customer should consider if it is worth switching or not.

[Tanaji Patil]

You are right Brad that we can't achieve anything more by using 'Incident State'. Or I might be missing something for which ServiceNow is providing this field OOB.

But I don't see any reason why to not go with it. Just because servicenow provides 'State' OOB on the form we should go with it doesn't make sense to me.

Use of 'Incident State' might not achieve anything more but reduces complications(specially for beginners) and work too. Also it makes the configuration less error prone as I have experienced people doing changes directly on the task field, unknowingly or in hurry, instead of the dictionary override.

[The SN Nerd · Accepted solution]

I personally don't like using Incident State, because when your Service Desk views all there work (task view) your states are not the same as the task states and it causes so much confusion and complaints. My opinion would be not to use Incident State.

[johnsgp]

It's taken me a while to get my head around this, especially because I had an ongoing issue that wasn't resolved by changing the usage of incident_state to use state instead.   I've now figured out what was causing that problem and it was a conflicting business rule.   So now reading through all the answers again and considering my experience so far, I find Paul Morris's answer the most helpful because it mentions the case of viewing all "tasks" (incidents, change requests, etc) uniformly and this seems to me to be a valuable consideration.   So I would go with using state for all my new work but would not worry about editing existing usage of incident_state.