What is the best practice or guidance, on the State field for REQ, RITM, SCTASK

[athavichith]

What is the best practice or guidance, on the State field for REQ, RITM, SCTASK for when the SCTASK is at Closed Complete, Closed Incomplete, or Closed Skipped? Cause I have a user who is asking why the REQ.State is at 'Closed Complete' while the SCTASK.State is at 'Closed Skipped'

[danmjunqueira · Accepted solution]

This is a common question in ServiceNow environments, especially when users are looking at Requests (REQ), Requested Items (RITMs), and Catalog Tasks (SCTASKs) and expect their states to stay in sync. Here's a clear breakdown of how this works and what best practices to follow.

Understanding State Propagation
The REQ, RITM, and SCTASK tables each have their own state fields, and they do not automatically sync unless customized. ServiceNow uses business rules and workflows to control how states roll up — but RITMs or REQs can close even if some tasks are in a non-Closed Complete state, depending on configuration.

Default Behavior (Out-of-the-box)
When is a RITM marked as Closed Complete?
By default, a RITM is set to Closed Complete when:

All its associated SCTASKs are in a closed state (Closed Complete, Closed Skipped, or Closed Incomplete)

And the RITM workflow has reached its end

This means:

The RITM does not wait for every task to be Closed Complete, only for them to be closed in general

When is a REQ marked as Closed Complete?
A REQ is set to Closed Complete when:

All associated RITMs are Closed Complete or Closed Incomplete

It doesn’t directly look at SCTASKs

Why might this confuse users?
Users often expect a strict match:

If a SCTASK is skipped or incomplete, they assume the RITM and REQ should also reflect a problem

But the system treats tasks being closed (regardless of the closure reason) as sufficient to progress the parent records

Best Practice / Recommendation
Clarify closure logic in documentation or training

Make sure users understand that Closed Skipped or Closed Incomplete does not stop the RITM or REQ from closing, as long as the tasks are in any closed state

Use close code fields for clarity

Consider enabling or using the close_code or similar custom field on RITM/REQ to indicate why it was closed (successfully, partially, skipped, etc.)

Customize state roll-up logic if needed

If your process requires RITMs or REQs to only close when all tasks are Closed Complete, you can:

Add custom business rules or Flow Designer logic

Prevent closure unless all SCTASKs are in a specific state

Use reports or dashboards to monitor task closure quality

Create a report showing requests where:

REQ.state = Closed Complete

AND any SCTASK.state != Closed Complete

This helps in auditing and improving task closure practices

Table What triggers closure?

SCTASK	Manual, workflow logic, or user action
RITM	All tasks are closed (any closure), and workflow ends
REQ	All RITMs are closed (any closure), and workflow ends

[Dr Atul G- LNG]

Hi @athavichith 

You can check the Request and Catalog Management Process workshop, which is also available on Now Create. It provides more clarity on this topic.