A 12 week coverage board for approving time off in Deel

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.