# A 12 week coverage board for approving time off in Deel

> See twelve weeks of team leave at a glance, spot the days too many people are out, and approve or reject Deel requests without leaving the board.

- Workflow type: app
- Services: Deel, Google Calendar
- Categories: HR & People, Operations
- Published: 2026-08-21

## What it does

- Shows a rolling twelve week calendar of approved and pending leave, with rows grouped by team and department and color coded by leave type.
- Puts every pending request in a queue sorted by soonest start date, showing how many teammates are already off on those same days and flagging anything that would leave a team short.
- Lets you approve or reject straight from the row, and adds every approval to a shared company calendar so the wider team can see the absence.
- Gives you a Check coverage button that sends a background assistant to read the requester's team, their manager and every overlapping request, then write a short recommendation back into the board.

## What you'll need

- A Deel login that can see people, teams and departments and approve time off for your team. Full admin access is not required.
- A Google account with permission to add events to the shared calendar where approved absences should appear.
- Teams and departments filled in on your Deel people records, since the board groups rows by them.
- Leave types set up in Deel, which the board uses for its color coding and filters.

## Prompt

Build me a team time off coverage board for Deel that I open whenever a leave request needs a decision. The audience is people managers and People Ops rather than Deel admins, so every screen should make sense without knowing how our Deel account is configured. The point of the app is that I see who else is already off at the moment I decide, instead of finding out about a coverage gap after the approval has gone through.

The main view is a rolling twelve week calendar grid starting from today. Load approved and pending time off with Deel List Time-Off Requests for Organization and lay each request across the days it covers. Rows are people, grouped first by team and then by department, resolved from Deel List Teams, Deel List Departments and Deel List People. Color code each block by leave type using the types returned by Deel List Time-Off Types rather than a hardcoded palette, and render pending requests in a lighter or hatched treatment so approved and pending are instantly distinguishable. Include a legend, and let me scroll or page horizontally through the twelve weeks.

Default the board to only the teams the signed in manager owns. Work that out from Deel List Managers by matching the connected Deel user, and give me a toggle to switch to the whole organization when I need the wider picture. Remember the last scope I used so the board opens where I left it. Add filters for department and leave type alongside the scope toggle.

Alongside the calendar sits a pending queue, sorted by soonest start date first. Each row shows the requester, the dates and total days, the leave type, and how many teammates on the same team are already off on those same dates, naming them. Raise a conflict flag on the row when approving the request would put more than a configurable share of that team out on any single day, defaulting to 20 percent. Make the threshold a setting I can change inside the app rather than a constant in the code, and have the flag name the specific days that clash.

Approve and Reject buttons sit on each queue row and call Deel Review Time-Off Requests inline. That operation reviews a batch, so also let me select several rows and act on them in one go. When a decision goes through, move the row out of the pending list and update the calendar grid straight away. If Deel refuses the review, show the error on the row itself rather than as a generic failure banner, and leave the request in the queue so I can retry.

Every approved request is also pushed to a shared team calendar with Google Calendar Create Event, so the wider company sees the absence without logging into Deel. Create it as an all day event using date values rather than timestamps, spanning the full leave dates, titled with the person's name and the leave type. Let me choose which calendar it writes to in the settings. Store the created event id against the request inside the app so a retry or a second approval never creates a duplicate entry, and if the calendar write fails, keep the Deel approval and show on the row that the calendar copy did not go out.

Put a Check coverage button on every pending request that kicks off a background agent. The agent pulls the requester's team and department from Deel List People and Deel List Teams, finds their manager with Deel List Managers, gathers every overlapping request across the organization from Deel List Time-Off Requests for Organization, and looks at that person's own recent history with Deel List Time-Off Requests by Profile. It then writes a short coverage recommendation, a few sentences at most, saying who else is out on those days, which day is thinnest, whether the team crosses the configured threshold, and a clear leaning toward approving or holding. Save the recommendation against the request so the app shows it inline on the queue row and in the request detail, stamped with when it was generated. Show the row as in progress while the agent runs, and let me re-run it later, since the picture changes as more requests come in.

Two things about the Deel data to get right. The time off list endpoints are cursor paginated with a next token and a has_next_page flag, so the handler must page all the way through instead of reading the first page only, otherwise the board quietly misses absences and the coverage math is wrong. Deel responses are also wrapped in a top level data object, with list endpoints carrying their pagination metadata alongside it.

Keep a local record of every decision made in the app, including who made it, when, and whether the shared calendar entry was created, and show it as a recent decisions list beside the queue. Persist the conflict threshold, the shared calendar choice and the default scope as app settings so they survive a reload.

## How to customize

- Change the share of a team that has to be out on the same day before the board calls it a coverage clash, which starts at 20 percent.
- Switch the board between only the teams you manage and the whole company, and pick which one it opens on.
- Choose which shared calendar approved absences get added to, and what each entry is titled.

## FAQ

### Does approving here actually update Deel?

Yes. Approve and Reject write the decision straight back to the request in Deel, so Deel stays the single source of truth and balances update as normal. Nothing sits in a separate approval system waiting to be copied over.

### Can I see who else is already off before I approve?

That is the whole point of the board. Every pending request shows how many teammates are already booked off on those same dates and names them, and the twelve week grid puts the request in context against the rest of the team.

### What counts as a coverage clash?

By default the board flags a request when approving it would put more than 20 percent of a team out on any single day. You can raise or lower that share in the settings, and the flag names the specific days that clash.

### Will the rest of the company see approved time off?

Yes. Each approval is added to a shared team calendar as an all day entry covering the leave dates, so colleagues outside Deel can see who is away without asking. You choose which calendar it writes to.

### Do I need to be an HR administrator to use this?

No. It is built for people managers and People Ops. A Deel login that can view your people and approve their time off is enough, and the board opens on just the teams you manage until you toggle to the whole company.

Use this prompt in General Input: https://www.generalinput.com/prompts/a-12-week-coverage-board-for-approving-time-off-in-deel