-
01 HR Open the employee record once.
A new hire is approved. The employee record carries role, manager, start date, location, cost center, and access profile. The onboarding workflow creates tasks, assigns Knowledge entries, requests setup, and routes approvals from that same record. In the AI pilot, AI Builder proposes an onboarding checklist based on role and team history; HR reviews the diff and ratifies. When the employee leaves, offboarding closes the same record that opened access — entitlements, approvals, and the audit history follow.
-
One employee spine
The row HR owns is the requester Approvals routes against, the payee context finance reads, and the manager workflows use.
Org structure on the row
Manager relationships, departments, and cost centers live on the same record approvals and finance read.
Leave on the spine
Leave requests, balances, and approvals write back to the employee record — not to a parallel time-off tool.
Offboarding closes what HR opened
The same record that opened entitlements closes them. Audit history follows the row, not five vendor logs.
Cost center reads HR
Finance reads role, location, and cost center from the employee record — no monthly headcount reconciliation.
One audit log
Every HR write — hire, edit, leave, offboard — logs actor, target row, before, after. The auditor reads a config screen.
-
02 Knowledge Answers that cite the work.
Three return tickets close with the same resolution. AI Builder proposes a draft article: the resolution, the source ticket citations, and a related macro. The support lead reviews the diff, edits the draft, and ratifies or rejects it. If ratified, the article keeps provenance back to the tickets — and when an agent or assistant later uses the article, the answer cites both the article and the source records that justified it. The boundary: AI drafts the knowledge, a lead owns publication.
-
Drafts from repeated work
AI Builder watches for the same resolution across multiple tickets, the same answer across multiple onboarding threads, and proposes a draft with the source records as citations.
Citations back to the row
Every article links to the tickets, employees, or accounts that produced it. Open the article, see the work it came from.
Permissions follow the record
Article ACL inherits from the source record — no parallel permission tree to maintain in a wiki.
Draft and publish audited
Every draft, edit, and publication writes an audit row — actor, agent_id (if AI), before, after.
-
03 Timesheet From clock-in to payroll on the same hour.
An employee clocks in. The time entry records employee, location, start time, and source. Later, a manager allocates part of the shift to a project — the same time record carries the project context. At clock-out, overtime rules evaluate against the employee record and approval routes to the right manager. After approval, payroll and finance read the approved time context instead of importing a separate copy; project actuals read the same hour for burn and billing.
-
Clock-in tied to the employee
Time entries reference the employee record directly — same row HR, finance, and approvals already read. No separate time-tool identity.
Project allocation on the row
A shift can be split across projects on the same time record — project burn reads what payroll posts.
Overtime against the rules
Overtime evaluates against the employee record at clock-out, not in a separate after-hours review batch.
Payroll reads, never imports
Payroll close reads the approved time context. The same hour is never copied to a second tool. (Planned.)
Knowledge assigned by role, completed by employee, audited by manager — on the employee record itself. Skills accrue as proofs; roles read them; promotions reference them.
The substrate is the employee record. The graph that connects skills to roles, career paths, and competency frameworks follows.
Production vs Pilot
- Employee records — role, manager, location, cost center
- Org structure and manager relationships
- Leave / absence workflow
- Offboarding workflow tied to access context
- audit_events for every HR record change
- AI-proposed onboarding tasks (HR pilot)
- AI-proposed knowledge drafts with source-record citations (Knowledge pilot)
- Hiring, performance-review, and comp-review workflows (HR — planned)
- Formal knowledge taxonomy and lifecycle management (planned)
Where it fits
HR, time, and knowledge share records with Ticketing , Workflows , ERP , CRM , and AI Builder — the same row across every module that wrote it. No second copy, no reconciliation step.
Often read alongside: Managers , Executives , and Finance & Compliance .
Bring one onboarding flow, or one repeated ticket — we'll run it live on your data.
New-hire onboarding, leave approval, offboarding access close — or three tickets your support team closed with the same resolution last month. Twenty-five minutes. We open the admin, model the flow against a sandbox of your employee + ticket data, and show what changes when HR, the work, and the knowledge that comes from it share the same record.