Welcome to Community Week 2025! Join us to learn, connect, and be recognized as we celebrate the spirit of Community and the power of AI. Get the details  

Sabrina Ethridg
Tera Guru

The Generic Look up Table

As an implementer, I was often asked to add new fields to the HR case tables so that specific information could be used for reporting and automation, but the values also needed to be easily updated.  ServiceNow provides many out of box tables for storing values that can be used as lookups for reference fields/variables in the HRSD application.  

 

The most common tables are under HR Administration -> Managed Lists and store values such as Relationships, Benefit Plans, and Benefit Types.   There are also tables that don’t have modules in the application navigator, but store values such as leave and time off types.   If the purpose of these tables matches the need, use them, but there aren't tables for every scenario. 

 

Using a choice field or creating a new table for each new reference field can quickly become unwieldy.  Choice lists limit the ability to quickly maintain values outside of a development cycle and new tables for every field will consume many (if not all) of the custom table entitlements.  

 

During one of my first HRSD implementations, I discovered an out-of-box table that could be used for many reference fields and variables.  It is the Generic Look Up (sn_hr_core_generic_look_up) table.  This standalone table comes with the 7 standard system fields.  By adding a handful more fields, it becomes a data lookup table that could be used across multiple HR services and record producers.    Key requirements that were fulfilled with this table include:

  • Easy to add/remove values outside of a development cycle
  • Can be used for both fields and variables
  • Some values should only be visible to the HR Agents on the case form
  • The order the values are displayed can be defined and is not always alphabetical

I have developed multiple iterations of this table, ranging from straightforward to sophisticated configurations, tailored to meet the specific requirements of each customer. As complexity increases, HR administrators will require more instructions to maintain the data. This article presents a simple configuration of the table, fields, and variables, along with an example of its use with the General Inquiry HR service.

Configuration

Ensure you are in the Human Resources: Core application scope and have an update set created and ready to capture these changes.

  • Create a new list module under the HR Administration -> Managed Lists for this table.

SabrinaEthridg_0-1762536517043.png

 

  • Create new fields on the Generic Look Up table.

Field

Definition

Mandatory

Lookup type

Choice
Values: Field, Variable

 

Yes

HR Service

Reference to HR Service (sn_hr_core_service)

Reference Qualifier: Active = true

Yes

Field

Reference to Dictionary (sys_dictionary)

Reference Qualifier: Active = true AND Type = Reference OR Type = List AND Table startswith sn_hr_core_case1

Conditional

Variable

Reference to Variable (item_option_new)

Reference Qualifier: Active = true AND Type = Reference or Type = List Collector and Table startswith sn_hr_core_case*

Conditional

Value

String (100)

This is the display field for this table

Yes

Active

True/False, default is true

No

Order

Integer, Optional

No

Available for

Choice

Values: Everyone, HR Agents

Yes

*If the Lifecycle Events or Employee Relations plugins are in use, add additional conditions to include the sn_hr_le_case or sn_hr_er_case tables and part of the reference qualifier.  While those tables extend from HR Case (sn_hr_core_case) they do not follow the same naming convention.

 

  • Create a UI Policy to hide/show the Field and Variable fields based on the value selected in the Lookup type field.
  • After the fields and UI Policies are created, ensure the form layout is user friendly.  The versions often look like this:

SabrinaEthridg_1-1762536517045.png

 

SabrinaEthridg_2-1762536517047.png

 

Elevate to the security_admin role to make Access Control (ACL) changes as outlined in steps 4 and 5.  

  1. Generic Look up table:
    • Edit the ‘read’ ACL so that all users can read values from this table.
      • By default, it is limited to those with the sn_hr_core.admin role.  Depending on your instance, you may need to add the snc_internal role or another role that you grant to all active users.
    • Ensure the ‘delete’ ACL is limited to admin or sn_hr_core.admin
  2. Dictionary (sys_dictionary) table*:
    • Add two ACLs that allow sn_hr_core.admin read access to the Dictionary table.    

*This change should be done in the Global scope in a new update set and only needs to be done IF the HR admins will not have the admin role.

SabrinaEthridg_3-1762536517051.png

SabrinaEthridg_4-1762536649003.png

 

Usage

After completing the setup, use the table as the reference when creating variables and fields. I typically refer to this table in three main scenarios.

 

  1. A reference or list field on the HR Case or one of its extended tables
  2. A reference or list collector variable on a record producer that maps to a field
  3. A reference or list collector variable on a record producer that does not map to a field

 

  1. When creating a field that uses this table as a reference, include the Active, HR Service, and Field as part of the reference qualifier. For example, if there is a field called Primary topic that is visible for the General Inquiry Service, the reference qualifier would look like this:
  2. SabrinaEthridg_1-1762538299620.png
  3. When creating a variable that maps to a field, the reference qualifier would look similar but have the addition of Available for as part of the reference qualifier. 
    • This ensures that both the field and variable are getting the same values AND allows you to have additional values that are only visible on the backend.
    • The image below follows the example of having a variable map to the Primary topic field.SabrinaEthridg_2-1762538338730.png

       

  4. If the variable does not map to a field the difference in the reference qualifier is to include the variable as part of the condition

SabrinaEthridg_7-1762536705009.png

 

Example

The General Inquiry service has the following requirements:

  • The employee selects a primary topic when submitting the form via the record producer with some values visible to only the HR Agent. This needs to be a field on the case record.
  • A question asking for the type of spending account to help gather information when the case is submitted but does not need to be a field on the case record.

 

After creating the field and variable,  define the values in the Generic Look Up table.

SabrinaEthridg_8-1762536801830.png

 

There are five values for the Primary topic field, one of which is only available for HR Agents. On the record producer only the values available for everyone are displayed.

SabrinaEthridg_9-1762536801831.png

 

In the HR Agent Workspace view, the values only visible to the HR Agents are also in the list

SabrinaEthridg_10-1762536801833.png

 

 

For the variable that does not map to a field, the two values defined for the variable are displayed on the record producer

SabrinaEthridg_11-1762536801834.png

Additional Information

  • If you see more values than expected are displayed in the reference field or variable, ensure the HR Service and Field/Variable are part of the reference qualifier.
  • Don't include the 'Available For' in the reference qualifier on the case fields, as the agents should be able to view all the values.
  • If a field is used across multiple services, an Advanced reference qualifier must be used to dynamically identify the HR service.
  • Use XML export/imports to move the values from this table between instances.  The sys_ids of these records need to be the same across instances (think of this similar to group management), especially if there is automation tied to specific values.
1 Comment