HR Case Creation Configuration

[Drishti]

Hi SNOW people,

Need help in HR Case Creation Configuration page. I need to know the significance of some of the fields from different section of this page

From the Employee Search  :  User,Links, Priority table name, Priority column.

From the Case Search : User Fields

Please help me in understanding what impact the changes being done to the value of these fields are going to have in the main page of HR Case creation page.

Attaching the screenshot with fields highlighted where I need help.

Thanks in advance !

[Rafael Batistot]

Hi @Drishti 

Employee Search section

This controls how the system searches for employees when an HR agent starts creating a case.

• User
  
• Defines which field in the sys_user table is used to identify the employee being searched.
• Example: if it’s set to name, the search bar will look at the Name field; if set to email, it searches by Email.
• Impact: Changing this changes how HR agents can find an employee in the search step.
• Links
  
• Determines which links/actions appear next to the employee record when it shows up in search results.
• Example: links to “View Profile” or “Create Case” might show.
• Impact: Controls the quick actions available when selecting an employee.
• Priority table name
  
• Defines the table that stores priority mapping rules for HR cases (ex: sn_hr_core_case_priority).
• Impact: Changing this could break or change how case priority is calculated when selecting an employee.
• Priority column
  
• Specifies the column within the chosen priority table that determines priority.
• Impact: If you point it to another column (say, from priority to urgency), the system will use that field to set the case priority automatically.

Case Search section

This configures how HR agents find existing cases for the selected employee (to avoid duplication or to reference history).

• User Fields
  
• Tells the system which fields link a case back to the employee (commonly opened_for or subject_person).
• Impact: Changing this affects which cases show up when searching.
• Example: If set to opened_for, you’ll only see cases where the employee is the case opener; if set to subject_person, you’ll see cases where the employee is the subject (even if someone else opened it).

[JessicaLanR]

Hey! On the HR Case Creation Configuration (HRSD → Case and Knowledge), those fields control what the agent sees and how search behaves on the “Create HR Case” page. Here’s what each one actually does and how changes impact the page.

Employee Search

User

• What it is: Which field on the case will hold the selected person from the employee search.

• Typical target: Subject person (HRSD) or sometimes Opened for.

• Impact if you change it: The person you pick in the employee picker will populate a different field on the case draft. Downstream business rules, assignments, and HR criteria that reference “Subject person” may stop working if you point this at another field.

Links

• What it is: The set of shortcuts shown under/near the employee card (e.g., View Profile, Org Chart, Employment, Cases).

• Impact if you change it: You add/remove buttons agents use while creating the case. Great for quick access to Profile, Previous Cases, Knowledge, etc. Removing a link simply hides that shortcut; adding a link exposes the new action. No data impact—pure UX/navigation.

Priority table name / Priority column

• What it is: Where the page should look to show a priority badge for the selected person (think: VIP, High Risk, Critical).

  • Example: Table = sys_user, Column = vip (boolean) → shows VIP badge for that user.

• Impact if you change it: The colored badge on the employee card will appear/disappear or reflect a different attribute. If your assignment or SLAs key off “VIP” via that same field, the visual will stay in sync; if you point to a different column, the badge may no longer match your rules. Choose a field that is populated and stable (boolean or choice works best).

Case Search

User Fields

• What it is: Which user attributes are searched when you type in the employee picker (and often which columns show in the results list).

  • Common picks: name, email, user_name (UPN), employee_number.

• Impact if you change it:

  • Findability: Agents can find people by different keys (e.g., adding employee_number lets you search by badge/HR ID).

  • Noise/Performance: Too many fields (or poorly indexed ones) can slow search or return noisy matches. Keep it to the 2–4 best identifiers for your org.

---

Practical, safe configurations

• User: Subject person (default HRSD behavior)

• Links: Keep “Profile,” “Previous Cases,” “Org chart.” Add others only if agents actually use them.

• Priority table/column: sys_user.vip (boolean) or a dedicated HR attribute you maintain (e.g., u_hr_priority).

• User Fields: name, email, user_name, plus employee_number if you use it widely.

---

Gotchas & tips

• If you switch User to a non-standard field, review any HR Criteria, assignment rules, and email templates that expect Subject person.

• For Priority, pick a field that’s indexed (boolean/choice). If you map to a custom table/column, make sure it’s populated for your pilot users or you’ll never see the badge.

• For User Fields, less is more: start with name + email. Add employee_number if agents ask for it. Test search speed on a large tenant.

• Changes are largely UI-level for the create page—they don’t retroactively change existing cases.

• After edits, impersonate an HR agent and run through:

  1. Search by name/email/ID

  2. Confirm the correct person populates the intended case field

  3. Check the priority badge appears when expected

  4. Click all Links and confirm they open what agents expect

If you share (a) which field you want to populate (Subject person vs Opened for), (b) your VIP/priority source (sys_user.vip or custom), and (c) which identifiers agents use most, I can propose exact values for those four settings to match your tenant—and a 2-minute test script for UAT.