Custom Table - Avoid subscription consumption

[satyendrakgupta]

In an environment that is heavily customized and you are always eager to serve your customer in the best possible way and avoid saying NO to their Ad-hoc need. Their need sometimes ask to create a table in ServiceNow. Since the time, ServiceNow came up with the concept of Custom Table and Management/Architect have to keep a very close eye before approving a new Table. We Architech have to come up with something. So, first thing, what exactly is a Custom Table?

“Custom Table” means any non-ServiceNow provided table created or installed by or on behalf of Customer on the ServiceNow platform and used for any purpose, including the creation of a custom application; unless such table is specifically exempt.

You can freely create or install custom tables on a non-production instance. However, the creation or installation of custom tables on a production instance requires a custom table entitlement granted when you purchase a product subscription.

Please go through the below article for details--

Custom Tables | Licensing Overview

Custom Table Guide

As per ServiceNow, certain tables are conditionally exempted. So, what is "Exempt Table"?

Exempt Tables: The customer is entitled to extend each of the below ServiceNow tables up to 1,000 times. Extending any of the below ServiceNow tables more than 1,000 times requires a subscription to either an App Engine product or any ServiceNow product that includes App Engine Starter entitlement.

cmdb_[*] cmn_location cmn_schedule_condition dl_definition dl_matcher kb_knowledge sc_cat_item_delivery_task sys_choice

scheduled_data_import sf_state_flow sys_auth_profile sys_dictionary sys_filter sys_hub_action_type_base sys_import_set_row

sys_portal_page sys_report_import_table_parent sys_transform_script sys_transform_map sys_user_preference sysauto syslog

*Any ServiceNow table with the prefix cmdb_

Use Case 1: Service Catalog's variable Type "List Collector" requires a "List Table", to support multi-selection. Now, how can I avoid multiple table creation for various variables?

Suggestion:

Step 1: Create a Table "Choice Extension" as below-

Label: Choice Extension                   Name: u_sys_choice_extension               Application: Global

Columns:

Step 2: Now, how this table is going to help us avoid the creation of multiple tables?

Suppose, we have a List Collector, on a Catalog Item-

Question: Support Required         Name: u_support_required

Then, in the "List Table", select Table "Choice Extension" and set "Reference qualifier" as "u_inactive=false^u_identifier=ProductionSupport", where "ProductionSupport" is unique for this "List Collector"

Thanks and regards,

Satyendra Kumar

[Stu McMurtrie]

Whilst this is inventive, I’d question why the sys_choice table should be extended to provide an alternative to creating a custom table that could be referred to by the platform. If a dataset definition does not match any existing element within the platform schema then it either needs to be housed and managed according to typical data principles or can simply exist on sys_choice, in which case it is simply that - a choice list that doesn’t expect changes to occur often or to be managed closely. As an Architect, it’s ok to advise ‘no’ sometimes, ie to provide an alternative & appropriate solution that satisfies the business outcome and conforms to policy, process, contract, corporate goals, etc, rather than the technical function that has been asked for. It’s also ok to say ‘yes, but this may impact cost’. As trusted advisors, we need to be transparent about consequences as well as providing advice so that stakeholders can make an informed decision. Can we extend these tables? Sure. Should we? That’s unclear without further discussion but, to me, the suggestion above plays on ‘rules as written’ rather than ‘rules as intended’ and could lead a Customer to fall foul of the ServiceNow licensing agreement and therefore the contract. If in doubt, ask your licensing sales contact.

[satyendrakgupta]

Thank you, Stu for your word 'inventive' & for engaging in the discussion. Now, let me elaborate on my thought.

Why the sys_choice table should be extended to provide an alternative to creating a custom table that could be referred to by the platform?

I am not extending the sys_choice table but gave a name similar to it. Now, why the similar name-

• The table name starts with 'u_' which means user-created table.
• The table name contains 'sys_choice', has thought, it has some relations while creating this table (similar)
• I wanted this table to appear in search if a developer/architect searches for sys_choice table or if they are thinking anything about to do around sys_choice table.

Can it managed or simply exist on sys_choice?

Obviously YES. My thought behind creating a table to save many more tables and looks more clear to the non-technical user-

• To manage the sys_choice table, you need (OOTB) either admin or a similar administration role which is not in this case. This table can be managed by a non-administration role.
• To save a record in sys_choice, you need 'Table' to be selected first, which is not in this case but can be uniquely grouped by column 'Identifier'.
• sys_choice table has a Display 'True' for the column 'Label' which does not look good while showing the details of a selected value. Similar thought behind other column names.

Is it leading a Customer to fall foul of the ServiceNow licensing agreement and therefore the contract?

I am certainly not sure, how am I violating any of their rules but certainly when I get a chance I would bring this question or open to it.

Thank you again for your reply!

With regards,

Satyendra Kumar

[Daniel Draes]

The solution will work yes, and yes it will avoid creating lots and lots of tables for simple reference data fields on catalog items. A few trails of thought to it though:

- Instead of creating new choice list tables, first look to see if the data is already existing somewhere in the instance. Most of the time I encountered this, a reference field to an existing table would have been a much better solution.

- The one common table for all choice entries means maintenance should rather be centralized. If you split the data based on item (or at least category) in different tables, you open up the option that someone in the business could maintain the content of that table, rather then IT.

Other options might include a decision table (free of charge as well). This could make sense as the fulfilment flow for the catalog item can leverage the same decision table for driving automation.

[toddvolpeRJ]

This is a build I've used for years and it proves very helpful. The sys_chocice is not a selection for all areas in the platform and so this allows centralized selection. I'd change the name as calling it extension developers/admin/architects will assume it's extending a table.  "Custom Choice" would likely be a name that wouldn't inherit the thought of it being an extended table.

It does centralize the location of choice selections and provides uses for choices outside of catalog items.  This typically will reduce the amount of time needed to find where a value is stored.  I also have a few additional fields such as assignment group, user, catalog item, etc. to provide for easy flow/workflow templating.  I then have a catalog item that can populate these records to allow for business users to supply updates.  

This table comes at the cost of 1 table, where you wouldn't technically need any if you just used the catalog completely out of box.  However with the way catalogs can get many thousands of items I believe this build would save more time for the client instead of having to manage choices of thousands of catalog items selections.

@satyendrakgupta Thank you for your contribution.

[Tobi3]

@Daniel Draes 

Now for the interesting part. How would you implement multiple choice fields in workspaces?

Normally, I'd create a new column with type List and add a few choices.
Works as expected and has good UI. Can easily be maintained and localization is also solved. Everyone knows how to handle choices.

Now try using that in a workspace. Doesn't work. You cannot select any of the choices.

If you want to use a list in a workspace, you need to reference to another table. Well, referencing sys_choice isn't allowed, so you're forced to build your own table and reference it.
This is turn has a bad UI, especially for few choices and handling localization is more effort.

It's 2024 and ServiceNow still has no oob multiple choice field that just works everywhere.
Alternative: Create lots of checkboxes.

[priyankaama]

can you share me the article stating that creating custom tables in production of servicenow requires licence or some kind of charges?

[Ryan Duce]

https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/legal/custom-table-gu... - this is the guide to use, and also tells you which tables you can extend without incurring custom table subscription consumption.