Request leave and understand your balance¶

Use Leave to prepare time away, follow a saved request and understand the allowance recorded for each policy.

For authorized configuration work, use Create, update and assign leave policies. Setting a policy, assigning it and posting allowance are separate operations.

For an explained allowance correction, authorized administrators can use Correct a leave balance. A correction does not change a request's dates or approval state.

These are the intended steps from WorkOS Final Screens. The inspected frontend currently demonstrates the screens with sample data. Its Send request and Open upload flow links change the preview state; they do not save a request or prepare a real attachment. Use a connected environment only after your organization confirms that it is available.

For role and privacy boundaries, read access to leave information. For missing or changed historical records, use existing leave records; a replacement request is not a history-restoration operation.

Before you start¶

Use the correct workspace and staff account. You need a policy assigned to you, either personally or through your effective position. The policy must apply when the requested leave begins. A policy visible today can stop applying before that date, while a future assignment may not yet appear among today's choices.

Check the policy's counting rule, notice period, maximum duration, approval route, supporting-file requirement and cover requirement. Some policies require sufficient recorded balance; others do not require the initial balance check. Ask your leave administrator when a rule or balance is unavailable.

The intended personal flow links to Policies and My Request Balances. The inspected detailed-policy and balance reads require leave-management permission. Ordinary member access to the complete designed experience remains an implementation gap; do not assume that a visible tab grants access.

Review your requests and balances¶

1. Open Leave in the workspace navigation.
2. Choose My leave, then My Request.
3. Find the relevant period and choose Open detail. Confirm that the person, policy name, period and saved state match the request you meant to inspect.
4. Review the current note and activity. A later state reason can replace the original submission note in the current summary.
5. Choose My Request Balances to review each assigned policy separately where the connected experience permits it.

The intended detail screen groups saved policy, review, cover and file facts. Some of that context is currently lost in the backend response mapping. A blank review reference or default cover/file value therefore needs investigation; it is not reliable evidence that no review, cover or attachment exists. Staff department and title shown alongside activity use current organization placement, so they are not necessarily the person's department and title at the historical event.

Do not combine days, half-days, hours and fixed-unit allowances into one number of days. The current request-list read returns a complete list; the sample page controls do not establish server pagination.

Understand the balance labels¶

Read each balance for the named policy and its counting unit.

This read totals the stored ledger entries without a current-cycle or effective-date filter. It must not be described as only time already taken this year. A missing ledger can produce a zero summary for an existing person and policy; it does not prove that the organization intended a zero allowance.

For example, 18 granted units plus 4 accrued units, minus 3 reserved and 11 consumed units, leave 8 available units when there are no other entries. Manual adjustments, reversals and expiry can change that result. Use the actual ledger-backed result rather than the demonstration totals.

Prepare and send a request¶

1. From Leave, choose New request.
2. Choose Leave policy. Review the selected policy's name, code, family, counting rule and approval route.
3. Enter Start date and End date. Confirm the exact period with the leave administrator if the interface does not make time and timezone handling clear.
4. Enter Why you need the time away. The current submission validation requires a note of 1–100 words. Include only information needed for the decision.
5. Under Supporting files, choose Open upload flow when evidence is needed. Complete the upload and return to the request with the prepared file. Check its identity and readiness before sending.
6. Recheck the policy, dates, note and prepared files, then choose Send request.
7. Confirm the saved request reference and state. Return to My leave and open the saved request to verify the result.

Cancel returns to My leave in the intended flow. The inspected submission API does not provide a separate personal draft-save operation, and the demonstration does not establish autosave.

Dates and chargeable time¶

The backend counts an interval with a start and an end time. The end is the boundary of that interval. A date-only label does not establish that the entire displayed end date is included. Same-day leave needs a valid start and later end time; two identical midnight values are invalid. The current frontend demonstration has not verified this conversion.

The submission validator compares the start with the current instant, not just today's calendar date. A value set to midnight earlier today can be rejected. Minimum notice is an additional policy check; a policy can also cap the calculated duration.

Counting depends on the policy:

• Days and half-days use the fraction of the relevant daily interval. A complete counted day contributes one day or two half-day units.
• Hours use overlap with configured working hours and exclude a configured break.
• Fixed units use the policy's fixed amount after validating the period, without counting individual working days.
• For day, half-day and hour policies, weekend, holiday and working-day exclusions apply according to the policy. Missing required business-hour configuration can block the request.

The backend normalizes times to UTC for these calculations. A calendar-looking selection is not proof of correct local-time conversion. Review the saved period and calculated outcome rather than assuming a universal inclusive-day count.

Required cover¶

Cover is resolved separately from approval. The current submission process can identify another person from effective position, acting, fallback and manager relationships according to the policy's coverage mode. It excludes the requester as their own cover.

Required handover confirmation currently blocks this submission path; there is no inspected request-form action that completes that confirmation. Missing positions, unresolved authority or a circular chain can also block submission. An organization owner must resolve the underlying requirement. Adding a name to the note does not establish valid cover.

The requester position is resolved for the requested start, while the cover lookup uses the submission time. The result does not prove that the same cover remains available for the whole future leave period. The inspected cover lookup also does not establish that the cover person is not on leave.

Supporting files¶

A prepared file is a prerequisite to attaching evidence; uploading it is not the same as saving the leave request. A policy requiring evidence needs at least one accepted supporting artifact. The submission rejects duplicate references to the same prepared artifact.

If preparation or submission reports an attachment problem, keep the error and use support to resolve the existing operation. Do not treat the sample Ready badge as proof that a real file exists. The current detail response's missing file context must also be corrected before file counts are used as authoritative confirmation.

What happens after sending¶

The system rejects overlapping requests in submitted, pending, approved, ongoing or suspended states. Requests that only meet at the same end/start boundary do not overlap under this check.

If a request is pending, follow its saved state and the organization's review process. Review or withdraw leave explains direct decisions, workflow handoff, personal withdrawal and their balance effects. Change approved or ongoing leave explains administrator revocation, call-back, suspension and automatic transitions. Do not infer an available action or saved result from a sample screen or a policy flag alone.

Understand leave updates and reporting explains email and inbox messages, saved history, reporting delays and the absence of an automatic allowance-posting job in the inspected source.

When a leave action has an uncertain result explains checks before repeating work, changed-action handling and the information support needs.

When something prevents submission¶

A validation error and a network timeout are different outcomes. The first may identify a rule that must change; the second does not prove whether the request was saved. Avoid repeated new submissions while the result is uncertain.