HRSD Record Producer Created on sn_hr_core_case - How to Create Cases Directly in COE Extended Table

manishkrpal
Tera Contributor

yesterday

I'm facing an issue in HRSD and would appreciate any guidance.

Current Requirement

I have created a Record Producer on the sn_hr_core_case (parent) table.

The Record Producer contains two variables:

  • q1_help_area – 7 choices
  • q2_details – 27 choices

The functionality works as follows:

  • User selects one of the 7 Help Areas.
  • Based on that selection, only the relevant question details are displayed
  • On submission, the Record Producer maps the selected q2 Detail to the appropriate HR Service through the Record Producer script.
  • The created HR Case also correctly populates the HR Service, Topic Category, and Topic Detail.

The Problem

We have 4 different COE (Center of Excellence) tables extending sn_hr_core_case.

For example:

  • Payroll  - sn_hr_core_case_payroll
  • Benefits - respective extended table
  • HR Central - respective extended table
  • HR Business - respective extended table

Since the Record Producer is created on sn_hr_core_case, every case is initially created in the parent table instead of the corresponding COE extended table.

Current Workaround

To solve this, I created a Flow Designer flow that runs after case creation and changes the record's sys_class_name from sn_hr_core_case to the appropriate extended table based on the selected HR Service/Topic Category.

This successfully moves the case to the correct COE table.

Remaining Issue

The problem is that notifications are triggered when the case is initially created on the parent table.

Because the class change happens afterward in Flow Designer:

  • Parent table notifications are triggered.
  • Extended table notifications are not triggered.
  • This results in incorrect notification behavior.

My Questions

  1. Is there a supported way to create an HR Case directly in the appropriate COE extended table from a single Record Producer?
  2. Is changing sys_class_name after insert considered a best practice, or should it be avoided?
  3. Is there any OOB HRSD mechanism that routes cases to the correct COE table based on the selected HR Service?
  4. How can I ensure that notifications are triggered from the correct extended table instead of the parent table?

I'd appreciate any suggestions or best practices from anyone who has implemented a similar HRSD solution.

Thank you!

0 Helpfuls
  • 33 Views
1 REPLY 1

Mariam_Ahmed
Tera Guru

43m ago

Hi @manishkrpal,

 

This is a common design challenge when balancing a simplified end-user experience with ServiceNow’s HRSD Center of Excellence (COE) data model. 

1. Direct COE creation from a single Record Producer

A Record Producer is designed to insert a record only on its designated target table. Attempting to bypass this in script (for example, by aborting the insert and manually creating a GlideRecord on the child COE table) is generally discouraged. Doing so breaks the platform link (sc_item_produced_record), which prevents submitted variables from showing up on the case and can break the portal's "My Requests" widgets.

2. Changing sys_class_name post-insert

It is best to avoid changing the class name after insertion. Behind the scenes, changing the class triggers a delete and insert process. If there are mandatory fields or Data Policies on the target COE table that fail, the record can be lost entirely. Additionally, it causes security risks because sensitive data (like Payroll) is briefly visible on the parent table before the class changes.

3. OOB HRSD routing mechanisms

ServiceNow HRSD is architected around a 1:1 relationship between the HR Service's COE table and the Record Producer's table. To keep the user experience simple without using a single "catch-all" form, the standard approach is to use:

  • Interceptors or Wizards: A simple front-end questionnaire that redirects the user to the correct, dedicated Record Producer.

4. How to fix the notifications now

If you need to keep your current workaround in place for the time being, you can resolve the notification issue with these adjustments:

  • Move notifications to Flow Designer: Instead of using table-level "on insert" email notifications, trigger the emails directly from your flow after the step where the case class is successfully updated.

  • Exclude parent table notifications: Add conditions to your parent sn_hr_core_case notifications to exclude these specific HR Services so they do not fire prematurely.

If you found this response useful, please mark it as Helpful and accept it as the Solution to help others with similar questions.


Best regards,

Mariam Ahmed.

0 Helpfuls