When label changes on sys_choice table for any element didnt update the updated timestamps on prev

[ajayvemula1]

When a choice label is changed in the sys_choice table, existing records display the new label, but their updated timestamps remain unchanged.

For example, the Category field on the problem table has a choice labeled Software, which is used by 100 existing records. When the label is changed to Software IT, all 100 records display the new label, but their updated timestamps do not change.

How can we capture the time of this label change on all affected existing records?

[OlaN]

Hi,

That's just how the platform works. You're not actually changing the records using the choice-value, you are only changing the display value of the choice itself.

Same thing would go if you were to change the same of any reference for example a user record.
Say you'd change Beth Anglin to something else, like Beth Anglin-Smith, then all the Incident records that exist would display the new name, and not the old one, but none of the records would be updated, since the value hasn't changed, only what's displayed.

[ajayvemula1]

Hi OlaN,

Thank you for your reply.

When a choice label changes in ServiceNow, the updated timestamps on existing records remain unchanged. As a result, Visibility’s downstream data processes cannot detect the change. ServiceNow displays the updated label, while Visibility continues to show the previous label, causing data inconsistencies between the two platforms.

Is there a way to update the timestamps on the affected existing records when a choice label changes so that Visibility can detect and synchronize the change?

[OlaN]

The only way I can think of to process the label change in all records using it, is by writing a (for example) business rule that looks up all records using the value, and then does a (forced) update on them to indicate the label change.
Though I have a hard time understanding a use case for tracking the label change on the records using that label.

The choice table is audited, so the change of records there is already tracked.

[ajayvemula1]

I agree that this is the default out-of-the-box ServiceNow behavior. However, the concern is its impact on downstream reporting.

When a choice label changes, ServiceNow immediately displays the new label on all existing records with the corresponding stored value. The underlying records are not physically updated, so their sys_updated_on timestamps remain unchanged.

Visibility receives a daily Excel file containing only records that were updated since the previous extraction. Because a choice-label change does not update the affected historical records, those records are not included in the daily file. As a result, ServiceNow displays the new label while Visibility Warehouse continues to display the previous label, creating a data inconsistency between the two platforms.

One of the goals of this analysis is to define the recommended approach for ingesting and maintaining choice-field data. In particular, we need recommendations on:

1. Whether Visibility should ingest and retain the stored choice value, while resolving the display label separately through sys_choice or a governed choice-mapping table.
2. Whether changes to choice definitions should be detected and communicated separately so that the affected warehouse data or label mappings can be refreshed.
3. Whether a separate daily choice-definition extract, change event, or reconciliation process should be introduced to keep ServiceNow and Visibility synchronized.
4. Whether current-label reporting or historical as-was reporting is required, because each approach requires different handling of label history.

Although an After Business Rule could force-update all affected historical records and change their sys_updated_on timestamps, this is not preferred. It would create artificial updates on records whose business data did not change and could trigger Business Rules, flows, notifications, audits, and integrations.

The preferred solution is to address this in the ingestion and warehouse design. Visibility should preserve the raw stored value and maintain labels separately. A change to sys_choice should update the central choice mapping or trigger targeted downstream reprocessing without modifying the historical source records.