← Home
🔥0 DAY
0 XP
Interview Prep · HRSD

HRSD
INTERVIEW.

Four scenario lessons on HR Profile security, Lifecycle Events, HR Criteria, and Case routing — the exact HRSD topics senior interview loops probe, each with a runnable simulator trace.

Pair with the ITSM guide and the Flow Designer guide for full platform coverage.

  1. 1. HR Profile security — who can see what?

    A manager opens an HR case and can read the subject's home address. Compliance is unhappy. How is HR Profile access controlled?

    How to answer

    • sn_hr_core_profile is the sensitive table — never grant public read.
    • Access is governed by HR Security roles (sn_hr_core.basic, .manager, .admin) PLUS scoped ACLs on individual profile fields (SSN, address, DOB).
    • The HR Profile record uses a Before-Query business rule to filter by employee relationship (subject, manager chain, HR agent assignment).
    • Case-level 'confidentiality' flags hide entire cases from non-HR users, even ones with a read role.

    Reference script

    // Field-level ACL on sn_hr_core_profile.home_address
    // Condition script:
    answer = gs.hasRole('sn_hr_core.admin') ||
             gs.hasRole('sn_hr_core.manager') &&
             current.user.manager == gs.getUserID();

    Pitfall

    Granting sn_hr_core.manager broadly. The role gates the UI, but the row filter still needs a manager-chain check — without it, any manager sees every profile.

  2. 2. Lifecycle Events — how onboarding actually runs

    Explain the moving parts behind an Onboarding Lifecycle Event when HR marks a new hire's start date.

    How to answer

    • A Lifecycle Event (LE) is triggered by a business condition — usually an HR Profile field change (start_date set, employment_type = new hire).
    • The LE spawns Activity Sets (Pre-boarding, Day 1, Week 1) — each Activity Set holds ordered Activities (issue laptop, assign trainings, schedule intro).
    • Each Activity creates its own HR Case or Task, routed via HR Services + HR Criteria to the right fulfillment group.
    • You monitor progress on the Lifecycle Event Case, which rolls up child activity statuses.

    Reference script

    // Trigger condition on sn_hr_le_activity_set_trigger
    current.hr_profile.start_date.changesTo() &&
    !current.hr_profile.start_date.nil() &&
    current.hr_profile.employment_type == 'new_hire';

    Pitfall

    Rebuilding onboarding as a single Flow Designer flow. You lose the LE dashboard, activity-set reuse, and the built-in HR Criteria targeting. Use LEs for HR workflows, Flow Designer for the fulfillment steps.

  3. 3. HR Criteria — targeting services and knowledge

    Why do HR admins use HR Criteria instead of just user_criteria records like the Service Catalog?

    How to answer

    • HR Criteria filter HR Services, Knowledge, Lifecycle Events, and Activities by employee attributes (department, location, employment_type, hr_profile fields).
    • They evaluate against sn_hr_core_profile, not sys_user — so location-based rules follow the profile's work_location, not the user's default.
    • Multiple criteria on a single service are OR'd by default — check 'Match all criteria' to switch to AND.
    • Criteria run advanced scripts too — you can call a Script Include to hit an external HRIS for eligibility.

    Reference script

    // Advanced HR Criteria script
    answer = (function() {
      var p = current.hr_profile.getRefRecord();
      if (p.employment_type != 'full_time') return false;
      var months = gs.dateDiff(p.start_date.getDisplayValue(),
                               gs.nowDateTime(), true) / 2592000;
      return months >= 6; // 6-month tenure requirement
    })();

    Pitfall

    Copy-pasting Service Catalog user_criteria logic. HR Criteria have a different evaluation context (hr_profile, not sys_user); a rule that works in catalog silently fails in HRSD.

  4. 4. HR Case routing — services, COEs, and assignment

    A benefits question goes to the Payroll team by mistake. Walk through how HR Case assignment is supposed to work.

    How to answer

    • The HR Service (sn_hr_core_service) defines the topic and its owning HR COE (Center of Excellence).
    • The COE holds the default assignment group — routing follows Service → COE → Group unless overridden.
    • Assignment Rules on sn_hr_case can override for special cases (VIP, region-specific specialists).
    • For Employee Center intake, the topic taxonomy maps directly to HR Services, so a mis-tagged topic sends the case to the wrong COE.

    Reference script

    // Assignment Rule condition
    current.hr_service.name == 'Benefits — Enrollment' &&
    current.opened_for.location.country == 'CA';
    // Script sets group:
    current.assignment_group = 'benefits_ca_specialists';

    Pitfall

    Editing the COE's default group to solve a one-off routing issue. Every other case flips too. Use an Assignment Rule for exceptions and keep COE defaults stable.

Keep going