Create a Custom HR Case Transfer Type

[MohamedMaghfour]

ServiceNow HRSD

Creating a Custom HR Case Transfer Type

A Practical Implementation Guide

The Problem

Out of the box, ServiceNow HRSD provides two primary methods for transferring HR cases: Reclassify and Standard Transfer. While these cover basic requirements, real-world HR operations often demand more specialized functionality.

A common example: your organization needs a dedicated transfer type for sensitive cross-region cases one that forces the agent to: transfer some related records and automatically notifies your Data Protection team.

None of the standard options do this. Rather than bending an existing type or, worse  modifying platform code, the clean path is to create a new transfer type from scratch using the built-in extension mechanism ServiceNow provides.

How it works — the big picture

Before jumping into configuration, it helps to understand the three things that make a transfer type work in ServiceNow:

Component	What it does	What we do with it
Transfer Type record	Registers your new type in the platform — gives it a name & label	Create a new record
Transfer script	Contains the behavior: validation, updates, and triggered actions	Copy from an existing OOB script and adjust
Visibility rules	Controls who sees this option and when	Configure based on HR-specific criteria

The key principle: ServiceNow is designed to be extended, not modified. Your new type sits alongside the OOB types without touching any platform code, meaning upgrades won't break your work.

Step 1 — Create the Transfer Type record

This is the entry point. Navigate to:

All > HR Administration  > Transfer Case Configuration >  New

Fill in the key fields:

• Name — a short internal name
• Display text — what agents will see in the dialog.
• Active — set to true
• HR criteria — to controle visibility

Save the record and note the Sys ID of this new Transfer Type — you'll need it in Step 2.

Step 2 — Build the transfer script

Every HRSD transfer type is powered by a Script Include (more precisely, a Scripted Extension Point implementation) that defines what happens when the transfer is executed. Rather than writing one from scratch, the right approach is to copy the closest existing OOB implementation and adapt it.

- Find the baseline

Navigate to: All > System Extension Points > Scripted Extension Points

Then locate the transfer script: API Name = sn_hr_core.HRCaseTransfer

- Create Your Implementation

Open the Extension Point record and review the existing OOB implementations in the related list to identify the one closest to your target behavior.

From the Extension Point record, click "Create Implementation" in the Related Links section.

💡Tip: Rather than starting from a blank script, copy the full script from the most relevant existing implementation, paste it into your new one, and adapt from there. This ensures you don't miss required functions.

 

- Map It to Your Transfer Type

Inside your new implementation, locate the getConfigurationId() function and replace the return value with the Sys ID of the Transfer Type record you created in Step 1:

This is what binds the script to your transfer type. Without it, the platform won't know which script to run.

- Adjust the script

Update the logic to match your requirements.

For example, to simplify this demo, we will modify the behavior to complete the original case instead of canceling it.

Step 3 — Control who sees this option and when

This is where the real HR-specific configuration lives. There are two ways to manage visibility, and they can be combined.

Option A — Condition on the HR case record 

Use the isCaseEligibleForMethod function inside your script to dynamically show or hide the transfer type based on the case record's state:

This is ideal for logic that depends on case data — service type, state, assignment group, or any field on the record.

Option B — HR Criteria 

Use HR Criteria field in transfer type record to control visibility based on user attributes — role, department, location, or any HR-defined criteria.

Summary

Here's what you built:

1. ✅ A Transfer Type record that registers your new option in the platform
2. ✅ A Scripted Extension Point implementation that defines the transfer behavior, mapped via getConfigurationId()
3. ✅ Visibility controls via HR Criteria and/or isCaseEligibleForMethod()

The result is a fully functional, upgrade-safe custom transfer type that sits cleanly alongside OOB options.

---------------------------------------

Did you find this guide helpful? Share your thoughts or questions in the comments below!