Review or withdraw leave¶
Leave review decides whether a person's requested time away can go ahead. A direct review is completed in Leave → Approvals. A workflow review continues in Workflows. Withdrawal is the requester's action when they no longer need the leave and its saved rules permit cancellation.
These steps describe the designed WorkOS journey, including approved, rejected and withdrawn requests. The current frontend preview displays sample records and changes the displayed status through links. It does not save these decisions or withdrawals. Use this guide as the intended journey until a connected implementation and its results have been verified.
Choose the correct action¶
| Your task | Where to continue | Conditions |
|---|---|---|
| Decide a direct request | Approvals → Review | You need leave-management permission; you cannot approve or reject your own request. |
| Review a workflow request | Approvals → Open workflow | Complete the assigned workflow task under that workflow's access rules. A direct leave decision cannot replace it. |
| Stop your own request | My leave → request detail → Withdraw leave | The saved request must allow withdrawal and still be submitted, pending approval or approved. |
| Change another person's approved or active leave | Leave changes | Revocation, call-back and suspension are separate actions with their own rules. Rejection is not an undo for approval. |
| Correct recorded allowance | Adjustments | A balance correction does not change the leave decision. See balance corrections. |
The designed Approvals page is a queue of pending decisions. The current management list also includes approved, ongoing, suspended and attention-required requests. The application must distinguish these statuses before offering an action. Appearing in this list does not mean a request is assigned to you for workflow review, and a manager title alone does not grant that responsibility.
Approve a direct request¶
- Open Leave, then Approvals. Check the person, leave dates and review route. Choose Review for a direct request.
- Confirm that the detail still belongs to the selected person and request. Read the current status, request note, policy, cover and supporting-file facts. Do not treat an empty panel as confirmation that no cover or file is required; the current implementation does not populate all these panels.
- Check the policy and available allowance. If context or authority is unclear, resolve it before deciding. The system prevents self-approval.
- Under Review this request now, enter Approved start date and Approved end date. These can differ from the requested period. Check the complete period and the policy's counting unit; a displayed number of calendar days is not necessarily the amount charged.
- Enter a clear Decision note, within 100 words. Explain any date change so the requester can understand the saved decision.
- Choose Approve request. In a connected implementation, reopen or refresh the same request and confirm that it is actually Approved, with the intended dates and chargeable amount.
The system recalculates the amount for the approved period and checks overlapping leave and available allowance. Current business hours and holiday dates can affect that calculation. A larger period can fail if other requests have reserved the remaining allowance. Required notice, maximum duration and cover are checked during submission; the current approval process does not repeat all those checks when a reviewer changes dates. Review the applicable policy yourself rather than treating save as a complete policy assessment.
Check the saved state even after a success message. If the calendar cannot support the calculation, the current approval process can record a configuration problem and release reserved allowance while still showing a success message. This does not mean the leave was approved. Ask the leave administrator to investigate the request's actual status.
Reject a direct request¶
Open the same direct-review detail, read its context and enter a Decision note explaining why the leave should not go ahead. Choose Reject request, then confirm the saved Rejected state and the recorded reason.
Rejection applies to a submitted or pending request and releases its reserved allowance when the operation succeeds. It does not approve different dates, return a draft for editing or revoke leave that is already approved. The rejected request remains available for reference. If the person still needs time away, they can prepare a new request after resolving the reason; the current implementation has no reopen or resubmit action for that rejected request.
Follow a workflow review¶
From the pending row choose Open workflow, or use the corresponding Workflows task. Check that the workflow refers to the same leave request. Follow the workflow's available actions; this leave guide does not establish every workflow task or permission.
After the workflow finishes, refresh the leave request. Workflow completion and leave approval are separate saved outcomes: the system checks the original requested period again for conflicts, the amount to charge and available allowance. A workflow decision does not supply a revised leave period. A new conflict or insufficient allowance can leave the request needing administrator attention; missing calendar configuration can leave it needing configuration repair.
Do not attempt to bypass a workflow problem with Approve request in Leave. Direct approve and reject operations refuse workflow-routed requests. A repaired workflow definition or corrected balance alone does not prove that an already blocked request will restart. Ask support to reconcile the request and workflow together before retrying or creating a replacement.
Withdraw your own leave¶
- Open Leave → My leave and select your request.
- Check its saved status, dates and policy. The pending and approved designs both provide Withdraw leave when allowed. Approved leave uses the explanation This approved leave can still be withdrawn.
- Enter a reason in Why are you withdrawing this request? or Why are you withdrawing this approved leave? Explain why the period is no longer needed.
- Choose Withdraw leave. In a connected implementation, confirm that the same request is Withdrawn and that its reason and balance effects are correct.
- If it used a workflow, allow the review cancellation to be processed and ask support to check any task that remains active. A saved withdrawal is not proof that every associated task has already closed.
Withdrawal is restricted to your own request and uses the withdrawal permission saved when it was submitted. A later policy edit does not automatically change that saved permission. Pending withdrawal releases reserved allowance. Approved withdrawal calculates a reversal of recorded usage; it is not necessarily a full refund or an exact calculation of unused working time.
Timing needs care. The system checks the request's saved status and can accept withdrawal while it is still Approved, even after its start time has passed. After commencement, day, half-day and hour policies use rounded remaining calendar duration without consulting working days, holidays or business hours. Fixed-unit policies use a proportion of remaining duration. At or after the end, the calculation returns zero. A calculated refund above the request's remaining recorded usage can cause refusal. Ask the leave administrator to reconcile an unexpected amount. Once the status is Ongoing or Suspended, this withdrawal action is not available. Follow the appropriate leave-change process instead of relying on the screen's age or a blanket “before commencement” message.
The withdrawn request stays in your history with no further personal action on it. Start a fresh request if you need another period, after confirming the old withdrawal and its balance effect.
Understand the result and get help¶
| Situation | What it means and what to do |
|---|---|
| Approval was saved | Reserved allowance is released and the approved amount becomes used allowance, including future leave. Check dates and units; do not subtract both the old reservation and the new usage. |
| A workflow finished but leave is not approved | Read the leave state and reason. Ask the administrator to investigate overlap, allowance or configuration; workflow completion alone is insufficient. |
| A workflow was cancelled | Unexpected workflow cancellation can leave the leave request needing attention. It does not necessarily withdraw the leave or reverse approved usage. |
| Your request cannot be withdrawn | Confirm ownership, saved policy permission and current state. Another person's leave requires an authorized administrator's separate action. |
| The operation timed out or gave an uncertain result | Refresh the exact request and balance before trying again. Preserve its reference, the action and time. Avoid a new decision or manual adjustment until the outcome is reconciled. |
| A request needs configuration or intervention | Ask the policy/workflow owner and support to investigate. The current implementation provides no dedicated retry, reset or recovery action for those statuses. |
| The displayed request differs from the selected row | Stop. The current frontend uses fixed sample details and does not establish real selection continuity. |
For managers and business owners, the useful checkpoint is a correctly saved leave outcome, with an accountable reviewer and reconciled allowance. A completed review task, an email, a demo success screen or an adjustment alone is insufficient evidence. Keep review delays and exception handling owned by the leave and workflow administrators. Environment delivery, full feature reconciliation and user walkthrough acceptance remain pending.