⚠ AI-DRAFT — v0.1
This document was generated by Novaworks AI (Claude) as a first-pass outline PRD. All architectural assumptions are unverified. Sections marked NOTE require human review before this document advances to a reviewed draft.

Version	Date	Author	Notes
v0.1	2026-07-04	Novaworks AI (Claude)	AI-generated outline — prioritization only

Outline PRD: Novaworks × ServiceNow HRSD + Employee Center Integration¶

Status: Draft — For Prioritization Only
Scope: Integration surface between Novaworks and ServiceNow HRSD and Employee Center (EC). CKM ticketing integration is explicitly out of scope — covered in a separate PRD.

Strategic Context¶

This PRD serves two active company priorities simultaneously:

Priority 1 — Enterprise Side Car
Fast-to-adopt enterprise motion that keeps incumbent HCMs in place while inserting Novaworks as the AI orchestration layer. ServiceNow is both a co-sell partner and a native deployment environment. Data sync and Worker Activation features are the minimum viable integration surface for this motion.

Priority 2 — Mid-Market HCM (Ateko + Design Partners)
Proving the Novaworks constellation with real customers. Approval Hub and Slate surface exploration unlock workflows that design partners can experience natively inside ServiceNow, reducing change management friction.

Feature Set¶

F-01 — Employee Center Profile Write-Back (Novaworks Worker → sn_employee_profile)¶

Priority: Low — Optional Direction: Outbound only (Novaworks Worker record → sn_employee_profile)
Deployment Target: Mid-Market / Novaworks-as-SOR

Why we're building it (company):
Where Novaworks is the system of record (mid-market / Ateko), the ServiceNow Employee Center profile should reflect Novaworks ground truth. sn_employee_profile is a thin, broadly-readable presentation surface in EC — this feature keeps the employee-facing profile consistent with Novaworks without requiring HRSD access.

Why it matters (customer):
Employees see accurate profile data in Employee Center — the experience layer they already use — sourced from the Novaworks system of record.

What it does: - Writes a minimal set of Novaworks Worker fields outbound into the ServiceNow sn_employee_profile table. Optional; disabled by default; enabled per deployment.

Note

Some research needed to determine exactly which fields are OOB.
Note that if HRSD sync (F2) is installed, this module should be disabled, as writing anything to sn_core_hr_profile also writes this data to the sn_employee_profile. This needs to be confirmed

F-02 — Core HR Schema Sync (Novaworks Worker ⇄ sn_hr_core_profile)¶

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.

F-03 — Employee Works Slate Framework (Proof of Concept)¶

Priority: Low — Multi-Surface Agent Strategy
Direction: Outbound surface (Novaworks agents surfaced in Slate)
Deployment Target: Enterprise

Why we're building it (company):
ServiceNow launched Employee Slate (Moveworks-powered) in May 2026 — which provides a new framework for AI native interface also called AIUX. Novaworks needs to understand how to surface our components into Slate so that an enterprise customer who standardized on Moveworks/Slate will not see Novaworks as an overlapping functionality.

Why it matters (customer):
Enterprises already invested in ServiceNow Employee Center get Novaworks agent capabilities without leaving their existing employee experience layer.

What it does: - Surface at least one Novaworks agent interaction natively inside the Slate UI - Test Slate's extensibility model against Novaworks' MCP/A2A proxy architecture - Document: what Slate allows, what it blocks, where Novaworks' identity model fits or conflicts - Deliverable is a PoC report and feasibility assessment — not a production feature

NOTE: This is explicitly scoped as discovery. Success is defined as a written assessment of integration feasibility, not a shipped feature. Scope must not expand mid-PoC.

F-04a — Approval Hub Integration (Novaworks-Initiated Approvals)¶

Priority: High — Mid-Market HCM
Direction: Novaworks → EC Approval Hub
Deployment Target: Mid-Market (Ateko)

Why we're building it (company):
Novaworks agents initiate HR workflows (onboarding, transfers, offboarding) that require human approval. Routing those approvals through EC Approval Hub means Novaworks fits natively into the manager and HR workflow experience customers already use — rather than creating a parallel approval channel.

Why it matters (customer):
Managers receive and action Novaworks-initiated approvals directly in their existing Employee Center experience. No separate Novaworks portal login required.

What it does: - Novaworks creates approval requests routed to EC Approval Hub via ServiceNow API - Approval request payload includes Novaworks context (agent, workflow, policy citation) - Approval decision (approved/rejected) returned to Novaworks via callback or polling - Novaworks agent resumes or halts workflow based on approval outcome

F-04b — Automated Policy-Based Approvals (EC Integration)¶

Priority: Medium — Policy-as-Code Differentiation
Direction: Novaworks Policy Engine → EC Approval Hub
Deployment Target: Mid-Market (initial); Enterprise (follow-on)

