How to develop using RITM without using AppEngine

[Mi1]

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,

[Mi1]

Hi @Ankur Bawiskar ,

Thank you for your response.

I have just posted an update to my requirements in the thread below (regarding table limits, ledger management, and data segregation).

Could you please take a look at the updated details? I would highly value your expert opinion on how to best structure this RITM-based application while maintaining data security and reporting capabilities.

[Tanushree Maiti]

Hi Mi1,

Could you please re- phrase your requirement.

We create custom application using development tools like App Engine Studio (for low-code development) or  Servicenow Studio (for pro-code development) on the Now Platform.

Whereas we Create Service Catalog using  Catalog Builder or Maintain Items module. RITM  represents a specific product or service ordered from the Service Catalog.

[Mi1]

Hi @Tanushree Maiti ,

Thank you for the detailed advice.

The method you provided seems very helpful for the initial request flow.

I have a question regarding reporting and data maintenance. Since we have a 40-table limit, I am considering using one "Generic Ledger Table" to store the latest status of various services post-approval.

Do you think this "Generic Ledger" approach is better for reporting compared to pulling reports directly from RITM variables?

I am worried that relying solely on variables might make complex reporting difficult in the long run.

Any advice on this architectural choice would be great.

[Tanushree Maiti]

Hi Mi1 ,

For a service catalog , there are 3 stages - Order, Approval  & Fulfillment.

Following oob tables are used for a catalog-

Request [sc_request] : Request table contain REQ0010013  information

Requested item [sc_req_item] : it is requested item table contain ritm information

Catalog task [sc_task] :this catalog task which contains task information ( it is fulfillment post approval)

If need reporting on Approval that also you can check sysapproval_approver.

So , ServiceNow platform itself provides you all the tables where you can do reporting. for associated record fetch, you can do DOT walking.

Always try to stick to OOB until and unless customization is very much required.

[Mi1]

Hi @Tanushree Maiti 

Thank you for the very clear explanation! It's reassuring to hear that using a "Generic Ledger Table" is a viable approach to stay within our table limits.

I have two additional questions to refine this architecture:

1. Column Management: If we aggregate data from many different catalog items into one generic table, we might eventually run out of columns or end up with a very messy table. Do you recommend using generic field names (e.g., String1, Date1) and mapping them per item, or is there a more scalable way to handle this?

2. Automated Security: Since multiple departments (HR, IT, etc.) will share this one table, I want to automate the data segregation. Would you suggest using a "Manager Group" field on the ledger record and applying a single Scripted ACL to check the user's membership? Or is there a better "ServiceNow standard" way to handle multi-departmental data in a single custom table?

I would appreciate your thoughts on these long-term maintenance aspects!