Correct a leave balance¶

A manual adjustment adds or removes recorded allowance for one person and one leave policy. Use it for an explained correction after checking whether the request, policy or leave-change process already provides the right action. An adjustment does not approve, withdraw or change the dates of a leave request.

This guide follows Adjustments in WorkOS Final Screens. The inspected frontend shows fixed sample balances and form values. Apply adjustment navigates to a demonstration state without submitting a correction. Confirm a connected implementation and the actual result before relying on these steps for real administration.

Before making a correction¶

Use the correct workspace and an account authorized to manage staff leave. Confirm the person, policy, counting unit and current balance. The correction operation checks that the person and policy exist in the organization; it does not establish that the person currently has that policy assigned or should receive the allowance. The policy owner must confirm that business decision.

Read what the balance labels mean. Available allowance already includes net reservations, consumption, expiry and prior corrections. Pending impact repeats the reserved amount; do not deduct both. Used can include approved future leave, rather than only time already taken.

Use the policy's unit: days, half-days, hours or fixed units. The demonstration's repeated days label is not suitable for every policy. Changing a policy's unit does not convert old entries.

Check the sign and amount independently. For example, if the verified balance is 8 units, a correction of -2 should leave 6 units when no other entries change. Entering 2 would increase it to 10. The system permits a negative adjustment that makes the available balance negative; a saved result does not prove the correction is appropriate.

Apply an adjustment¶

1. Open Leave, then Adjustments.
2. In Manual balance adjustment, choose the Staff member and Leave policy. Check that Selected balance shows that same person and policy.
3. Enter Units: a positive amount adds allowance; a minus sign removes it. Zero is not a valid correction.
4. Enter Effective on as the intended recorded date. Read the date limitation below before saving.
5. Add Source reference only when the connected application can resolve a supported record. The current backend accepts a record identifier, not arbitrary text such as the sample LEAVE-CORR-1882. If no supported reference is available, leave this optional field empty and put the useful context in the reason.
6. Write Reason for the adjustment. State what was wrong, why this signed amount corrects it and the relevant record context. Keep the reason within 100 words and 500 characters. Do not add unnecessary personal information; the notification path can include this reason.
7. Recheck the person, policy, unit, sign, amount and reason, then choose Apply adjustment.
8. In a connected implementation, retain the returned correction reference and refresh that person's balance for that policy. Compare the change with the expected amount, allowing for other activity that happened meanwhile.

Discard leaves the unsaved form in the intended journey. It is not a reversal of a correction already saved. The backend posts the correction directly; the inspected path does not provide a separate adjustment approval or review stage.

What the effective date means¶

A future effective date does not delay the correction's effect on the current balance summary. The read totals stored entries without filtering by their effective dates. Once a correction is saved, it contributes to that summary even when its recorded effective date is later.

The form's wording about when a change takes effect therefore needs reconciliation. Until scheduled application is supported and verified, do not post a future-dated correction expecting the current available amount to remain unchanged. Date conversion between the person's local calendar and the stored time also needs to be handled by the connected application.

What changes after saving¶

The system adds a signed correction to the person's balance history for that policy, creating that history if none exists. It does not replace the entire balance, edit an older entry, remove a reservation or change a request's state.

A successful adjustment changes available allowance without increasing the Granted or Accrued categories. The inspected balance summary does not show a separate manual-adjustment total, so its visible headline figures alone may not explain the whole calculation. Support may need to reconcile the underlying entries.

The backend requests email and inbox notifications for the person and records activity for the adjustment. Actual arrival depends on the notification services and delivery environment. A missing message alone does not show that saving failed; an email is not a substitute for checking the correct balance and correction reference.

Policy settings for annual entitlement, accrual and carryover are separate from posted allowance. These settings and balance categories exist, but the inspected source has no automatic posting job for grants, accrual, carryover or expiry. See updates and reporting. Selecting a cadence does not fund a balance; a displayed accrued amount does not establish an automatic producer.

Recover from an unexpected result¶

A complete correction-history view has not been verified. Reviewing all corrections and investigating a repeated submission may require authorized support. Rollout testing must cover positive and negative corrections, future dates, wrong targets, denied access, uncertain saves and duplicate prevention before this journey is accepted.