Guidance Needed: Table Field Expansion, Licensing, Performance, and Data Model Design Best Practices

[ashrotriya]

Hello ServiceNow Community,

I’m reaching out for advice and best practices regarding a scenario we’re facing with one of our tables. I’d appreciate input from both the support team and community experts.

Background

• We currently have a table with 103 fields already defined.
• Due to evolving business requirements, we anticipate the need to add even more fields.
• To accommodate this, we have started creating table extensions.
• There are related tables (let’s call them Table1 and Table2) that represent the same record in different contexts.

Questions and Concerns

1. Licensing Impact

• Will adding more fields or creating extensions to the current table have any impact on our ServiceNow licensing?
• Are there any field or table limits that could trigger additional licensing costs or restrictions?

2. Performance Considerations

• What are the potential performance impacts of having a table with a large number of fields (over 100, possibly more)?
• Are there best practices or thresholds we should be aware of to avoid performance degradation?
• Does the use of table extensions help or hinder performance in this scenario?

3. Data Model Design

• Given that Table1 and Table2 represent the same record, is it advisable to bring fields from these tables into our main table?
• Would it be better to reference these tables instead of duplicating fields?
• What is the recommended approach for designing a scalable and maintainable data model in this situation?

4. General Best Practices

• Are there any ServiceNow-recommended guidelines for managing tables with a large number of fields?
• Should we consider normalization or other data modeling techniques to optimize our design?

Summary of What We’re Looking For

• Licensing implications of expanding fields and using extensions
• Performance best practices for large tables
• Data model design recommendations for handling related tables and shared records
• General advice on maintaining scalability and maintainability

Any insights, documentation references, or real-world experiences would be greatly appreciated!

Thank you in advance for your support and guidance.

[Mark Manders]

We don't know your contract, so anything license related should really be taken up with your account rep. However, usually, you only are allowed a certain amount of custom tables, so expanding will probably get you into the license discussion.

Performance will absolutely be an issue. You only stated that you have defined (way too many) custom fields. Why do you need this many? What is the process you are looking to implement? Did you check on OOB solutions or apps in the store? It really sounds like you are going to be using an existing table for something it wasn't meant for.

Putting too many fields on a form will impact the performance a lot, and that can even be getting worse if there are lots of html/multi line string fields amongst them.

Why would you ever use different tables to show the same record? Just use views, based on types or something like that (check out the OOB change process as an example -> emergency, normal and standard changes are all in the change_request table).

I think it would help in getting you a good answer, if we would know the process you are designing. That would help in understanding why you are moving into this direction. 

[ashrotriya]

• Our solution is portal-centric and supports multiple workstreams, each with substantial and diverse data requirements.
• The main table, called workstream, currently holds 103 fields due to the complexity and breadth of data we need to capture for each workstream.
• Many of these fields are necessary to support various business logic and reporting needs.
• To address both performance and licensing concerns, we are considering creating a new table.
• This new table would have a reference field (joining key) to the main workstream table.
• The goal is to move some of the less frequently used or specialized fields from the workstream table into this new table, reducing the field count in the main table and potentially improving performance and compliance with custom table limits.
• Further to address your statement, we do not have so many fields on our form, and user doesn't interact with form, user interacts with portal only.
• Since we need to store some metrics now - that created the requirement to have a separate table, and we want to move some fields from main workstream table to this metric one too - to remain compliant as I mentioned above
• We have gone through process of cleaning up fields - so now we are at position of moving them - will really appreciate some feedback on this approach 

[ashrotriya]

• Our solution is portal-centric and supports multiple workstreams, each with substantial and diverse data requirements.
• The main table, called workstream, currently holds a large number of fields due to the complexity and breadth of data we need to capture for each workstream.
• Many of these fields are necessary to support various business logic and reporting need
• So, recently with the next phase of development we are incorporating reporting and dashboards, for that we need fields having metrics, for that we were creating new fields in a separate table after a discussion, At the same time we had this idea to move some existing fields from workstream to this new metric table to remain compliant with servicenow guidelines
• Further to address your statement, since we have portal centered project - user does not interact with servicenow form or lists or even the instance UI
• In the end, This new table would have a reference field (joining key) to the main workstream table.
• The goal is to move some of the less frequently used or specialized fields from the workstream table into this new table, reducing the field count in the main table and potentially improving performance and compliance with custom table limits

[ashrotriya]

• Our solution is portal-centric and supports multiple workstreams, each with substantial and diverse data requirements.
• The main table, called workstream, currently holds a large number of fields due to the complexity and breadth of data we need to capture for each workstream.
• Many of these fields are necessary to support various business logic and reporting need
• So, recently with the next phase of development we are incorporating reporting and dashboards, for that we need fields having metrics, for that we were creating new fields in a separate table after a discussion, At the same time we had this idea to move some existing fields from workstream to this new metric table to remain compliant with servicenow guidelines
• Further to address your statement, since we have portal centered project - user does not interact with servicenow form or lists or even the instance UI
• In the end, This new table would have a reference field (joining key) to the main workstream table.
• The goal is to move some of the less frequently used or specialized fields from the workstream table into this new table, reducing the field count in the main table and potentially improving performance and compliance with custom table limits.