Difference between a Request State and State
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-29-2015 09:23 AM
Hi
Could someone explain to me the difference between a "Request State" and "State" for a Request Task, as I am unsure what to use to for me to know what the actual Status of the Request is i.e. open, closed etc...
Thanks

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-29-2015 09:50 AM
Hi Denis,
Request state is used to track the status of the request i.e for service catalog related requests.
State is used to track the status of the tickets like incident,problem or change...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-29-2015 10:00 AM
Its actually a really timely and astute question, Dennis.
Many of the default tables in ServiceNow come with their own state field that works independently of the base Task state.
Since the base Task state can be configured per extension table, there are a number of us who question the need for unique state fields on each Task extension table... especially when the application of them are inconsistent.
For example, Request, Incident, and Problem each have their own state field. Change has another unique one called Phase State. Newer task tables like Legal, Marketing, HR, and Financial don't have these private state fields, and instead rely on extending base Task State.
I've always found this tremendously confusing, but something I was forced to build with given how many OOB business rules key off of the task extension state, vs base task state.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-03-2015 09:09 PM
I've got to agree with you on this... the OOB fields that are table specific are a bit of a confusing mess and seem to serve little purpose when it is possible to make table specific choices for the TASK state field.
Properly managed, the table specific choices on the TASK table for the state field are enough. This becomes a bit of an exercise in tiding up the existing business rules that manage child table states, but I believe that this is more than worth it in the long run as it makes state management and reporting at the task level a much simpler exercise.
Much the same could be said for the different fields for caller, requestor, etc that litter the sub tables of task, with no TASK level field that is used to track this (opened_by is as close as it gets - promoted caller_id in the past to cover this)
Personally I'm in the "one state field to rule them all" camp.
R
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-29-2015 10:01 AM
Request State is used to check the status of Request. State field is visible on request as it inherits Task table which is used for other application. You should use Request state field.