Employee Lifecycle and Manager Workspaces

The Employee Lifecycle & Relations workspace groups work that follows an employee through onboarding, probation, job changes, workplace relations, recruitment handoff, and exit. My Team and Work Queue are separate views inside that workspace: they expose existing HR work to a manager or responsible owner rather than creating a second copy of the underlying records.

The workspace is intentionally capability-composed. Its presence does not mean every tab is enabled. The active service capability, tab-specific capability, and user's route/action permissions all matter. See Capabilities and Access for the complete map and known route/tab inconsistencies.

Workspace and capability map

Tab	What it handles	Capability boundary
Work Queue	Cross-workflow items that need an owner, approval, correction, or follow-up.	Onboarding and Transitions, Employee Relations, or Manager Self-Service.
My Team	Direct reports, team leave/attendance, roster coverage, onboarding, reviews, and assigned work.	Manager Self-Service.
Onboarding	Employee onboarding tasks and completion evidence.	Onboarding and Transitions.
Probation	Dated probation periods and review outcomes.	Onboarding and Transitions.
Employee Changes	Promotions/transfers, salary revisions, and employee benefits.	Each inner tab has its own capability: Onboarding and Transitions, Compensation, or Benefits.
Employee Relations	Grievances and disciplinary actions.	Employee Relations.
Recruitment	Vacancies and the candidate/application assessment process.	Talent Acquisition.
Exit	Separation, clearance, and final settlement.	Onboarding and Transitions or Employee Relations.

The workspace stores its selected tab in the tab query parameter. My Team stores its inner tab in team_tab. If a remembered tab is no longer allowed, the UI should select the first visible tab. A route-level gate must still permit the workspace whenever the user has a valid tab-level capability; two route/tab mapping mismatches are recorded in the capability guide.

Choose the source workspace before taking action

The lifecycle workspace is an index into HR work, not the owner of every workflow. Use this map to avoid entering the same business event twice:

Need	Authoritative workspace/record	Do not use instead
Change a person's current contact or master detail	Employee Management profile	A new employee record or a free-text manager note.
Change position, reporting relationship or grade	Approved position/employment change	Editing the old assignment or only changing the person's manager in a queue row.
Change base pay or recurring pay terms	Salary Revision / payroll enrollment as applicable	Editing a shared salary structure to update only one employee.
Put employee on or return from leave	Leave request and return-to-work record	A roster note or an unapproved attendance override.
Investigate a grievance or disciplinary issue	Restricted Employee Relations case	A generally visible employee note or performance review.
End employment	Separation, clearance, final settlement and lifecycle transition	Deactivating the user account alone.

The Work Queue and My Team can deep-link users to these owner workspaces. Use the queue to find and prioritize work, then finish it in the source record and return to confirm the queue reflects the new state.

Work Queue

The Work Queue combines records from existing workflows into an actionable list. It is not a new approval engine and it does not replace the source record's own workflow. The current filters include:

• View: This service, My work, or My direct reports.
• Status: Draft, Pending approval, Pending, Blocked, External pending, Failed, or Complete.
• Work item: Leave request, overtime request, onboarding task, probation review, separation, coverage exception, salary revision, promotion/transfer, or payroll period.
• Priority: Critical, High, Medium, or Low.

The status terms have distinct meanings:

Status	Meaning in the queue
Draft	Needs completion before it can be submitted.
Pending approval	Waiting for the assigned approver.
Pending	Needs an owner action.
Blocked	Cannot proceed until the named dependency is cleared.
External pending	Waiting for a provider or authority outside HR.
Failed	Needs investigation or correction.
Complete	No further action is required.

Use the row's Open HR workspace action to continue in the owning feature. Resolve the item there so the original employee, approval, activity-log, and financial records remain authoritative. Do not treat a queue status label as proof that a downstream payment, GL posting, external filing, or employee notification completed; open the source workflow and verify that result.

My Team

My Team shows approved current employees who report to the signed-in manager within the active HR service. Its tables query the same employee, leave, attendance, roster, onboarding, and performance records used by the ordinary HR workspaces. Team information is not copied into a separate manager-owned data model.

The inner tabs are:

Tab	What a manager sees	Available action examples
Direct reports	Active employees in the reporting line, with employee number, name, position, hire date, and status.	Read the manager's team list; use the owning HR workflow for employee changes.
Leave	Submitted/approved/rejected leave requests, dates, leave type, days, request and approval state.	Approve or reject a submitted request with the dedicated leave-approval permission.
Attendance	Attendance date, clock times, hours, overtime, status, and approval state.	Approve or reject a pending attendance record with attendance-approval permission.
Coverage exceptions	Coverage gaps, leave conflicts, availability and fatigue exceptions, with severity and status.	Acknowledge or resolve the exception with roster-update permission and a resolution note.
Rosters	Roster period, covered employees, status, and approval state.	Review the authoritative roster; roster changes remain in the roster workflow.
Onboarding	Direct-report onboarding tasks, checklist, assignee, due date, task status, and due state.	Start or complete a task when the manager has onboarding-task permission and the task permits completion.
Performance	Review/cycle progress and assigned reviewer information for direct reports.	Continue the review through the existing performance workflow and required permissions.
Team work	Queue records scoped to My direct reports.	Open the underlying work item.

