How to develop using RITM without using AppEngine

Mi1 · ‎02-06-2026

Hi,

I want to create an application based on RITM.
Until now, we have been developing using App Engine, but this time we need to re-implement the services within the ITSM package(RITM) without using App Engine.
Do you have any suggestions for implementing what was created in App Engine within the ITSM(RITM)?

Also, please let me know if there are any things to be careful about or any limitations that may arise.

Best Regards,

<------------- add information --------------- >

Thank you for the suggestions.

To clarify my requirements and get more specific advice, please let me add a few points:

1. Table Limit:

We have a strict limit on the number of custom tables (currently 40), which is why we are shifting from App Engine to an RITM-based architecture.

2. "Ledger" Management:

In App Engine, we managed the "current state" (e.g., active user permissions or asset status) in custom tables. RITM is an audit trail of a "request," but I need a way to manage data that remains "living" after the RITM is closed (e.g., updating a completion date or expiration date later by a fulfiller).

3. Data Segregation:

The application will be used by different departments (HR, IT, General Affairs). I need to ensure that sensitive data (especially HR-related) is strictly restricted to specific groups via ACLs, even though all records reside in the same RITM table.

My specific questions are:

• For managing the "current state" after a request is closed, do you recommend using a single "Generic Ledger Table" to aggregate data from various items? Or is it better to manage everything within RITM variables?

• Are there any best practices for implementing robust ACLs on the RITM table to segregate data between completely different departments?

• What are the reporting limitations when using RITM variables instead of actual table columns for long-term data management?

I would appreciate your expert insights on these architectural points.

Best Regards,

Dr Atul G- LNG · ‎02-06-2026

Hi @Mi1

My video will be helpful

https://youtu.be/JN2wVxkAbOg

****************************************************************************************
Regards
Dr Atul G. - Learn N Grow Together ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
******************************************************************************************

Mi1 · ‎02-06-2026

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.

Dr Atul G- LNG · ‎02-08-2026

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.

****************************************************************************************
Regards
Dr Atul G. - Learn N Grow Together ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
******************************************************************************************

Mi1 · ‎02-10-2026

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!