Clarification on Custom Table Licensing for M2M Tables with Additional Configuration Fields

[Subrahmanyam6]

Hi Community Team,

I was reviewing the ServiceNow Custom Table Guide and came across the following exemption for custom table licensing:

2.2.1 Many-to-Many Tables: Many-to-many tables that are registered in the m2m_table field in the sys_m2m table. These tables are restricted to three (3) custom fields in addition to the standard fields created by the system.

Source: ServiceNow Custom Table Guide

---

My Question

I would like to better understand how ServiceNow counts custom fields on an M2M table for licensing purposes.

Example Scenario (Illustrative Only)

Suppose I create an M2M table to manage approval routing for a business process.

The M2M table contains the following fields:

Field Type Purpose

u_product_type	Reference to custom Product Type table	Defines which product type the rule applies to
u_group	Reference to sys_user_group	Approval group
u_order	Integer	Controls sequential vs. parallel approvals
u_category	Choice	Provisioning / Decommission / Both
u_active	Boolean	Enable/disable configuration

Intended Logic

For example:

• Multiple records with the same u_order value would generate parallel group approvals.
• Records with different u_order values would generate sequential approvals.
• u_category allows approval rules to apply only to specific transaction types.
• u_active allows administrators to enable or disable rules without deleting records.

This would typically be driven by Flow Designer or a custom subflow.

---

Licensing Interpretation Question

The exemption mentions that M2M tables are allowed up to three custom fields in addition to the standard system-created fields.

My uncertainty is around how ServiceNow treats the relationship fields that are automatically created when an M2M table is generated.

Interpretation A

The following are considered system-generated relationship fields:

• u_product_type
• u_group

In that case, the actual custom fields would be:

• u_order
• u_category
• u_active

Result:

• Only 3 additional custom fields
• Table remains within the M2M exemption

Interpretation B

All fields on the table are counted as custom fields, including:

• u_product_type
• u_group
• u_order
• u_category
• u_active

Result:

• Total of 5 custom fields
• Table may no longer qualify for the exemption

---

What I'm Looking For

Has anyone received an official clarification from ServiceNow Licensing, Account Teams, or Legal regarding how these fields are counted?

Specifically:

1. Are the two relationship/reference fields automatically created by the M2M definition considered system-created fields for licensing purposes?
2. Or are they counted as part of the three-field limit?
3. Has anyone implemented a similar configuration-driven approval framework and received guidance from ServiceNow on licensing compliance?

I would especially appreciate input from ServiceNow employees, licensing specialists, or customers who have obtained an official answer from ServiceNow.

Thanks in advance for any clarification.

[Dr Atul G- LNG]

Thumb rule: consult with your SN account representative.

[Abhishek Pal]

Hi @Subrahmanyam6 ,

The current public Custom Table Guide does not explicitly confirm that the two reference fields created by the M2M definition are excluded from the three-field limit.

The guide defines a Custom Table Field as any non-ServiceNow-provided field created by, or on behalf of, the customer. It also states that an exempt M2M table must:

- Be registered in the m2m_table field of the Many-to-Many Definition [sys_m2m] table.
- Contain no more than three custom fields in addition to the standard fields created by the system.

The phrase "standard fields created by the system" normally refers to platform fields such as:

- sys_id
- sys_created_on
- sys_created_by
- sys_updated_on
- sys_updated_by
- sys_mod_count

Although the M2M creation process automatically generates the two relationship reference fields, they are still customer-specific fields pointing to customer-selected tables. The public guide does not clearly state that these two reference fields are treated as standard system fields for licensing purposes.

Therefore, the safe interpretation is:

u_product_type
u_group
u_order
u_category
u_active

should all be treated as potentially custom fields unless ServiceNow provides written confirmation otherwise.

Do not assume that Interpretation A is contractually valid only because the two relationship fields were automatically generated by the M2M definition.

Recommended validation:

1. Create the M2M relationship through:

sys_m2m.list

Do not create a normal custom table manually and then use it as an M2M table.

2. Confirm that the generated table is registered in:

sys_m2m.m2m_table

3. Review its classification in Subscription Management:

ua_exempted_table_inventory.list

and:

ua_custom_table_inventory.list

The inventory classification is useful for technical validation, but it should not be treated as a replacement for contractual confirmation.

4. Send the following information to your ServiceNow Account Executive, licensing specialist, or Customer Service and Support:

- Your ServiceNow contract execution date
- The applicable Custom Table Guide version
- M2M table name
- From table
- To table
- Complete field list
- Confirmation that it is registered in sys_m2m
- Intended business use

Ask them to confirm in writing whether the two generated reference fields count toward the three-custom-field limit.

Architecture consideration:

Your proposed table is more than a simple relationship table. It contains approval-routing configuration such as:

- Sequence
- Transaction category
- Active status

That can still be a valid associative data model, but the design should not be forced into an M2M table only to obtain a licensing exemption.

For configuration-driven approval routing, also evaluate:

- Decision Tables
- Flow Designer approval rules
- A properly entitled custom configuration table

A Decision Table may be a cleaner option because the requirement is fundamentally rule evaluation based on product type, transaction category, group, and order.

My recommendation is:

Do not rely on Interpretation A without written confirmation.

Until ServiceNow confirms otherwise, use the conservative interpretation that all five customer-specific fields may count toward the limit, or implement the requirement using an entitled custom table or Decision Table.

Also note that the applicable licensing rules depend on the Custom Table Guide incorporated into your organization’s contract. A newer guide published on the ServiceNow website does not automatically replace the terms governing an earlier contract.

Official references:

Current ServiceNow Custom Table Guide:
https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/legal/custom-table-gu...

Create a many-to-many relationship:
https://www.servicenow.com/docs/r/platform-administration/table-administration-and-data-management/t...

Grandfathered and exempted tables:
https://www.servicenow.com/docs/r/platform-administration/grandfathered-and-exempt-tables-v2.html

Hope this helps!

If this response helped, please mark it as Helpful.
If it resolves your question, please Accept it as Solution.

Kind Regards,
Abhishek Pal