HR System Architecture

This domain is about the data model, scoping, and configuration objects that make HRSD work. Most architecture questions reduce to: which scoped app owns this, which table does this extend, and which COE/criteria controls visibility?

Scoped Applications and COE Data Separation

HRSD ships as a set of scoped applications, not as part of the global scope. The foundation is the Human Resources Scoped App: Core (com.sn_hr_core), with companion scoped apps for Case and Knowledge Management, Enterprise Onboarding and Transitions (Lifecycle Events), Employee Relations, Employee Document Management, and others. Scoping isolates HR application logic and data and is why legacy (non-scoped) HR customers must migrate HR data from non-scoped to scoped to adopt new features.

Centers of Excellence (COEs) are the organizing principle for data separation in HRSD. A COE is a functional HR discipline — the base set includes HR Operations (HR Core/Total Rewards/general), Benefits, Payroll, Total Rewards, and Employee Relations style groupings (exact base COEs vary by release; the COE data model is the source of truth). Each COE has:

• its own case table that extends the base HR case table,
• its own assignment groups, agents, and managers,
• its own knowledge, services, and security policy.

The COE data model means a Benefits agent does not see Employee Relations cases, and sensitive COEs (Employee Relations especially) can enforce extra case restrictions and a COE security policy so that even broad HR roles cannot read those records.

HR Table Structure (sn_hr_core_*)

The HRSD data model is built on the platform Task [task] table:

• The base HR case table (in the core scope, prefixed sn_hr_core_) extends Task [task], inheriting state, assignment, work notes, SLAs, and approvals.
• Each COE case table extends the base HR case table (e.g., a Benefits case table, a payroll case table). This is classic table inheritance: child tables add COE-specific fields while sharing common case behavior.
• HR task records also extend Task and hang off a parent HR case.
• The HR Profile (sn_hr_core_profile, also surfaced as the Employee Profile) is a per-person record that references the platform User [sys_user] record and stores HR-relevant attributes; profile fields can be secured individually, and tax-identification fields support encryption. (UNVERIFIED: exact current table name sn_hr_core_profile vs. the newer Employee Profile table name varies by release — confirm against the HR Profile / Employee Profile docs for your target release.)
• Supporting configuration tables include HR service, HR service categorization (COE / case type), HR criteria, assignment rules, matching rules, and the HR skill tables.

Because HR cases extend Task, platform features (SLAs, workflow/Flow Designer, Agent Workspace, approvals) apply, but HR adds its own security layer on top so that Task-level access does not automatically grant HR case access.

HR Criteria, Conditions, Assignment and Matching Rules

• HR criteria are reusable condition definitions evaluated against a subject (usually the employee/profile or the case). They drive who sees a service, which lifecycle activity sets apply, which employee form is shown, and similar conditional behavior. HR criteria are distinct from catalog user criteria, though both gate visibility.
• Conditions on services and producers further refine eligibility.
• Assignment rules automatically set the assignment group/assignee on an HR case based on conditions (COE, location, service, etc.). Matching rules narrow assignment to agents who hold the required HR skills. Advanced Work Assignment (AWA) can push HR work to agents via queues instead of static groups. Test tooling exists to validate assignment rules before activation.
• Client roles / client role assignment rules automatically grant or revoke roles to users based on conditions, used to keep portal/agent access in sync with org data.

Configuration vs. Customization

HRSD is designed to be configured (services, criteria, templates, activity sets, COEs) rather than customized in code. Guided Setup walks an implementer through the core configuration. Prefer Flow Designer over legacy workflow for new automation.