"Who approves my leave?" is the first question every team asks when moving off spreadsheets. Collabin's answer is deliberately simple: approval rights follow team leadership, not job titles — with admins as the safety net and an opt-out for teams that don't want approvals at all. This guide walks through the whole flow, from submission to decision.
The three roles — and the one assignment that matters
Collabin has three roles:
| Employee | HR Manager | Admin | |
|---|---|---|---|
| View own data | ✓ | ✓ | ✓ |
| View team leaves | own teams | own teams | ✓ |
| Approve leaves | only where Team Leader | only where Team Leader | ✓ everywhere |
| Manage users | – | ✓ (except Admins) | ✓ |
| Manage teams | – | ✓ | ✓ |
| System settings & billing | – | – | ✓ |
The key insight: Team Leader is not a role — it's a per-team assignment. Any user, whether Employee or HR Manager, can be set as the leader of a team. Approval rights for that team's members come from this assignment, not from the role. An HR Manager who leads no teams can organize people and teams but approves nothing; a regular Employee who leads the support team approves the support team's requests.
Admins are the exception: they can approve (or reject) any request in the organization, regardless of teams.
The flow, step by step
1. An employee submits a request
The request is created in pending status. Collabin immediately emails the leaders of every team the requester belongs to (each leader once, and only those who have email notifications enabled). If someone belongs to two teams, both teams' leaders are notified — and either of them may decide.
2. A leader or admin decides
Approvers see waiting requests on the Approvals page. Approving is one click; rejecting prompts for an optional rejection reason, which is stored on the request and visible to the employee.
3. The employee is notified
The requester receives an email with the decision. At the same moment, the leave.status_changed webhook event fires, so Slack channels, no-code automations, or HR systems learn about the decision instantly.
Approved leaves then show up everywhere downstream: the in-app calendar, synced Google/Outlook/Apple calendars, reports, and the API.
When requests skip approval entirely
Two situations auto-approve a request the moment it is submitted:
- The Free plan. Approvals are an Advanced/Pro feature; on the Free plan every request is recorded as approved immediately. You still get the shared calendar and history — just no gate in front of it.
- Teams with "Bypass approval" enabled. Each team has a Bypass approval (auto-approve leaves) toggle. It's useful for teams where tracking matters but sign-off doesn't — leadership teams, trusted senior groups, or organizations that treat leave as notification rather than negotiation. Members of such a team get instant approval; other teams keep the normal flow.
Cancelling a request
A pending or approved request can be deleted by three actors: the requester themselves, an Admin, or a Team Leader of any of the requester's teams. So an employee can withdraw their own request, and a leader can clean up after plans change.
Setting it up: a 10-minute checklist
- Create teams that mirror how approval should actually flow — approval follows team structure, so structure the teams accordingly.
- Assign Team Leaders on each team. Remember: any user can be one, and a team can have several.
- Decide who gets the HR Manager role — people who manage members and teams but shouldn't necessarily approve everything.
- Flip on "Bypass approval" for any team where sign-off would be theater.
- Check email notifications with leaders — the notification email respects each user's own notification setting.
One structural tip: if a person should approve across many groups, either make them a leader of those teams or give them Admin. Avoid the common anti-pattern of one giant "Everyone" team with a single overloaded approver — several small teams with local leaders spread the load and the context.