Critical Core HR Transactions¶
Questions or comments?
Post them as a comment on the tracking issue -- requires a GitHub account with access to this repo.
Novaworks AI | x_novaw_corehcm_* (per schema/core-hr-schema.md — see Open Questions for the naming-and-references.md prefix conflict)
Major Change History¶
| Version | Date | Author / Notes |
|---|---|---|
| 1 | 2026-08-11 | Ravi Buddharaju — Feature Set created from #316's sub-issue material (policy/spec/JTBD docs) and the reviewed core HR schema. |
Business case¶
- What's broken, inefficient, or missing today? Six of Core HR's most common employee-lifecycle changes — personal data updates, job description/skill-tag changes, promotions, demotions, salary changes, and bonus/incentive awards — have no configured transaction in Nova's transaction framework yet. Each was named explicitly on the 7/16–7/22 Core Transaction Priorities call as work Ateko (the mid-market design-partner customer) needs before it can run its HR operations on Novaworks — without them, routine changes have no system-of-record path at all: no validation, no approval routing, no audit trail.
- Who has the problem? Workers (need self-service for their own address/contact, dependent, and tax-withholding changes — today there is no path at all, deterministic or otherwise); Direct Managers (own job-description/skill-tag updates and initiate promotions/demotions, with no guided workflow distinguishing a level change from a scope change); HR Business Partners (are the compliance approver on dependents, tax withholding, promotion/demotion band compliance, and compensation changes, with no tracked queue to work from); HR Operations (has no audit trail to prove a compliance- sensitive change — tax withholding, dependent additions, compensation — happened correctly and on time).
- What's the measurable cost of not solving it? Payroll errors from ungoverned salary/bonus changes; compliance exposure from tax-withholding and dependent changes that bypass HR review; promotion/demotion decisions made without compensation-band validation; no audit trail to satisfy an auditor after the fact; and, concretely for Ateko, a go-live blocker — a mid-market customer using Novaworks as its system of record cannot operate without these six transactions existing in some form.
- Value to customers. Workers get instant self-service for routine personal-data changes instead of waiting on HR for something that carries no compliance risk; managers and HR Business Partners get a single, auditable, policy-driven path for every job, promotion, demotion, and compensation change, with the right approvers routed automatically and nothing able to skip a required review.
- Value to Novaworks. These six transactions are foundational, table-stakes HCM
capabilities every full-suite incumbent (Workday, BambooHR, Rippling, HiBob) already
ships — not having them blocks Novaworks from being viable as a system of record for
any mid-market customer, Ateko specifically named. Shipping them unblocks Ateko's
go-live and is a prerequisite for any further Core HR land-and-expand in the
mid-market motion (per
skills-product/business-context.md's system-of-record framing for this segment). - Novaworks lens. Rather than building six one-off forms/workflows, each
transaction is configured against the same transaction framework already live in
nova-corehcm-sn-app(TransactionContextRunnerService+ Decision Table routing) — the framework decides per-transaction whether a change is deterministic and auto-applies (address/contact info) or requires approval routing (compensation, promotion/demotion, dependents/tax), instead of every transaction type carrying its own hand-built approval chain the way incumbents' static workflow builders do.
Goal¶
Every one of the six transactions — Personal Data Updates, Job Data Changes, Promotion, Demotion, Salary Changes, and Bonus and Incentive Awards — runs through Nova's configurable transaction framework with the correct validation, approval routing, and audit trail, so Ateko (and any future mid-market customer) can run these routine and organizational-management changes on Novaworks as their system of record.
Scope¶
x_novaw_corehcm_*, per the reviewed schema/core-hr-schema.md (the x_nova_corehcm_*
prefix in skills-product/naming-and-references.md is stale against this — see Open
Questions). Touches nova-corehcm-agent (intent detection, decision routing) and
nova-corehcm-sn-app (transaction configs, Decision Tables, schema deltas). Explicitly
excludes the other two sub-issues under #316 — Cost Center Change (#664) and Org
Restructuring/Reorganizations/Hierarchies (#672) — neither has a policy/spec/JTBD trio
available yet; they're deferred to a later pass rather than blocking these six.
Sources¶
- Seven policy documents (
HR-EMP-002,HR-ORG-004,HR-ORG-005,HR-ORG-007,HR-CE-001,HR-CE-002, plusHR-ORG-006for the deferred Cost Center Change) —corehr-tns/folder. - Six Transaction Spec + JTBD Canvas documents covering the same six transactions, each tagged with its GitHub sub-issue number — same folder.
- Core Transaction Priorities call, 2026-07-16–2026-07-22 (referenced directly in the Personal Data Updates and Job Data Changes specs).
schema/core-hr-schema.md— reviewed, current Core HR schema.
Related PRDs¶
feature-sets/employee-offboarding/concept.md and
feature-sets/worker-document-management/concept.md — both adjacent Core HR Feature
Sets in this repo. Worker Document Management is a likely dependency: the Personal Data
Updates and Job Data Changes specs both flag a missing document/attachment reference
needed for dependent-addition and tax-withholding supporting documentation.
Who this is for¶
| Persona / Role | Friction today | Value gained |
|---|---|---|
| Employee / End User | No self-service path for address, contact, dependent, or tax-withholding changes — every change today would have to go through HR regardless of compliance risk. | Instant self-service for address/contact changes with no approval wait; a guided, documented path for dependent/tax changes. |
| Manager | No guided workflow to distinguish a job-description/skill-tag update from a level change, or to initiate a promotion/demotion with the right compensation-band checks. | A single workflow per transaction type that routes to the right approver and blocks a submission that's actually a different transaction. |
| HRBP | No tracked queue for the compliance-sensitive approvals (dependents, tax withholding, promotion/demotion band compliance, compensation) — coordinated ad hoc today. | An auditable, policy-driven approval queue for every compliance-sensitive change, with validation already run before it reaches them. |
| HR Operations / HR Ops | No audit trail to prove a compliance-sensitive change (tax withholding, dependents, compensation) happened correctly and on time. | A permanent, queryable transaction/audit record per worker, per change, satisfying periodic compliance audits. |
What we are building¶
| # | Feature | Folder |
|---|---|---|
| 1 | Core HR Transaction Bundle: Personal Data, Job Data, Promotion, Demotion, Salary & Bonus | core-hr-transaction-bundle/spec.md |
Phasing, effort, and sprint/month targets are planning decisions — they live on the
GitHub issue (issue-url in frontmatter), not here.
Table-Stakes & Differentiation¶
| Table-stakes capability | Bar set by | Where we cover it |
|---|---|---|
| Self-service personal-data updates with compliance gating on sensitive fields | Workday, BambooHR, Rippling, HiBob | Feature #1 |
| Promotion/demotion workflow with compensation-band validation | Workday, Rippling | Feature #1 |
| Structured compensation change approval (merit increases, bonus/incentive awards) | Workday, Rippling, HiBob | Feature #1 |
| Job description / skill-tag maintenance separate from level changes | Workday, HiBob | Feature #1 |
Differentiation. - One configurable transaction framework (Decision Table + ordered context scripts) drives all six, rather than six separately-built workflows — a new transaction type is configuration, not custom build, unlike incumbents' per-workflow builders. - The framework decides deterministic-vs-approval-gated per transaction automatically (e.g. address/contact auto-applies, dependents/tax routes to HRBP) rather than forcing every transaction through a uniform approval chain. - Every transaction produces one denormalized audit record from initiation through SOR update, feeding both worker-facing confirmation and HR's compliance audit — not two separate systems of record for "what was requested" and "what happened."
UX & Interaction Design¶
Not yet available.
Open Questions¶
| # | Question | Blocks |
|---|---|---|
| 1 | skills-product/naming-and-references.md states the Core HR table prefix as x_nova_corehcm_*; schema/core-hr-schema.md (reviewed against the live app) and tables.md both use x_novaw_corehcm_*. Which is correct, and should naming-and-references.md be corrected? |
Scope section accuracy across every Feature in this Feature Set. |
| 2 | Resolved: blocks on worker-document-management — this Feature Set does not build any document/attachment reference itself. |
Personal Data Updates' scope within the combined Feature; confirmed cross-Feature-Set dependency. |
| 3 | Unclear whether Worker needs to support more than one concurrent tax jurisdiction (multi-state/country withholding) — flagged in the Personal Data Updates transaction spec as "confirm before build." |
Personal Data Updates' schema delta. |
| 4 | Resolved: Job Data Changes writes a new effective-dated Job Assignment entry (closing the prior one via job_end_date), not a Job Profile edit or a new override field. |
Job Data Changes' schema delta. |
| 5 | No reason-code field exists yet for a Job Data Change (role refresh / skills update / job architecture alignment). | Job Data Changes' schema delta. |
| 6 | Owner and product-manager above are unconfirmed — no verified GitHub @handle for either. |
Frontmatter accuracy; will need correcting once a Commitment Meeting issue exists specifically for this Feature Set (currently pointing at the parent #316, which also covers the two deferred transactions). |
| 7 | Cost Center Change (#664), Org Restructuring (#672), and — as of implementation planning — Bonus and Incentive Awards (#674, no existing home in nova-compensation-sn-app's schema) are all deferred out of core-hr-transaction-bundle. Should all three become later Features under this same Feature Set, or does Bonus and Incentive Awards need its own Feature Set once that app's team is engaged? |
Future scope of this Feature Set vs. a new one. |
For internal engineering review only. Not for external distribution.
Novaworks AI | Confidential