The leave and attendance actions use confirmation/rejection flows and require their existing action permissions. Being a manager or seeing a row does not automatically grant the right to approve it. The backend and the HR service context remain responsible for scope and authorization; hiding a button in the browser is not a security boundary.

Onboarding

Onboarding Checklists are reusable setup templates. They define tasks and their required/optional nature; they are not themselves proof that an employee has completed onboarding. HR applies the checklist to an employee through the operational onboarding workflow, which creates assigned employee tasks with owners and due dates.

The operations view exposes task states such as Pending, In Progress, Completed, and Skipped, and due states such as Overdue, Due Today, Upcoming, and No Due Date. The task detail view shows its owner, due state, and supporting context. Start and completion actions are permission-controlled. If a task requires evidence, attach or reference the approved shared document through the configured document workflow; do not mark it complete merely because the employee has supplied an unreviewed file.

Completing the task list is not identical to confirming employment, passing probation, enabling payroll, granting application access, or completing statutory onboarding. Those outcomes belong to their own approved employee, access, payroll, and compliance workflows.

Recommended operating sequence

1. Maintain reusable checklist templates in HR Setup. Keep required legal, safety, equipment, identity, policy acknowledgement, and role-training tasks explicit; avoid a single vague task such as “complete onboarding”.
2. After the employee exists and the approved checklist is selected, generate employee-specific tasks. Check the assignee and due date on every required task; a template owner is not necessarily the correct task owner.
3. Assign employee-facing tasks to the employee and operational tasks to the responsible HR, manager, IT, finance, or safety owner as appropriate.
4. Start work only when the owner has accepted responsibility. Mark a task Completed only after verifying the required evidence or action; use Skipped only where the task is optional or an authorized exception is recorded.
5. Review overdue and blocked tasks in the queue. Record the actual dependency (for example a provider or equipment delay) rather than marking the item complete to clear the queue.
6. At onboarding close, reconcile checklist completion with the employee's approved position, current employment, payroll enrollment, and any required user access. Checklist completion does not activate those records itself.

An onboarding task that requires a document is not necessarily a document retention/compliance control. Confirm that the evidence is stored in the approved document service, has the required access, and can be found again by its owning process.

Probation

Probation records link an employee to an approved employment and retain the start date, planned end date, review date, reviewer, current state, possible extended end date, and review notes. The visible status choices are In Progress, Extended, Confirmed, and Terminated.

Review the record at the scheduled decision point. An extension should record the revised end date and review context; confirmation or termination should capture the authorised outcome. A probation status is not, by itself, an employee lifecycle transition or access decision. Apply the corresponding employment/status, payroll, position, and system-access changes through their own controls and verify the effective date.

Use this review sequence:

1. Compare the review date and planned end date with the signed employment terms. Do not let an expired end date silently decide the employment outcome.
2. Gather the reviewer's evidence and any employee response through the approved review process. Keep confidential material out of open notes.
3. Record one explicit outcome: confirm, extend, or terminate, with the decision-maker and rationale required by tenant policy.
4. If extended, set a new end/review date and assign the next review owner.
5. If confirmed, verify the employee remains Active and review payroll, position, benefits, and access eligibility. If terminated, use the separation process; do not only change the probation label.

Probation data can be visible in HR and manager workspaces, but the role-specific permissions still control who can see or update the underlying record.

Employee Changes

Employee Changes is a nested set of tabs, not one mixed transaction list:

• Promotions & Transfers records a role/position movement through the approved employee-change workflow.
• Salary Revisions records effective-dated compensation changes and their approval history. Shared salary structures should not be edited to rewrite one employee's past pay.
• Benefits opens the enrolment, life event, waiver, provider invoice, and total-reward workspace described in Benefits and Total Rewards.

Each change affects downstream consumers differently. A transfer can affect reporting and position occupancy; a promotion can also trigger grade/compensation review; a salary revision affects payroll only from its approved effective date and calculation policy; a benefit event changes coverage only through the benefit enrolment workflow. Do not infer that recording a request has already updated payroll, access, the manager hierarchy, or GL.

Promotion, transfer, and salary revision controls

For any employee change, capture the employee, proposed new state, effective date, reason, supporting approval/evidence, and the appropriate approver before submission. Then inspect the decision result and the employee timeline. An approved request and an effective change are not always the same instant: the effective date may be later, and payroll should consume only the approved terms that apply to the selected period.

Before closing a change, check each affected record explicitly:

• Reporting line: does the manager now have the correct direct report?
• Position occupancy: is the former position released and the new one occupied without exceeding allocation?
• Grade and pay: does the employee have the intended approved compensation record, not merely a new title?
• Payroll: does the new pay begin in the intended period and retain the old value for earlier periods?
• Scheduling and leave: do future rosters, leave approvals, and coverage use the correct reporting/position context?
• Access: are system roles still appropriate? HR position changes do not themselves grant or revoke application permissions.

