Discrepancy between record states and metrics table.

[renatasanto]

Hi everyone!

I hope this message finds you well!

I'm dealing with a scenario where, when a RITM (Rapid Interruption Time Management) has its first state transition to On Hold OR Awaiting Prioritization, the record isn't updated in the Metrics table. An interesting observation is that the previous state doesn't populate the End and Duration fields.

I've already done an analysis based on these guidelines Troubleshooting Metrics intermittently not working - Support and Troubleshooting, but it didn't work.

Could someone please help me?

Thank you in advance.

[Me Being Mustaq · Accepted solution]

Hi @renatasanto ,

RITM records fail to create entries in the Metrics table during the initial state transition to "On Hold" or "Awaiting Prioritization," with previous state fields (End, Duration) remaining unpopulated. This commonly occurs when workflows or rapid field updates interfere with the "metrics events" business rule execution

• Business Rule Order Conflict: The "metrics events" and "start workflow" business rules both run at order 10000 on task tables like sc_req_item. Workflows updating state shortly after creation can cause the metrics rule to execute before the state change, missing the trigger.​

• Field Auditing: Metrics only trigger on audited fields; verify the "state" field on sc_req_item has auditing enabled (default for task-extended tables).​

• Metric Definition Setup: Ensure a Field Value Duration metric definition exists for the "state" field on sc_req_item, with definition type "Field Value Duration" and field name "state." First transitions may lack prior instances if no initial "New/Open" metric was captured

You Can try below steps for resolution

1. Navigate to System Definition > Business Rules, search for "metrics events" on sc_req_item (or task table), and set its Order to 10001 (higher than "start workflow"). Test by creating/updating a new RITM.​

2. Check System Definition > Dictionary for sc_req_item.state; confirm "Audit" is true. If not, enable it.​

3. Review Metrics > Definitions for sc_req_item.state; duplicate OOTB incident definitions if missing (e.g., copy "Open" or state metrics). Ensure script completes durations on state changes.​

4. Impersonate a user, transition a test RITM to On Hold/Awaiting Prioritization, then query metric_instance for the sys_id—verify Start/End/Duration population. Monitor workflow logs for race conditions

You may find below thread helpful:

• https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0781007
• https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0963918
• https://www.servicenow.com/community/developer-forum/metric-not-firing-off-for-1st-updated-by/m-p/21...

If it is helpful, please hit the thumbs button please mark the answer as correct based on the impact!!

Kind Regards,

Shaik Mohammed Mustaq

[renatasanto]

Incident State - On Hold = 3, shows as Closed Comp... - ServiceNow Community

[Me Being Mustaq · Accepted solution]

Hi @renatasanto ,

RITM records fail to create entries in the Metrics table during the initial state transition to "On Hold" or "Awaiting Prioritization," with previous state fields (End, Duration) remaining unpopulated. This commonly occurs when workflows or rapid field updates interfere with the "metrics events" business rule execution

• Business Rule Order Conflict: The "metrics events" and "start workflow" business rules both run at order 10000 on task tables like sc_req_item. Workflows updating state shortly after creation can cause the metrics rule to execute before the state change, missing the trigger.​

• Field Auditing: Metrics only trigger on audited fields; verify the "state" field on sc_req_item has auditing enabled (default for task-extended tables).​

• Metric Definition Setup: Ensure a Field Value Duration metric definition exists for the "state" field on sc_req_item, with definition type "Field Value Duration" and field name "state." First transitions may lack prior instances if no initial "New/Open" metric was captured

You Can try below steps for resolution

1. Navigate to System Definition > Business Rules, search for "metrics events" on sc_req_item (or task table), and set its Order to 10001 (higher than "start workflow"). Test by creating/updating a new RITM.​

2. Check System Definition > Dictionary for sc_req_item.state; confirm "Audit" is true. If not, enable it.​

3. Review Metrics > Definitions for sc_req_item.state; duplicate OOTB incident definitions if missing (e.g., copy "Open" or state metrics). Ensure script completes durations on state changes.​

4. Impersonate a user, transition a test RITM to On Hold/Awaiting Prioritization, then query metric_instance for the sys_id—verify Start/End/Duration population. Monitor workflow logs for race conditions

You may find below thread helpful:

• https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0781007
• https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0963918
• https://www.servicenow.com/community/developer-forum/metric-not-firing-off-for-1st-updated-by/m-p/21...

If it is helpful, please hit the thumbs button please mark the answer as correct based on the impact!!

Kind Regards,

Shaik Mohammed Mustaq

[renatasanto]

@Me Being Mustaq 

What happens when metric records from the INC table are not being made in metric_instance?

The default metrics are configured correctly and the fields used are audited by ServiceNow.

Thank you in advance.

[Me Being Mustaq · Accepted solution]

Hi @renatasanto ,

When metric records for the Incident table are not being created in the table, even though the default metrics are configured and the fields are audited, it almost always points to an issue with timing, execution order, or background processing.

​The core mechanism for creating metric instances is the "metrics events" Business Rule, which runs after an update to an audited field. If this rule doesn't execute correctly or in the proper sequence, no records are created.

If it is helpful, please hit the thumbs button based on the impact!!

 Kind Regards,

Shaik Mohammed Mustaq