Skip to content

FEATURE SPEC

Questions or comments?

Post them as a comment on the tracking issue -- requires a GitHub account with access to this repo.

Core HR Schema Sync (Novaworks ⇄ HRSD)

Parent Feature Set: ../concept.md.

Note

Following information is reverse engineered for [AI-DLC]. Review and remove this note before proceeding.

Important

To follow the AI-DLC process, fill this spec with PM assistance first.

GitHub Issue Description (verbatim)

Issue #389, titled "[Feature] Core HR Schema Sync (Novaworks ⇄ HRSD)":

Summary

--

Acceptance Criteria

Expected Business Value

--

Additional Context

No response

All fields are placeholder — the GitHub issue itself carries no content beyond its title.

Matching PRD Content

Reproduced verbatim from ../reference/sn-integration-v1.md, F-02.

Priority: High — Enterprise Side Car + Mid-Market Direction: Either direction or both depending on deployment scenario Deployment Target: Enterprise (inbound-dominant); Mid-Market / Novaworks-as-SOR (outbound-dominant)

Why we're building it (company): For customers like Ateko where Novaworks is the system of record for Core HR, changes originate in Novaworks and propagate to HRSD sn_hr_core_profile. For enterprise deployments where Novaworks is not the system of record, the direction depends on the customer preference. This feature must support both topologies. sn_hr_core_profile is the authoritative HR record in ServiceNow (for HRSD) — the rich table F-01's thin EC profile is merely projected from.

Why it matters (customer): Customers don't want to maintain two systems manually. This sync eliminates dual entry and ensures agent decisions in Novaworks reflect ground truth from HRSD — or push ground truth into HRSD depending on who owns the record.

What it does: - Syncs the Novaworks Worker record against the HRSD HR Profile (sn_hr_core_profile) table — the authoritative Core HR record. - Inbound (enterprise topology): sn_hr_core_profile → Novaworks Worker. - Outbound (mid-market / Novaworks-as-SOR): Novaworks Worker → sn_hr_core_profile. Writing here means ServiceNow's own business rules then project the relevant subset down into sn_employee_profile automatically — so F-01 is redundant in this topology for Group A fields (see F-01). - Conflict resolution rule: deployment configuration determines authoritative source; no merge logic in v1. - Sync scope: employment lifecycle fields only (hire, transfer, termination, role change) — not compensation or benefits in v1.

NOTE: sn_hr_core_profile references sys_user for base identity (name, email, manager) and adds HR fields. Confirm which fields F-02 owns vs. which are read from sys_user (directory-sourced) — Novaworks should not attempt to author identity fields mastered by the enterprise directory/AD.

NOTE: sn_hr_core_profile is access-restricted (sensitive HR data). Outbound writes and inbound reads both require elevated ServiceNow entitlements — confirm the license tier and API/ACL scope. Where those entitlements are unavailable, F-01 (EC sn_employee_profile) is the lower-privilege fallback surface.

NOTE: Bidirectional sync requires a conflict resolution strategy. v1 should enforce a strict "one authoritative source" configuration per deployment — no hybrid authority.

Sources

  • GitHub issue #389
  • ../reference/sn-integration-v1.md, F-02