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.