Cancellation approved
Approved cancellation: the original booking changes to Canceled and its booked hours become zero. The original request and the cancellation stay available for review.
Give every request a reviewer and a recorded next step. Return incomplete requests, approve only after checking hours and cover, and handle cancellations without losing the original booking.
Free for up to five users. No credit card required.
Adapt fields, workflows, and dashboards without code. Explore 1,000+ app templates and use cases
Sign in to preview. Install with sample data to try your own requests and decisions.
The employee sends one request. Its assigned manager reviews the hours and handover, returns missing information or records a decision. Only an approved request reduces the employee’s available leave.
The selected leave account supplies the responsible reviewer. Dates, scheduled hours, and handover information travel with the request.
No booked hoursThe reviewer sees the request context and checks the current posted allowance. Record whether coverage is agreed or unnecessary.
An accountable taskReturn an incomplete request with specific comments. The requester changes the permitted inputs and resubmits for another review.
History retainedA completed approval posts booked hours. A rejection ends the request without deducting them. Missing coverage or insufficient allowance blocks normal approval.
A clear balance effect| Responsibility | Employee or requester | Assigned reviewer | Leave administrator |
|---|---|---|---|
| Request details | Enter dates, hours, and handover; correct a returned request | Read the request and ask for clarification | Maintain fields and policy guidance |
| Approver | Supplied by the selected account | Receive the assigned task | Maintain account reviewers; reassign open tasks explicitly |
| Approval and coverage | Cannot edit the manager’s decision | Record the outcome and coverage assessment | Maintain the review rules |
| Allowance | Cannot post their own credits | Check the account before deciding | Review allocations and signed adjustments |
| Booked effect | Cannot edit it directly | Approval triggers the recorded effect | Reconcile booking and adjustment records |
These are the intended responsibilities of the installed app. Map actual members and test employee, manager, and administrator access separately before rollout.
See the employee’s request fields →Changing an approved request in place makes it difficult to tell what was originally agreed. A separate cancellation references the original request and asks its reviewer to reverse that booking.
Approved cancellation: the original booking changes to Canceled and its booked hours become zero. The original request and the cancellation stay available for review.
Rejected cancellation: the original booking remains. In the example, Maya’s four-hour request is still deducted after the manager rejects the cancellation.
For different dates or hours, first agree how to cancel the old booking and submit the replacement. Do not keep both as approved leave by accident.
| Situation | Useful next step | Avoid |
|---|---|---|
| Dates and hours do not agree | Return the request for an explanation or correction | Guessing the employee’s working pattern |
| The available allowance is too low | Reduce or return the request; review a legitimate adjustment separately | Treating a typed exception note as extra allowance |
| No one has accepted the handover | Resolve the coverage gap before normal approval | Equating a proposed cover name with an agreement |
| Two reviewers may approve the same limited balance | Assign one reviewer to decide those requests in order and refresh the balance between decisions | Approving both at once because each showed enough hours when opened |
| The approver is unavailable | Reassign the open task through authorized administration | Letting the employee choose a different approver |
| The employee wants to withdraw approved leave | Use the linked cancellation process | Deleting the original approval history |
The team starts with dates, hours, and one handover note. Later, customer-support leave also needs a named cover contact and a handover deadline.
An administrator can add those fields in Jodoo, require them for the relevant requests, and show them to the reviewer. Existing accounts, bookings, and request history do not need a separate application.
Changing the account reviewer affects new requests; already-open tasks need explicit reassignment. When changing request fields, check that employees can complete them, managers can see them, and an approved request still deducts the correct hours.
Try these paths with your policy and separate employee and manager accounts before inviting the team. The sample records are fictional. Automatic accrual, holiday calculations, payroll and statutory leave decisions are not included; decide requests against one limited account in sequence.
Plan the surrounding leave management process →Return asks the requester to correct the same record and submit it again. Reject closes the request without approval. Neither outcome books leave hours in this example.
When the review workflow finishes with approval, the request’s booked-hours effect is posted. A pending request or an employee-entered approval word does not by itself create that booking.
The requester’s entry step does not expose the manager decision fields. The responsible reviewer is maintained on the leave account. Configure actual member relationships and access groups so a person is not inadvertently assigned as their own reviewer.
No. It is a separate record linked to the original request. If approved, it reverses the original booked effect; if rejected, the original booking stays. Both decisions remain inspectable.
Use one reviewer to decide those requests in order. Although approval checks the current balance, this example does not guarantee that two decisions made at exactly the same time reserve hours separately. If simultaneous approvals are essential, add and test that protection before rollout.
The organization installs and configures the template once, then gives members the appropriate access to its shared app. The template preview contains examples, not your employees’ live request history.