Time Off
Leave requests move from the team portal to a decision to a recorded balance without anyone chasing anyone. The system carries the request, the context, and the outcome.
Request to decision in five steps
The whole loop is request, decide, record. Nobody chases anybody, and the balance math never gets done by hand.
The employee picks dates and a leave type in the team portal. Their current balance is right there on the form.
A policy that auto-approves closes it on the spot. Otherwise the approver is emailed and the request waits in the admin or client-portal queue.
The admin, or the client manager on the placement, sees the request in context: team calendar, remaining balance, overlapping leave.
On approval the leave shows on the team and client calendars. Balances are synced from the HR system, not deducted by hand.
The employee sees the decision and their updated balance in the portal. No follow-up message needed.
How each step works
The employee opens the team portal, picks dates and a leave type, and submits. Their remaining balance is shown on the form, so nobody requests days they do not have.
The leave policy sets the path. A policy marked auto-approve approves the request on the spot, stamped as approved by policy rather than a person. Otherwise the approver (the client manager on the placement, else the Edge8 manager) gets an email with the reason, the client's portal admins get a copy without it, and the ops Lark chat gets one line. The request waits in the queue with the balance, the history, and any team overlap on those dates.
Approve or reject, one click either way, in the admin or in the client portal. Because the context travels with the request, the decision takes seconds instead of a back-and-forth thread. An admin can also deny leave that a policy approved automatically.
On approval the leave appears on the shared calendar, and the daily check-in agent treats those days as off. Balances are not computed here: they are synced from the HR system the company already runs leave in, so the portal shows one number and nobody reconciles it by hand.
The decision shows in the team portal immediately, next to the synced balance. The whole loop closes without a single “did you see my request?” message.
The seven elements
Every workflow we document has the same anatomy: seven elements, each assigned to a human, a machine, or both. This is the Centaur Map from our workflow design method.
An employee submits a leave request in the team portal.
The current balance, leave history, and team calendar, shown with the request.
Approve or reject. The leave policy decides who decides: some policies auto-approve, the rest wait for a person.
Requests route to the approver, the Edge8 manager or the client manager on the placement, by email; the ops Lark chat sees every request.
A decided leave record on the shared calendar, and a balance synced from the HR system rather than hand-tracked.
The decision shows in the team portal; the client portal shows who is out when.
Balances and usage across the team, read from one synced source instead of a spreadsheet.
The standing rules
- All leave goes through the portal, never through chat
- Balances are synced from the HR system, never hand-tracked
- Every request is decided with the team calendar in view
- The decision and the record are the same thing
Why it works
- One queue means requests cannot get lost in a thread
- Context attached to the request makes decisions fast
- One synced balance kills the year-end balance argument
- Everyone sees the same calendar, so coverage gaps surface early