Change approved or ongoing leave¶

Leave changes let an authorized leave administrator stop another person's approved leave, call someone back from ongoing leave, or plan and remove suspension dates. Each action has different timing, policy and balance effects. A balance adjustment does not perform any of these actions.

These steps follow the intended WorkOS Final Screens journey. The inspected frontend shows sample people, dates and reasons; its action buttons change the preview through links without saving. Connected actions, actual results and environment availability remain unverified.

Choose an action¶

Open Leave → Leave changes, find the person and period, then choose Manage. Check that the detail belongs to that same person and request before continuing. Read its current status, effective dates and saved policy rules.

You need leave-management permission and cannot perform these manager actions on your own leave. The selected person must own the request in the current organization. A later policy edit does not automatically change the action permissions captured in an existing request. For your own cancellation, follow Withdraw your own leave.

The designed distinction is revocation before leave starts and call-back after it starts. The current revocation check uses the saved Approved status, without independently enforcing the start time. Automatic processing can lag behind the clock. Check the actual dates as well as the status, and ask the leave administrator to resolve a mismatch before relying on an available button.

Revoke approved leave¶

1. In Leave changes, select Manage for the approved request.
2. Under Manage this approved leave, review the person, period, policy and review history. Confirm that revocation is the intended outcome.
3. Enter Reason for revocation. Explain why the approved time away must stop.
4. Choose Revoke leave. In a connected implementation, refresh the same request and confirm the revoked state, recorded reason and balance effect.
5. If approval used a workflow, ask support to reconcile any still-active review task. Revocation can request workflow cancellation, but saving leave and closing the workflow are separate outcomes.

Before the effective start, revocation reverses the request's recorded charge. If the request is still approved after that time, the calculation uses the remaining interval. For day, half-day and hour policies, that calculation uses rounded calendar duration and does not consult working days, holidays or business hours. Fixed-unit policies use a proportion of the remaining duration. At or after the effective end, it returns zero. If the calculated refund exceeds the request's recorded usage still available to reverse, the operation can be refused. Do not assume the resulting adjustment is an exact refund for unused working time; verify it with the leave administrator.

Call someone back from ongoing leave¶

1. Open the person's ongoing leave through Leave changes → Manage.
2. Under Manage this ongoing leave, find Call back this leave.
3. Enter Reason for call back, then choose Call back leave.
4. In a connected implementation, confirm that the same request is called back and review its recorded allowance change. The effective time is when the operation is processed; this action has no separate future call-back date input.

The request must be ongoing. The current operation refuses a suspended request, even though suspension also represents leave that has started. Calling someone back records the interruption and closed status; it does not rewrite the saved effective end date. Read the status and history alongside the dates.

Call-back normally recalculates the charge for the remaining interval using the request's saved counting rules and the organization's current calendar. Fixed-unit policies currently return their whole configured fixed amount in this recalculation, rather than the proportional amount used by revocation and withdrawal. If calendar configuration cannot resolve, a simplified remaining-duration calculation can be used; an invalid interval or other calculation error can instead prevent completion. Check the actual balance result rather than assuming every policy receives the same kind of refund.

If processing is delayed until the request's end has passed, the remaining interval may be invalid even while its status still says ongoing. Preserve the request reference and ask support to check its lifecycle and saved outcome; do not substitute a manual balance correction for the call-back itself.

Plan suspension dates¶

1. Open the ongoing request and find Plan or remove a suspension.
2. Enter the intended Suspension dates. Use distinct dates within the effective leave period. Avoid past dates: the current service can accept some past dates but its automatic processor only applies dates matching the current UTC day.
3. Set Days to extend from zero up to the number of selected dates. Enter Reason for the suspension.
4. Choose Plan suspension. In a connected implementation, confirm the saved dates and which of them extend the leave. Saving a plan does not immediately change the status or end date.
5. When the dates arrive, check the applied suspension and the revised end date. Escalate a missed date or unexpected result before arranging further changes.

Dates are processed in chronological order when assigning extension flags. If you select three dates and request two extension days, the first two selected dates each carry one extension; the third does not. Each flagged date adds one calendar day to the effective end when that suspension is applied. The addition happens during suspension processing, not when leave later resumes, and does not skip weekends or holidays.

An extension changes the end date without recalculating the request's charge or posting extra allowance. The inspected path does not recheck new overlaps, cover or other policy constraints for the extended period. Administrators must review those consequences. Extending leave should not be presented as granting extra entitlement.

The suspension date input and its server conversion still need verification across time zones and partial-day boundaries. Confirm the saved date explicitly. No connected confirmation or error companion has been verified for this action.

Remove a planned suspension¶

Open the same request, select the pending Suspension dates to remove and choose Remove suspension. The request may be ongoing or suspended, but each selected date must still be unapplied. This action has no reason field in its write contract; the adjacent planning reason is not evidence that a removal reason is saved.

Confirm that only those pending dates were removed. Removing a date that carried an extension also removes that future extension; its flag is not redistributed to another date. Applied suspension dates cannot be undone through this operation, and an end-date extension already applied is not reversed by it.

Do not remove and recreate dates as an uncertain-save recovery technique. The implementation prevents duplicate pending dates, but does not establish a general prohibition on scheduling an already applied date again. Ask support to reconcile the existing records first.

Automatic start, suspension, return and completion¶

The background process is scheduled hourly in UTC. This describes the configured cadence, not an exact transition time or a delivery guarantee. It considers approved, ongoing and suspended requests for the tenants selected by the job.

There is no exposed manual Resume or Complete action in the inspected leave interface. Do not invent a button from the existence of a policy setting or internal operation. The completed personal design presents history with no further action on that request.

Automatic processing checks today's suspension date; it does not apply all missed earlier dates. If processing was unavailable on a planned date, support must investigate the missed suspension and any expected extension. For consecutive suspension dates, support also needs to confirm that each date was saved as applied. The current process can skip a save when a date changes neither the leave status nor its end. A processing log alone is insufficient proof that every date was saved as applied.

Recover from an unclear result¶

Managers should coordinate the reason and staffing consequences with the affected person. Business owners should assign responsibility for delayed transitions, missed dates and allowance reconciliation. These pages describe platform behavior; they do not establish a payroll change, a personnel notification, a contractual entitlement or a completed rollout.