Custom Fields in HR Case

There’s really nothing quite like HR Case Management. It’s kinda like Incident, but not really. It’s kinda like service catalog, but not really. Thanks to HR Service, we have many different types of tasks being handled in small set of tables within the HR scope. This works pretty well, but can become complicated when you have a LOT of HR services that all use the same table (aka Center of Excellence or COE) and they all have their own fields. It’s even more complicated if multiple services (but not all services) want to use the same fields on a given COE.

I took the HR Fundamentals and HR Implementation courses back in the London and Madrid days, respectively. I haven’t seen the courses since then, but the versions I did see did not at all mention showing/hiding fields based on the HR service selected. They don’t even mention the idea of having custom fields for each HR service except on the Case Creation Service Configuration page.

The idea of having specific fields to fill in, similar to variables on a requested item, is so incredibly common in my experience that it’s a gross oversight to exclude the topic from both the fundamentals and implementations classes. Hopefully this has changed since that time.

ServiceNow even seems to gloss over this feature in Product Docs. Here’s the page that describes how to have custom fields for an HR service:

Note: When adding custom columns to an HR COE table, you must create a UI policy to hide it from other HR services that use that HR COE table.

That’s a big understatement, in my opinion. If an admin just created a new UI policy for each field or service, that could end up being a lot of UI policies that run all the time. It’s more efficient, however, to have fewer UI policies.

ServiceNow at least did us a favor by creating an OOB UI Policy that hides all the HR service-specific fields, as long as the admin adds the custom fields to that UI policy. The UI policy is called “Hide HR service fields and related lists”. This will hide any fields that are service-specific by default. (Another UI policy, “Show HR service fields on load” will display the fields that are specified in the “Service table fields” field on the HR service record.) When setting up a service with new custom fields, we can just use the existing UI policy to hide our fields by default.

Add Fields to the “Hide HR service fields and related lists” UI Policy

This assumes you’ve already created your custom field in the right COE.

  1. Navigate to System UI > UI Policies.
  2. Search for a UI policy with the name “Hide HR service fields and related lists”
  3. In the “UI Policy Actions” related list, add the Table column to the list view using the gear icon.
  4. If your COE is not the base HR Case table, apply a filter that shows only UI Policy Actions that are against your COE or find an example in the related list and use Show Matching to build the filter more easily. This will allow us to use a feature that causes the record we’ll create in the next step to inherit the value from the filtered list.
  5. Click the New button in the related list.
  6. Note the Table field contains either “HR Case” (the default) or the table we filtered on a few steps back.
  7. Select the custom field field in the Field name field.
  8. Set the Visible choice list to “False”. Leave everything else as it is.
  9. Click Submit.

The result is that the new custom field will be hidden by default whenever a case on that COE is viewed. Now we need to add it to HR service so that it will be displayed sometimes.

Add Fields to Service Table Fields on an HR Service

  1. Navigate to HR Administration > HR Services > HR Service Configuration.
  2. Search for an open the HR service that will use the custom field.
  3. Select the HR Service Additional Information section of the form.
  4. Add the custom field to the Service table fields list.
  5. Click Update.

Fortunately for us, the Show HR service fields on load UI policy will use this value to automatically show the field whenever the HR service is used (in the frameset, anyways).

If the field needs to be mandatory, the regular process of creating a UI policy should be used to make it mandatory.

ServiceNow’s Documentation

ServiceNow has done a subpar job of documenting this, though you can see where they have (barely) tried. Here’s what I could find:

Leave a Reply