These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
Feature · Employee changes
Example screen with sample data
Employee changes
Bring hires, promotions, transfers, manager changes and separations through a consistent review process. Each proposal explains what will change and when, while current employee information stays tied to the arrangement actually in effect.
OverviewPending Hire Approvals×
Core HR · Employee changes
New
Pending Hire Approvals
HR changes
| Change number | Employee | Kind | Effective date | Status | Prepared by | |
|---|---|---|---|---|---|---|
| HRC-60858 | Kofi Mensah | Hire | 03 Nov | Submitted | Maya Singh | |
| HRC-46413 | Hana Park | Rehire | 02 Nov | Submitted | Lucas Chen | |
| HRC-47343 | Elena Rivera | Hire | 20 Oct | Submitted | Elena Rivera | |
| HRC-29157 | Daniel Okoye | Rehire | 18 Oct | Submitted | Omar Haddad | |
| HRC-69564 | Kofi Mensah | Hire | 29 Oct | Submitted | Amara Costa |
6 of 6 records
HRC-60858HR changes · HRC-60858
HireEmployeeKofi Mensah
Effective date03 Nov
StatusSubmitted
Prepared byMaya Singh
Content version220
What you can do
Prepare a change that can be reviewed
The request records the employee or organizational subject, proposed before-and-after values, reason and effective date. It retains the actual preparer and material editors. An authorized Manager can request a team change; HR Specialist prepares only the delegated scope their current grant permits.
Delegated preparation is bounded by person, subject, action and time. It does not give HR Specialist unrestricted permission to edit accepted employment history or acquire an approval role. Revocation or expiry prevents further delegated action.
- State the effective employer, position and reporting relationship.
- Identify the employment episode and affected assignment.
- Keep requested timing separate from the time the change is recorded.
- Resolve stale record versions before submitting a revised proposal.
Make the approval apply to the exact proposal
An independent HR Manager reviews the content and its affected domain scope. The subject, requester and material editors cannot turn a second role into independent approval. Where technical configuration or a broader import needs Admin sign-off, that remains additional to the HR decision.
Changing the employee, dates, organization or material scope invalidates the earlier decision. Approval of one revision cannot authorize another. The accepted proposal retains the decision identity, evidence and current authority used at review.
| State of the work | What it establishes |
|---|---|
| Prepared proposal | A requested change with supporting facts |
| Approved revision | Authority for that exact reviewed content |
| Scheduled change | A future effective event, not today’s employee state |
| Applied result | The recorded effective outcome and linked history |
Apply the event at its effective boundary
Future changes remain scheduled until their conditions and effective boundary are met. A future hire does not immediately increase employed headcount, and a scheduled termination does not instantly remove an employee who is still employed today.
Applying a change updates the current employee projection, employment episode and affected position assignment together. Employment and position history retain the event’s effective time separately from its recording time. Capacity and overlapping assignments are checked again where the approved action requires them.
A termination date is the first nonemployed date for the ended episode. The previous assignment and employment history remain available. Rehire creates a new episode linked to the same verified person, preserving the earlier break and reviewed rehire eligibility.
Coordinate absence and return to work
Leave-of-absence start and return are explicit lifecycle events where the approved policy requires them. An employee can remain employed while shown as on leave. A return event restores the appropriate current operating state without creating a second hire or losing the original assignment history.
Routine day-based leave and its balance ledger remain separate from employment-state changes. A request for future absence does not immediately mark the employee away, and a leave cancellation cannot silently erase a previously applied employment event.
Manager receives operational dates and status needed to coordinate the team. Protected medical information, reasons and documents retain their own access classification throughout the request, decision, history and notification paths.
Correct history with its consequences visible
A cancellation before application preserves the cancelled proposal and releases its unused effects through the guarded workflow. A correction after application links to the original change and reconciles later employment, assignment, access, leave and obligation history as required.
Backdating cannot overfill a position, create overlapping employment or rewrite later decisions without review. The original event remains traceable, including what was known when it was recorded. Technical deletion or direct editing of accepted history is not a substitute for that correction.
Keep downstream work accountable
Configured identity, payroll, recruiting or benefits systems receive only the fields and actions owned by their agreed integration contract. A Core HR change can request a downstream update, but sending or acknowledging that request does not establish the external result.
Repeated source keys return the existing outcome. Changed content under the same identity is investigated, and uncertain external execution stays open for reconciliation. Imported historical events remain evidence at the cutover and cannot trigger fresh accounts, leave earnings or separation notices.
Recent Hires (last 30 days), Recent Terminations (last 30 days) and Open Positions expose the relevant work within scope. Headcount, Turnover Rate and Tenure Distribution use effective events and their stated populations rather than mutable current labels alone.
What it keeps track of
Data model- HR changes
- Versioned employee/lifecycle/master/policy proposal; only approved current content creates immutable history.
- Approval decisions
- Immutable actual-person decision bound to exact subject, revision, domain scope and conflict exclusions.
- Employment history
- Every lifecycle event: hire, promotion, transfer, manager change, leave-of-absence, termination, rehire.
- Employment spells
- Dated employment episode for a stable employee identity, preserving rehire breaks and employer changes.
- Position history
- The seat-side mirror of employment history: when a Position opened, was filled, refilled, or frozen — independent of which Employee occupied it.
- Position assignments
- One whole-seat dated primary assignment per employee; approved future intervals reserve capacity without changing present headcount.
- Employees
- The central person record and the single source of truth for who is employed. Every other HR app in the stack references this table.
- Access grants
- Effective role, delegated preparation or restricted subject/class access, separately authorized and revocable.
- Integration events
- Authenticated inbound fact and outbound request/outcome identity; external status cannot rewrite HR-approved employment.
- Migration batches
- Independently reviewed nonposting HR cutover preserving people, employment, obligations and unresolved external work.
Who uses it
Permissions- HR Manager
- Owns lifecycle proposals and independent domain decisions.
- Manager
- Requests permitted team changes.
- HR Specialist
- Prepares explicitly delegated work.
- Employee
- Supplies permitted self-service facts.
- Admin
- Maintains technical controls and any additional required activation review without replacing HR authority.
Set up Core HR your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.