When a leave action has an uncertain result¶
Use this guidance when submitting leave, maintaining a policy or assignment, recording a decision, changing approved leave or correcting a balance. It explains how to distinguish a rejected action from a result you have not yet confirmed.
The current frontend is a demonstration of the intended journey. Sample success screens do not establish a saved change. The connected recovery experience and its availability still need verification before rollout. This page introduces no additional screen or recovery button.
Start with the outcome you can verify¶
| Situation | Meaning and next step |
|---|---|
| A specific validation message rejects the details | Resolve the identified rule or ask the policy owner for help. Confirm the details again before sending a corrected action. |
| The response disappears, times out or the connection fails | The action may have reached the service. Check the saved request, policy or balance through the access available to you before starting another action. |
| A message says the request is still being processed | The service has recorded the attempt but cannot yet return a completed result. Keep the original details and reference; persistent uncertainty needs support. |
| A success message appears | Check the actual saved state and relevant dates or amount. Submission can still be awaiting approval; messages and workflow work can arrive later. |
| The displayed result conflicts with what you intended | Preserve both the intended details and the observed result. Ask an authorized administrator to reconcile them before changing anything else. |
An absent email, inbox alert or reporting update does not prove a failed save. Understand leave updates and reporting explains those separate outcomes. Access limitations can also prevent you from checking a result yourself; your administrator may need to perform that check.
Repeating the original action versus making a change¶
The service can recognize a repeated attempt and return its previously recorded result. The application must preserve the identity of the original attempt for that to work. Connected frontend handling of this behavior remains unfinished.
A repeat is appropriate only for the same intended action with the same details. Changing the person, policy, dates, amount or reason creates a different intention. Reusing the identity of an earlier completed action can return its old result without applying those changes. Starting a new attempt while the old outcome is unknown can instead create duplicate work.
Users should not need to create or manage technical retry identifiers. Preserve the original action and let the connected application or support procedure handle a repeat. Do not assume reopening a form preserves the attempt, and do not use repeated submissions to test whether the service is available.
Take particular care with balance corrections¶
An adjustment adds a signed posting to the balance. Sending another adjustment can add another posting; the same source reference does not by itself prevent this. A correction of a confirmed mistake needs an authorized, separately explained compensating adjustment. It does not erase the original entry.
The current interface does not establish a complete adjustment-history investigation workflow. If the outcome is uncertain, ask support to reconcile the posting and resulting balance before applying either another correction or an opposite amount. See Correct a leave balance for units, dates, reasons and current limits.
Supporting files and later processing¶
Leave submission coordinates saved leave with prepared supporting files. Cleanup is attempted if submission fails, but a cleanup failure requires support. Keep the error and file preparation context; do not treat an unsuccessful response as proof that all reservations or background work have disappeared.
Successful submission also does not mean a workflow has finished, a document has completed every later processing step, or notifications have arrived. Follow the saved leave state and the relevant review process. Review or withdraw leave explains approval and withdrawal outcomes.
Information to give support¶
Provide the workspace, action, approximate time, any request or operation reference shown, exact message, and the expected versus observed state, dates or amount. Share only the personnel details needed for the investigation through your approved support channel. Do not send passwords, access tokens or file-finalization credentials.
Administrators should reconcile uncertain actions before repeating them, record the reason for any correction and verify the result afterward. This guidance does not establish an automatic recovery schedule, a universal undo operation or a guarantee that every background system has completed.