Is there logic behind cmn_location not being extensible OoB?

ProcessMatters
Tera Guru

3 weeks ago

This one has often puzzled me.
Extensions of cmn_location are considered "Exempt" meaning they do not count towards custom tables...
OoB it is not extensible. It is easy enough to make extensible; it is just a checkbox.
I am curious if anyone knows the logic behind not making it extensible OoB (implying it should not be extended) while exempting extensions from the custom table allotment (implying it should be extended).

Labels:
0 Helpfuls
  • 533 Views
3 REPLIES 3

fknell
Tera Patron

3 weeks ago - last edited 3 weeks ago

Hi @ProcessMatters,

Why would you want to extend the `cmn_location`? Could you provide some examples of why it’s important to you?

 

Regarding your question about whether an extension of a table counts, the guide from ServiceNow attached provides the answer. 

 

Hope this helps!

Preview file
157 KB
0 Helpfuls

Tanushree Maiti
Kilo Patron

3 weeks ago

Hi @ProcessMatters 

 

It could be the reason to not making cmn_location extensible OoB,

 

  • Performance & Database Complexity: cmn_location is a highly referenced, core table utilized across all modules (ITSM, ITAM, CSM etc). Allowing unlimited, arbitrary extensions can lead to complex database joins, potentially causing performance degradation, especially with massive amounts of location data.
  • Data Consistency: By forcing it to be "not extensible" by default, Servicenow encourages developers to use custom fields(reference) on the base table rather than creating new child tables, ensuring a consistent location structure.

 

Please mark this response as Helpful & Accept it as solution if it assisted you with your question.
Regards
Tanushree Maiti
ServiceNow Technical Architect
Linkedin:
0 Helpfuls

Uday Damaraju
Kilo Guru

3 weeks ago

@ProcessMatters 

This is to strike balance between platform stability and business flexibility. 

Rationale for OOTB not extensibleRationale for exemption from custom tables
1. Data integrity & Consistency perspective- SN forcing consultants/architects to leverage the way it is structured hierarchically, if needed scale horizontally by adding columns/fields as needed.   It doesn't make sense to fragment the data and maintain in multiple tables.
2. Its a core foundation data table leveraged by almost every solution on SN and every possible extension creates a DB join & such uncontrolled DB extensions for a highly reff.ed table would lead to performance issues
 3. Checkbox could treated as a guardrail using which architect can make the right decision if a separate table is necessary or not.
  1.  SN realizes certain industries may require extensions. I can think of few use-cases from manufacturing and Retail industries perspective. Hence, with an 'exempt' SN wants to eliminate the financial implication (custom table quota) for a legitimate architectural pattern.
  2. More often customers were guided in a wrong direction (Ex: Extend Task table for location-based just to save on table costs) - this exemption could avoid such scenarios 


"Hope this help, if it does, mark it as Helpful"

BR, UD

0 Helpfuls