Leave requests and approvals¶
Leave connects a person's planned time away with the organization's leave rules, available allowance, cover arrangements and review process. It gives staff a request history and gives authorized leave administrators a way to manage policies, decisions and balance corrections.
This draft explains request preparation, submission, personal reads, balance meanings, manual corrections, policy administration, decisions, withdrawal, leave changes, automatic lifecycle processing and background updates. The intended steps follow WorkOS Final Screens. The inspected frontend uses demonstration data and simulated outcomes; its actions are not connected saves. The inspected source has no automatic allowance-posting job; full operational reconciliation remains unfinished. Environment availability and audience acceptance remain unverified.
How the parts fit together¶
| Part | What it means |
|---|---|
| Policy | The named rule for a kind of leave: how time is counted, whether approval or cover is needed, supporting-file requirements and balance rules. |
| Assignment | The policy applies to a person directly or through a position for an effective period. Seeing a policy in an administrator's catalogue does not make everyone eligible. |
| Request | One person's selected policy, period, note and attached supporting evidence. |
| Balance | Recorded grants, accruals, reservations, consumption, reversals, expiry and manual corrections for one person and policy. |
| Cover | Another person identified through the organization structure when the policy requires it. Cover and approval are separate responsibilities. |
| Approval route | No approval, a direct decision, or a configured published workflow. Submission and approval are separate outcomes for the latter two. |
The same organization can use different rules for annual leave, study leave or another policy. These are policy choices, not fixed platform entitlements. Do not infer an allowance, paid status or contractual right from a sample policy name.
For a task, follow Request leave and understand your balance. The People guide explains staff context, and organization routing explains why structure and assignment purpose matter.
Authorized administrators can follow Create, update and assign leave policies. Policy configuration, effective eligibility and posted allowance have separate outcomes. Review the create operation's existing-code behavior before saving a new rule.
Use Correct a leave balance for a manual correction. The guide explains signed units, the current treatment of future effective dates, expected results and uncertain-save recovery.
Follow Review or withdraw leave for direct decisions, workflow handoff and personal withdrawal. Confirm the saved leave outcome: a completed workflow or success message alone may not establish approval.
Use Change approved or ongoing leave for revocation, call-back, suspension planning/removal and automatic start, return and completion. The action's saved state, effective dates and allowance effect must be checked separately; planned suspension is not immediate suspension.
Read Understand leave updates and reporting for message preferences, history, analytics reference meaning and the difference between configured entitlement and posted allowance.
Read When a leave action has an uncertain result before repeating a submission, decision, policy change or balance correction.
Read access to leave information for personal versus administrative responsibility and unresolved access verification. Use existing leave records when reconciling a transition; a new schema or screen does not prove historical completeness.
Responsibilities¶
Staff should select an assigned policy, check the period, provide a concise reason and complete any required supporting upload. They should confirm the saved request and its actual state before treating submission as successful.
Managers and process owners should agree the review route and ensure the organization structure provides the cover the policy needs. A named manager on a profile is not proof that every leave policy routes to that person.
Authorized leave administrators maintain policy and assignment data and investigate blocked submissions or unexpected balances. A policy change and a balance correction serve different purposes. Policy configuration alone is not proof that grants or accruals have already been posted.
Executives and rollout owners should decide who owns policy accuracy, cover readiness, review delays and exceptional corrections. Adoption depends on reliable staff identity, structure, business hours, holiday dates, evidence handling and published workflows where used. This guide does not establish payroll integration, legal compliance, a savings estimate or delivery readiness.
Support should distinguish validation failure, missing configuration, unavailable access, a saved request awaiting review and an uncertain submission result. Preserve the request reference and the exact error where available; avoid collecting more personnel information than the investigation requires.
What submission does¶
The backend checks the policy assignment for the requested start, overlapping active requests, calendar configuration, any required published workflow, notice and duration, cover, balance and supporting files. Required unresolved cover blocks submission in the inspected path.
A policy with no approval creates an approved request and posts consumption. Direct and workflow approval create a pending request and reserve its units. Workflow start is queued separately; a pending request does not prove that workflow execution or a final decision has happened.
Saved request rules include the policy identity, counting settings, approval mode and interruption permissions at submission. Organization and calendar reads are not one immutable historical snapshot. Later decisions and lifecycle changes have their own rules and need separate verification.
Availability and limits¶
The personal design includes policy summaries, request details, balances and prepared-file states. Current implementation gaps affect those screens: member access to detailed policy/balance reads, date-only input interpretation, and propagation of policy/workflow/cover/file context into request responses still need reconciliation. Blank or default context must not be treated as proof that no cover, file or review is required.
The frontend's sample success state is not a saved request. Confirm access, real results, recovery and the intended journeys in the deployed environment before rollout. The initial user/business walkthrough, complete feature coverage and publication are still open.