Incident state vs state on incident form

[varunp]

HI All,

What is the difference between Incident state vs state on the incident form?

Which field we should use on incident form and for defining incident SLA?

[Mike Patel]

State is from Task table and Incident state is from Incident table. There is out of the box business rule that sync both so changing incident state will change state too. You can define SLA on incident state.

[Strange]

The incident table is actually a child of the "task" table, and thus has columns from the task table passed down into it.

The "state" field is the passed down column from the task table, whereas the "incident_state" is a state field defined only on the incident table itself.

Out of box there are usually business rules that sync the two so they should effectively be the same values unless otherwise modified.

Generally you'll want to set the SLA's according to the task table, thus the regular "state" field should be sufficient.

[KamakshiM]

Hi,

  I created a UI policy to make the description field Read Only when State is Closed or Cancelled.

However, I found that in a new record, when I changed the State in the dropdown, the description field was changing to read only. 

But, if you look at the other fields, they are all still editable(though there is a UI policy to make them read only). Only in an existing record. did the read only policy seemed to work for other fields.

When I compared my UI policy with the existing UI policy, I found that mine used State while the existing UI policy used incident state.

When I changed my UI policy to use incident state instead of State, it worked fine(no read only in New Record).

Could somebody please explain this behavior and the difference between State and Incident State based on this?

[abhinavmakk]

This behavior is expected.

On the Incident form, the field exposed to users is State, while Incident State is a field that is specific to the Incident table and is maintained internally.

ServiceNow uses server-side Business Rules to keep the State and Incident State fields synchronized. These Business Rules execute during database operations such as insert and update.

When creating a new Incident, if you directly change the State field to Closed or Cancelled before saving the record, only the client-side value of the State field is updated at that moment. Since the record has not yet been submitted, the server-side Business Rules have not executed.

As a result, the Incident State field is not updated immediately and may appear out of sync with the State field while the form is still unsaved.

Once the record is submitted, the server-side Business Rules run and synchronize the State and Incident State values accordingly.

Therefore, the behavior you are observing is expected and occurs because the synchronization logic is executed only after the record is inserted or updated on the server.

I hope this clarifies the behavior.