Best practice for customer-configurable choice values in a scoped application

[MalakaSilva]

Hi everyone,

We are currently building a scoped ServiceNow application that will be installed across multiple customer instances. We have several fields in our application tables that are currently defined as Choice fields, with the choice values hardcoded as part of the application.

For example:

Customer Type

Enterprise
SME
Government
Partner

However, we would like to allow each customer to add, deactivate, or maintain their own choice values after installing the application, without having to modify the application itself. I'm looking for recommendations on the best ServiceNow architecture for this requirement.

One option we are considering is replacing the Choice field with a Reference field pointing to an application-specific configuration table, for example:

Customer Type Configuration

Name
Code/Value
Active
Order
Description

The application could then provide some default records, while allowing the customer administrator to add their own values after installation.

My questions are:

Is Reference field + custom configuration table the recommended approach for this scenario?
Are there any ServiceNow application development best practices around making Choice values customer-configurable?

Would you recommend a separate configuration table for each type of choice, or a generic configuration/choice table that stores multiple types of values?
Are there any considerations around upgrades, application scope, or customer modifications that we should take into account?

Is there a recommended alternative approach that we should consider?

I'm particularly interested in hearing from developers who have built Store applications or applications that are

installed across multiple customer instances.

Thanks in advance for your suggestions and experiences.

[Tanushree Maiti]

Hi @MalakaSilva 

Could you please confirm whether the reference field points to a custom table or a base table?

If it points to a custom table:

• Create a custom role and provide the required access to the Business.

• Create ACLs for Create, Write, and Delete operations and assign the custom role to those ACLs.

• This will allow the Business team to maintain the data.

Please also ensure that the same custom table is not being used or shared by any other component or application. Otherwise, any changes or moderation performed by the Business could potentially impact those components or applications.

If it points to a base table:

• We should avoid providing direct access to the table to other users, as this could impact the underlying system data or functionality.