Leave Requests Where the Balance Is Derived, Not Typed
Vacation, sick, personal, unpaid and parental leave — requested in a day range, counted against working days by the server, and approved in one transaction that writes the hours.
Most leave tools ask the requester how many days they are taking. That is the bug: the number is a guess about weekends, holidays and half-days, and it is the number the balance is then trusted against. Stintt never accepts a day count from the client. You pick a date range; the server counts the working days inside it against your workspace's policy and holiday calendar, and the balance is derived from the ledger every time it is read rather than stored and drifted.
- 1Request a rangePick the kind, the dates, and whether either end is a half day. You do not enter a day count — the server works it out.
- 2It reaches an approverThe request lands in the approvals queue with the computed days and the requester's remaining balance beside it.
- 3Approved leave becomes hoursOne decision writes the leave entries and marks them reviewed together. A half-approved leave that wrote three days of five cannot happen.
Leave requests, in the concrete.
- Five leave kinds plus a custom one: vacation, sick, personal, unpaid, parental
- Half days — first or second half — not just whole ones
- Day counts are computed server-side from working days, never taken from the request
- Workspace holiday calendar and per-policy working days feed that count
- Two overlapping requests are impossible by construction, not by a check that can lose a race
- Balances are derived from the ledger on every read, so they cannot drift out of date
- An unlimited policy shows as unlimited — never as zero days remaining
- Per-person adjustments for the cases a policy cannot express
- Approve, decline or cancel — and approval writes the leave hours in the same transaction
- Pending requests reach the approver in the approvals queue, not only the requester's calendar
3 steps, start to finish
No timer to start, no form to remember.
Request a range
Pick the kind, the dates, and whether either end is a half day. You do not enter a day count — the server works it out.
It reaches an approver
The request lands in the approvals queue with the computed days and the requester's remaining balance beside it.
Approved leave becomes hours
One decision writes the leave entries and marks them reviewed together. A half-approved leave that wrote three days of five cannot happen.
The things people ask before signing up
The balance is shown to the approver next to the request, derived from the ledger at the moment they look. The decision stays a human one.
They are excluded by the server, from your workspace's holiday calendar and the working days set on the policy. That is why the day count is not something the request is allowed to state.
It reads as unlimited. Coercing an unlimited allowance to zero would tell someone they have no days left when they have no cap at all, so remaining stays genuinely empty.
Yes. Approval writes real hours through the same path a reviewed timesheet takes, so leave appears in the period alongside worked time instead of as a gap.
No. Overlap is blocked by a database exclusion constraint over pending and approved requests, so two simultaneous submissions cannot both slip through.
