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), which delivers Case and Knowledge Management, with companion scoped apps for 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 Zurich COE data model lists Employee Relations, Lifecycle Events, Payroll, Talent Management, Workforce Administration, Total Rewards, and HRIT Operations, plus Benefits, Compensation, Corporate Communications, and Global Mobility, which are inactive by default. Each COE has:

• its own case table that extends the base HR case table,
• its own HR services (the HR service COE decides which case table a case lands in),
• optionally an active COE security policy that limits its cases to listed groups.

Separation is not automatic: the HR case reader and writer roles cover all HR cases. Because each COE has its own case table, an active COE security policy can restrict a COE (for example Payroll) to specific groups, and Employee Relations adds case restriction configurations so that agents outside the permitted groups cannot read restricted ER cases even with case reader or writer roles. HR knowledge is secured per knowledge base by user criteria, not by COE.

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, topic category, topic detail), 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 which HR services an agent can request for a subject person, which lifecycle activities apply, which Employee Center content is shown, which document template is used, and similar conditional behavior. HR criteria are distinct from catalog user criteria: user criteria on the HR catalog item control which employees can see and request it, and user criteria can be created from an HR criteria record.
• 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.