RITM state changed to "(4)" when request is canceled
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Dear ServiceNow Community,
I have an issue for which when a SAD request is canceled all the associated RITMs about that request got "4" as state, which is not present in the dictionary about the state field of the "sc_req_item" table.
I checked lots of business rules, UI policies, and UI actions, but I didn't find anything useful about that issue.
Is there a mechanism for which this thing occures? And is there a way to make those RITMs go into a valid (canceled) state?
Thanks,
Cristopher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi,
Check whether this is updated in flow or a business rule on task table
Palani
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @CrisBene ,
'4' should have been your 'Closed Incomplete' state, it should come from Task out-of-the-box. if this is missed, please add (you can add it to the> sc_req_item > state choice > value 4 as 'Canceled' or 'Closed Incomplete').
Thank you,
Hemanth
Certified Technical Architect (CTA), ServiceNow MVP 2024, 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Dear all,
thanks for replying.
I have already checked several BR, UI policies, UI actions, and workflows, but I didn't find any useful record in the sc_req_item table about the state changing to "4".
Now I would like to ask you how can I intercept this state changing, since I don't want to create a new entry in the sc_req_item table dictionary. Is this interception performed by a BR or something else? Which search criteria should I use to find that eventual piece of code if exists? There would be with high probability a piece of code of type "current.state = 4" where current is a sc_req_item record, isn't it?
Thanks,
Cristopher