Hi @Mi1 

My video will be helpful

https://youtu.be/JN2wVxkAbOg

Hi @Dr Atul G- LNG ,

Thank you for sharing the video!

It's a very clear guide on how to technically generate an RITM from a Record Producer.

One thing I am concerned about is the "Ledger" aspect. While the video shows how to create a request (point-in-time), I need to manage the "current status" of the service even after the RITM is closed (e.g., updating an expiration date later).

In your experience, is it better to manage such "living data" by updating the RITM variables themselves, or should I still consider a separate table to act as a central ledger?

I would love to hear your thoughts on this.

Hi @Mi1 

It is not recommended to change variables once a request has been submitted. We need to understand the fundamental concept here: a request follows a standard process and structure. Variables are required to execute the work, and if changes to variables occur frequently or later in the process, it becomes difficult for teams to fulfill the request efficiently. Therefore, we should avoid this practice, as it is not a best or recommended approach.

hi,@Dr Atul G- LNG,

Thank you for clarifying the fundamental concept. Your point about not changing variables post-submission to maintain fulfillment efficiency makes perfect sense.

Based on your advice, I am now even more convinced that we should keep RITM variables as an "Immutable Audit Trail" (Request History) and use a separate "Generic Ledger Table" to store the "Current Active State" of the service/asset.

This way, we can respect the standard request process you mentioned, while still allowing the operational teams to maintain up-to-date data in the Ledger without touching the original RITM variables.

Thank you for helping me align our architecture with ServiceNow best practices!

Glad to know my experience helped here. Please close this thread by accepting the solution. @Mi1