Understand leave updates and reporting¶
Leave can produce several related records: the saved request, allowance entries, messages to the affected person, an activity record and reference information for reporting. They serve different purposes and can arrive at different times. Use the saved request and balance to confirm an outcome; an email or inbox alert alone is not a complete leave history.
This page explains background behavior found in the inspected implementation. It does not establish deployed delivery or introduce a new screen journey. The current Leave frontend still uses sample records and simulated actions. Full messaging, reporting and recovery walkthroughs remain pending.
What the affected person may receive¶
| Trigger | Update requested by the backend | What it establishes |
|---|---|---|
| A request is submitted | An email and inbox alert describing submission or the initial saved outcome | Submission can mean pending review; it is not always approval. A no-approval policy can produce an approved outcome immediately. |
| The request changes status | An email describing the change and an inbox alert with the new status | The request reached that state when the update was produced. Read its current state before acting on an older message. |
| Allowance is reserved, consumed, released, restored or manually corrected | An email and inbox alert describing the amount and policy | A balance entry was reported. A usage message can concern approved future leave, not just time already taken. |
| Suspension is planned or removed | A manager activity record is requested | Planning/removal does not itself change leave status, so it does not produce the same status-update notification. |
These leave updates address the affected staff member. They do not establish a separate alert to every manager, direct approver or cover person. Workflow task notifications have their own process. Agree the human handover and staffing communication with your organization instead of assuming the leave update notified everyone who needs to know.
The email includes relevant policy, period, status or balance information. A decision or adjustment reason can also be included. Write reasons that explain the action without adding unnecessary sensitive personal details.
Balance messages use the policy's current counting-unit label. If that unit has changed, reconcile the message with the original request and entries; changing the label does not convert previously recorded units.
Email preferences and inbox alerts¶
The leave-update email preference can suppress submission, status-change and balance emails. The inspected email service suppresses them when the stored preference is explicitly off; it does not suppress them merely because no preference record was found. A preference change still needs to reach the notification service before it can affect delivery.
Inbox alerts use a separate path. Turning off leave emails does not, by itself, turn off those alerts or change the saved leave request. Likewise, receiving an inbox alert does not prove that an email was delivered. The inspected leave messages do not provide a direct destination link, so a message should not be relied on as a verified shortcut to the matching request.
Missing messages can result from preference settings, delayed processing, missing staff/policy context or delivery problems. Check the saved request and balance first. Preserve the reference and approximate action time when asking support to investigate; do not repeat the leave action simply to generate another message.
Why messages are not a complete history¶
A request can return to the same status, for example after a suspension. The system can treat a later message for the same request, person and status as having the same identity as the earlier one. Delivery for every repeated change still needs verification. Do not count messages to determine how many suspensions or returns occurred.
The request's own state history, interruption records and the separate activity log are also different records. The activity log records submission and supported human actions such as approval, rejection, withdrawal, revocation and call-back when the person who acted can be identified. Automatic start, suspension, return and completion do not all create equivalent human-action entries. Planning/removal has its own activity. A quiet activity view does not by itself prove that no automatic transition happened.
For a disagreement, support should compare the current request, its saved history, suspension dates and allowance entries. A notification's displayed date can be the balance entry's effective date, including a future date, rather than the time the correction was saved or the message arrived. See balance corrections for the current treatment of effective dates.
Leave status and staff availability¶
A staff update marks a person as on leave when that person has an ongoing leave request. An approved future request or a suspended request does not, by itself, set this particular marker. The lookup uses the saved request status; it does not independently decide that leave has started or ended from the dates. Delayed automatic processing can therefore leave this marker behind the intended schedule.
This marker is separate from employment status, access to WorkOS, permission to perform an action and the person's position in the organization. A person can have more than one of these restrictions or conditions at the same time. Do not interpret a missing on-leave marker as proof that the person is available, can sign in or may receive a task.
Staff updates and person-detail responses can capture this marker at different times. A saved leave change does not prove that every receiving product has refreshed its staff information. Compare the current request, the time the staff information was captured and the receiving product's update before making a staffing decision.
The reporting reference below uses a different rule: it excludes expected work for both ongoing and suspended leave. A suspended request can therefore have no on-leave marker in a staff update while still excluding expected work in reporting. This difference needs an agreed interpretation by staffing and report owners; it is not evidence that either view has calculated attendance or entitlement.
How leave contributes to reporting¶
Workforce supplies HiveOrbit with reference information for approved, ongoing and suspended leave whose effective end is still later than the capture time. It includes the person, policy, status and effective end. Pending, rejected, withdrawn, revoked, called-back and completed requests are not retained as active leave in that reference capture.
The reference marks ongoing and suspended leave as excluding expected work; approved leave is not marked that way. Suspension therefore does not automatically mean that reporting now treats the person as available for expected work. Administrators and report owners need to reconcile this meaning with the organization's intended suspension policy before using it for staffing decisions.
This reference is not an allowance ledger or a payroll calculation. Its dates and status do not prove the exact amount charged, actual attendance or a statutory entitlement. Capture and delivery timing also matter: a changed request is not proof that a downstream dashboard already reflects it.
The process that sends a submission update does not itself refresh this reporting information. Later state changes and other captures can update it. In particular, a newly submitted, immediately approved request is not guaranteed to be visible in reporting at once. Full report calculations, historical reconstruction and delivery freshness need their separate verification.
An extension applied while leave remains suspended can also miss the immediate reporting-update path, because the status has not changed. Check the revised end date against the report instead of assuming the extension has already appeared there.
Configured allowance versus posted allowance¶
Policies can store annual entitlement, accrual cadence and carryover rules. The balance model also recognizes grants, accruals, carryover and expiry. The inspected codebase has no automatic posting job for those allowance categories. The daily Workforce process currently performs no business work, and hourly leave processing changes request state and suspension dates rather than posting those entries.
Saving a policy or waiting for the next month therefore does not establish that an allowance has been funded, carried over or expired. An organization must verify how its actual opening and ongoing balances are maintained before requiring available allowance for requests. A manual correction is recorded as a correction; it does not become a grant or accrued amount merely because it was used to add units.
This is an implementation limit, not an instruction to recreate annual balances by guesswork. Agree an approved process with the policy owner and support, keep evidence for any correction, and avoid repeated adjustments while earlier outcomes are uncertain. No automated allowance schedule or mass-posting action is established by this documentation.
Resolve a mismatch¶
| Observation | What to reconcile |
|---|---|
| A request is saved but no email arrives | Check the leave email preference, staff contact context and delivery processing. The absence of email does not reverse the request. |
| An alert has an older status | Read the current request and history; compare the action and message times. |
| A planned suspension has no status email | Check whether the date was merely planned or actually applied. Planning is a different event. |
| Staff information and a report disagree about availability | Check whether leave is ongoing or suspended, each view's meaning and capture time, and the person's separate employment/access conditions. Do not change the leave request simply to make two different markers match. |
| A report disagrees with Leave | Compare the saved status/end, reference capture time, delivery and report interpretation. Avoid changing allowance to repair a reporting delay. |
| A configured entitlement has not appeared | Verify actual ledger postings and the organization's approved allowance process. There is no automatic producer in the inspected source. |
| A manager expects an approval or cover alert | Check the assigned workflow/task process and agreed handover. The inspected leave messages address the affected person. |
Business owners should assign responsibility for policy configuration, allowance posting, communication and reporting reconciliation separately. These responsibilities help distinguish a delivery delay from a failed request or an absent background process.