Why we're building it (company):
ServiceNow recently released automated policy-based approval capability in EC. This is a direct touchpoint for Novaworks' core differentiation: Policy-as-Code. Testing automated approval routing based on Novaworks policy rules demonstrates that Novaworks can enforce policy decisions at the approval layer — not just recommend them.

Why it matters (customer):
Low-risk, policy-compliant requests get auto-approved without manager interruption. Policy violations surface immediately at the approval stage with a cited rule — not after the fact.

What it does: - Novaworks Policy Engine evaluates approval requests against configured policy rules before routing to Approval Hub - Requests meeting auto-approval criteria are resolved by Novaworks and logged — not queued for human review - Requests failing policy checks are routed to human approvers with a policy citation attached - Audit trail written to Novaworks (and optionally synced to HRSD) for every auto-approved transaction

NOTE: This feature depends on F-04a being stable. It should not be prioritized ahead of F-04a. The newly released ServiceNow capability needs to be assessed for compatibility with external policy engines before committing to this feature.

F-05 — Worker Activation Integration (Novaworks → HRSD Enterprise)¶

Priority: High — Enterprise Side Car
Direction: Novaworks → HRSD
Deployment Target: Enterprise

Why we're building it (company):
Worker Activation is one of the highest-value HR events in an enterprise — it triggers provisioning, system access, benefits enrollment, and onboarding workflows. A proper messaging and integration of Novaworks worker activation into broader HRSD Enterprise Life Cycle Events and Journeys is required when we get to enterprise customers.

Why it matters (customer):
New hire onboarding that previously required manual HRSD entries or custom integrations gets handled by Novaworks agents — with policy enforcement applied before any record is written.

What it does: - Novaworks agent submits Worker Activation event to HRSD Enterprise via API on completion of onboarding workflow - Activation payload maps to HRSD worker record schema - Pre-submission policy check: Novaworks Policy Engine validates activation data before write - Activation status (success/failure) returned to Novaworks and surfaced to HR admin - Failure path: agent alerts HR agent or escalates via ticketing module (per Ticketing Integration PRD) - It should be possible for Novaworks worker activation to be part of the overall ServiceNow journey.

NOTE: HRSD Enterprise Worker Activation API schema and required entitlements must be confirmed. The policy enforcement step pre-write is a differentiator and should be preserved — not simplified away in v1.

Prioritization Summary¶

Feature	Priority	Horizon	Strategic Driver
F-01 EC Profile Write-Back (→ sn_employee_profile)	Low — Optional	Revisit after F-02	Novaworks-as-SOR (mid-market)
F-02 Core HR Schema Sync (⇄ sn_hr_core_profile)	High	Now (0–3 mo)	Enterprise Side Car + Mid-Market
F-03 Slate Framework PoC	Medium	Now (PoC only)	Competitive Intelligence
F-04a Approval Hub (Novaworks-Initiated)	High	Now (0–3 mo)	Mid-Market HCM
F-04b Automated Policy-Based Approvals	Medium	Next (3–6 mo)	Policy-as-Code Differentiation
F-05 Worker Activation → HRSD	High	Now (0–3 mo)	Enterprise Side Car

Out of Scope (this PRD):
- CKM ticketing integration → covered in Ticketing Integration PRD - Outbound sync from HRSD to Novaworks in F-02 bidirectional mode (enterprise) deferred to confirmed deployment scenario - Approval Hub UI customization - Slate production integration (F-03 is PoC only)

Open Questions¶

Which ServiceNow entitlements (license tier, API scopes) are required for F-01, F-04a, F-05?
Is F-02 bidirectional mode required for Ateko go-live, or is inbound-only sufficient for the design partner phase?
What is the Novaworks team's assessment of the new ServiceNow automated approval capability (F-04b) — is it compatible with an external policy engine?
Who owns the Slate PoC (F-03) — Vivek's AI Differentiation team or a dedicated spike?
Does F-05 Worker Activation need to be production-ready for Ateko, or is Ateko's go-live scope limited to Core HR sync?
Is F-01 (Novaworks Worker → sn_employee_profile) warranted at all? If F-02 is co-deployed, Group A fields project into EC automatically and F-01's only remaining write set is Group B (pronouns, bio, preferred name) — which are typically employee self-service. Confirm whether Novaworks should author any EC-native fields as SOR.
Which sn_hr_core_profile fields does F-02 own vs. read from sys_user (directory/AD-mastered)? Novaworks must not author identity fields the enterprise directory masters.
What ServiceNow entitlements (license tier, API/ACL scope) are required for F-02 sn_hr_core_profile access (sensitive), and separately for F-01 sn_employee_profile write (lower-privilege fallback)?