Immediate versus scheduled lifecycle status

Employee lifecycle controls have special behavior that should not be confused with the effective-dated Employee Changes tabs. The frontend transition form currently says that activation, suspension, and reinstatement take effect immediately and cannot be future-dated. The backend procedure, however, accepts a future effective date and writes a LIFECYCLE_SCHEDULED event for an effective-dated worker to apply. This is a UI/source contract mismatch. Until the interface and scheduled-worker behavior are verified together, use the form for immediate transitions only, or obtain an approved operational procedure for a future date. Do not assume that entering a future date either applies it now or guarantees a scheduled change without checking the lifecycle timeline and resulting status.

The Preview action is non-persisting: it validates the employee, service scope, approval, current employment assignment, position state, hire-date boundary, and reason. A successful preview means “the current checks passed”; it does not mean the transition was executed. A persisted activation/reinstatement also does not automatically enable the user's login. Employee status and user access must be inspected separately in Employees.

Employee Relations

Employee Relations separates Grievances from Disciplinary Actions. These records can contain sensitive allegations, statements, investigations, evidence, decisions, and outcomes. Access to an ordinary employee profile must not be treated as permission to see a confidential case.

Use the dedicated Employee Relations capability and case permissions. Preserve a clear chronology, limit free-text details to what is necessary, and attach evidence using the approved shared-document process. A case record is not a substitute for a formal legal, safety, or external-authority process; record any external dependency and its result in the appropriate case workflow. A case outcome does not automatically suspend or terminate employment—use the authorised lifecycle transition with its reason and effective date.

Recruitment

Recruitment separates workforce demand from candidate records. A vacancy is created from an approved workforce requisition and an approved position; publishing or withdrawing it is controlled by recruitment permissions. Candidate identity is a recruitment record, not an employee record.

The Recruitment workspace has tabs for Vacancies, Candidates, Applications, Interviews, Assessments, Checks, and Offers. The visible stage/status values include:

Record	Examples of states or decisions
Vacancy	Draft, Published, Closed, Withdrawn.
Candidate	Active, Hired, Withdrawn, Rejected.
Application	Applied, Screening, Interview, Assessment, Checks, Offer, Hired, Rejected, Withdrawn.
Interview	Planned, Completed, Cancelled, No Show; may record score and recommendation.
Assessment	Planned, In Progress, Completed, Waived; captures outcome and score.
Checks	Requested, In Progress, Cleared, Failed, Waived.
Offer	Draft, Issued, Accepted, Declined, Expired, Withdrawn.

Record each stage as it occurs and retain the reason for rejection, withdrawal, exception, or waiver. An accepted offer is not proof that the employee record, position assignment, contract, payroll enrollment, or system account has been created. Complete the employee handoff using the approved Party/employee process, then verify the new employee and employment records rather than assuming recruitment created them automatically.

Hiring handoff checklist

When an offer is accepted:

1. Confirm the vacancy is tied to an approved requisition and position and has remaining authorized headcount.
2. Reconcile candidate identity, contact data, offer terms, expected start date, and signed evidence. Resolve candidate duplicates before creating a shared Party.
3. Use the employee creation workflow to select or create an Individual Party with the HR Employee role, then create the employee. The employee number is generated by the entity ID-template procedure.
4. Create the approved current employment/position assignment and contract details. Employee creation initially sets employment status to Inactive; it does not implicitly activate the hire.
5. Obtain employee approval if configured, then explicitly activate when the start conditions and approved active position are satisfied.
6. Generate onboarding tasks and separately enroll payroll/benefits where those capabilities are enabled.
7. Provision a user account only if required. The HR-side access action establishes the Staff Member Party role before the user form; the app's roles and permissions are still assigned through access administration.
8. Confirm recruitment's hired/filled state and the downstream employee, position, payroll, onboarding and access records agree.

Keep candidate, Party, employee, and user identifiers linked in their own records. Never treat a candidate status as evidence that any downstream record was created.

Exit and downstream handoffs

The Exit tab opens the separation workflow. See Separation for notice, clearance, final settlement, payment, access, and completion controls. The lifecycle workspace is an entry point; a row or status here does not prove that all clearance owners have signed off or that final pay has posted and settled.

Before closing any lifecycle item, reconcile the owning HR record with the affected position, payroll, leave/attendance, benefits, documents, system access, manager scope, and accounting/payment records. Retain effective dates and audit history; do not make current-state edits that erase the path by which the employee reached that state.

The separation status change has a stricter backend precondition than a normal status toggle: it must reference the approved, non-cancelled separation for the same employee, business-unit scope and effective date. If the transition is blocked, open the separation record and reconcile its approval/effective date; do not try to force the employee to Exited through an unrelated edit. See Separation for clearance and settlement readiness.

Related guides

• HR Overview
• Capabilities and Access
• HR Setup
• Employees
• Leave and Attendance
• Benefits and Total Rewards
• Payroll
• Separation