merging 10 custom tables into one table

[rBh]

Spoiler

Hi Team,

Our client has requested that we merge 10 custom tables into a single table and introduce a "Type" field containing the names of all existing tables as dropdown values.

Each of the current tables has:

• Different approval processes
• Different UI Actions
• Different business processes
• Different user access restrictions
• Different form sections and fields

In the proposed design, based on the selected Type, the system would display the relevant fields and sections and execute the corresponding approvals and UI Actions.

Could you please advise whether merging these 10 tables into a single table is considered a best practice? Given the differences in processes, security requirements, UI configurations, and business logic, would it be better to retain separate tables (or use a parent-child table structure) instead of consolidating everything into one table?

Please share your recommendations and any best practices that should be considered for this design approach.

Thanks,
Bhavana

[yashkamde]

Hello @rBh ,

As per my understanding, the proposed single-table design trades short-term simplicity for long-term technical debt. ServiceNow's table inheritance model exists precisely for this scenario shared identity, divergent behavior. A parent-child structure gives you a unified reporting layer (query the parent for all records) while preserving isolated logic, security, and UI per type. This is the same pattern ServiceNow itself uses for Task, ITSM, HR, and Legal modules.

If my response helped mark as helpful and accept the solution.

[Tanushree Maiti]

Hi @rBh 

Combining 10 distinct custom tables with fundamentally different business processes into one table is a ServiceNow anti-pattern. This approach often leads to difficult maintenance, complicated ACL management, and cluttered forms.

Instead of that -

• Create a single custom parent table that contains all the globally shared fields across all 10 processes.
• Create 10 child tables extending this parent table.

[rBh]

Hello Everyone,

Thank you for sharing your inputs.

One challenge we have is that these custom tables are being developed within the Enterprise Architecture scope, where extending the Task table is not a suitable option since none of the Task table fields are required for our use case.

Additionally, the customer has informed us that they only have licensing available for 5 custom tables and are not willing to pay for the 11 custom tables currently proposed.

To address this constraint, we are considering the following approach:

• Merge 2–3 smaller custom tables that have similar structures and relatively simple logic into a single table.
• Retain separate tables only for entities that have more complex business logic and distinct requirements.
• Implement an interceptor/routing mechanism similar to the Product Models approach, where users are directed to the appropriate record type based on their selection.
• Use field, section, UI Action, and related list visibility controls based on the selected record type.
• Restrict form visibility and access through ACLs, roles, and user/group-based controls.

Given the customer's licensing limitations, consolidating some of the tables appears to be the most practical option available to us.

Please let me know if there are any concerns with this approach or if I am overlooking any important considerations.

Thanks,
Bhavana

[yashkamde]

Hello @rBh ,

As per my understanding another option could be consider implementing a parent-child table model instead of consolidating multiple entities into a single table with record-type differentiation.

For example, we could create a common base table that contains only the shared attributes across the Enterprise Architecture entities and then extend that table for the specific entities that require unique fields or business processes. This approach provides several benefits:

• Reduces data duplication by centralizing common attributes.

• Maintains clear separation of business logic for each entity.

• Simplifies ACL, UI Policy, Business Rule, and Flow management compared to a heavily customized single-table solution.

This will allow you to reduce the overall custom table count without introducing the complexity associated with a single consolidated table that relies heavily on conditional visibility, ACL logic, and record-type routing.

If my response helped mark as helpful and accept the solution.