Is there a "data lookup repository" to use as reference data?

[tahnalos]

I am aware of the Choice Data type and that the choice data use the sys_choice form.

However, a recent directive from our Solutions Architects have prevented us from using the Choice Data Type for anything that isn't considered as a "core" field.

We have several choice fields that are related to each other and are determined by categorization.  Normally we would rely on choice data with dependent fields but as mentioned earlier we are forbidden from using Choice Lists.  This means that the only option is to use a reference on a customized form.

However, we are also limited to using customized forms and have been requested to use an existing repository form to hold this "choice" data as a reference.  Does such a form exist?

(Note: this kind of form would be used closely with HRSD, so something related to that would be appreciated)

Thanks

[WillieW]

On your question of where "Choice" data is stored, look in the sys_choice table. There is the "Advanced" and "Default" view.

You can also use Servicenow's Now Assist feature to help you. Then your organization won't need Solution Architects. Save some costs.

[nityabans27]

Hi @tahnalos ,

There isn’t an out-of-the-box ServiceNow form or table designed specifically to act as a “generic choice repository.” However, since using the Choice data type (sys_choice) has been restricted, you can use reference-based lookup tables instead.

If you’re working in HR Service Delivery (HRSD), there are already a few suitable tables that can hold this kind of configurable, categorized data:

• sn_hr_core_configuration – Stores configurable values and HR service mappings.

• sn_hr_core_task_configuration – Handles HR task-specific configurations.

• sn_hr_core_service – Useful if your dependent data relates to HR Services.

If none of these align with your exact need, you can create a small custom lookup table (for example, u_hr_lookup_value) with fields like Category, Value, and Dependent On. This table can then be referenced on forms and filtered using reference qualifiers instead of hardcoded choice dependencies.

This approach keeps the configuration data-driven, reusable, and compliant with the architectural directive to avoid sys_choice while still maintaining dependency logic between related options.

[Bert_c1]

@tahnalos 

1. Records in sys_choice are free.

2. You can use Client Script - onChange, to enforce specific values for fields. You have to hard-code those.

3. You can use a Business Rule to enforce specific values for fields. You have to hard-code those.

4. You can start looking for a new job where the organization has funds.

[tahnalos]

1) Again, we are prevented from using sys_choice until further notice

2) ServiceNow would probably trigger this code as a methodology violation.  I have been on the receiving end of those violation calls.

3) ServiceNow would probably trigger this code as a methodology violation.  I have been on the receiving end of those violation calls.

4) This isn't an issue of funds, but rather an organization with a tight control of who does what in their instance.

[WillieW]

Then use method 2 or 3 above.