Closed [closed_at] field not populated in ritms in requested item [sc_item] table

[SumajRajNk]

Hi,

In the RITM (sc_req_item) table, some RITM records have the closed_at field populated with the date and time when the record was closed (Complete, Incomplete, or Skipped), while other records have this field as NULL. Why is this inconsistency ?

Note: This is happening with RITM records where they are in closed complete state but still they are showing as active True and active false also

I am not able to find the reason for this. Please help me find the issue.

#ritm #closed_at 

[Naveen20]

 

On any task-based table (including sc_req_item), two key OOTB mechanisms handle these fields:

1. The active field is driven by the state model. Each state choice has an inactive attribute. When a record transitions to a state marked as inactive (like Closed Complete = 3, Closed Incomplete = 4, Closed Skipped = 7), the platform should automatically set active = false.

2. The closed_at field is set by an OOTB business rule on the task table — typically named something like "Set close time" or "close task". This rule fires when the record transitions to a closed/inactive state and stamps closed_at = gs.nowDateTime() and closed_by = current user.

Common Root Causes for the Inconsistency

Here are the scenarios that cause some records to have closed_at = NULL and/or active = true even though the state is Closed Complete:

1. Workflows or Flows using setWorkflow(false) This is the most common culprit. If a workflow activity, Flow Designer action, or script sets the state like this:

var gr = new GlideRecord('sc_req_item');
gr.get(sysId);
gr.setWorkflow(false); // This skips business rules!
gr.setValue('state', 3); // Closed Complete
gr.update();

The state changes to 3, but the business rules that populate closed_at and flip active to false never fire. The active field behavior depends on whether the platform-level state-to-active mapping kicks in (which it sometimes does independently of business rules), explaining why you see mixed results — some records get active = false but still have closed_at = NULL.

2. Import Sets / Data Loads If RITMs were closed via an import set or migration script, and the transform map didn't trigger business rules (or setWorkflow(false) was used in an onBefore script), you'd get the same problem.

3. autoSysFields(false) in Scripts This suppresses system field updates. If a script uses this before updating the state, fields like closed_at won't populate.

4. Deactivated or Modified OOTB Business Rules Check if someone deactivated or added conditions to the OOTB business rule on the task table that sets close time. Go to:

sys_script.list → filter by Table = task and Name contains "close"

Look for rules like "Set close time," "close task," or similar. Verify they're active and haven't had extra conditions added.

5. State Choice "Inactive" Attribute Misconfiguration If the state choices on sc_req_item don't have the inactive flag set correctly for closed states, the platform won't automatically flip active to false. Check this at:

System Definition → Choice Lists → filter by Table = task or sc_req_item, Element = state

Each closed state (3, 4, 7) should have inactive = true.

How to Diagnose

Step 1: Identify affected records

Table: sc_req_item
Condition: state IN (3,4,7) AND closed_at IS EMPTY

This gives you all closed RITMs missing closed_at.

Step 2: Check the audit history On a few affected records, go to the Activity/History or the sys_audit table and look at what changed the state to Closed Complete. Was it a workflow, a flow, a user, an import, or a script? That tells you the mechanism that bypassed the business rules.

Step 3: Check for setWorkflow(false) usage Search your instance scripts (business rules, script includes, workflow run scripts, Flow Designer script steps) for patterns like:

setWorkflow(false)

combined with state updates on sc_req_item or task.

Step 4: Verify the OOTB business rule Navigate to the business rule that sets closed_at on the task table and confirm it's active, the conditions are correct, and no one has added a filter condition that excludes sc_req_item.

How to Fix Existing Records

Once you've identified the root cause and fixed it going forward, you can remediate existing records with a fix script (run in a sub-production instance first):

var gr = new GlideRecord('sc_req_item');
gr.addEncodedQuery('stateIN3,4,7^closed_atISEMPTY');
gr.query();
gs.info('Records to fix: ' + gr.getRowCount());

while (gr.next()) {
    // Use sys_updated_on as a fallback for closed_at
    gr.setValue('closed_at', gr.getValue('sys_updated_on'));
    gr.setValue('active', false);
    gr.setWorkflow(false);   // Prevent cascading triggers
    gr.autoSysFields(false); // Preserve sys_updated_on
    gr.update();
}

Note: Using sys_updated_on as the fallback is a reasonable approximation since that's likely when the state was last changed. If you need precision, you can query sys_audit for the exact timestamp when the state changed to 3/4/7.

Summary

The inconsistency almost always traces back to one thing: something bypassed the OOTB business rules when closing the RITM — whether it's setWorkflow(false) in a script, a workflow run script, a Flow Designer action, or an import set. The active field sometimes gets set correctly by the platform's internal state mapping even when business rules are skipped, which is why you see that mixed active = true / false behavior on records that are all in the same closed state.

[Ankur Bawiskar]

@SumajRajNk 

check this KB
RITM not updated with Closed date 

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