What this automation does
Two related flows share the same approval plumbing: time-off requests, which happen any time, and timesheets, which close on a fixed cycle.
Time off
- Request. An employee types in Slack or Teams, for example “Out Thursday and Friday next week for a wedding”, or submits the HRIS form.
- Parse. For free-text requests, a model extracts dates, partial days and leave type into a fixed structure and echoes it back for the employee to confirm.
- Check policy in code. The workflow pulls the projected balance as of the leave date, checks minimum notice, blackout periods and company holidays, and counts how many teammates are already out.
- Ask the manager. The manager gets one message with the request, the balance after approval, the coverage picture and approve or decline buttons.
- Record. On approval, the request is written to the HRIS, the employee’s calendar gets an out-of-office block, and the team calendar is updated.
Timesheets
- Remind. Two days before the period closes, employees with missing days get a direct message.
- Check. At close, the workflow pulls entries and flags missing days, hours on approved PTO days, possible overtime for non-exempt staff, and project codes that are closed or over budget.
- Summarize. A model writes a short plain-English note per employee for the manager, such as “38 hours, Tuesday missing, 6 hours booked to a closed project”.
- Approve and lock. Managers approve in chat. Anything not approved by the payroll cutoff escalates to payroll with the list of open items.
When it is worth building
The clearest sign is payroll corrections. If payroll regularly reruns or adjusts because timesheets were late or wrong, or because PTO was taken but never recorded, the automation pays for itself quickly. The second sign is managers approving requests days late because the HRIS notification email went unread.
Skip it if you have fewer than about 20 employees and one approver, or if your HRIS approval flow already works. Building around a tool your managers are happy with only adds moving parts.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Request channel | Slack or Microsoft Teams, plus the existing HRIS form | Meets employees where they already ask for things |
| Parsing | A small model with a strict schema, such as Claude Haiku 5.5 | Turns “next Thu and Fri, half day Mon” into dates, cheaply and quickly |
| Policy engine | Code inside n8n, with rules in a Google Sheet HR can edit | Balances, notice and coverage must be calculated exactly and be easy to change |
| HR data | BambooHR API; Gusto through exports or an approved partner; ADP through its partner program | Balances and approved leave stay in the system of record |
| Approvals | Interactive Slack or Teams messages with buttons | One tap for the manager, with every bit of context in the message |
| Calendar | Google Calendar or Outlook | Out-of-office blocks keep scheduling and coverage views accurate |
| Audit | Approval log with who approved what and when | Payroll and HR can answer “who approved this” without digging |
How to build it
- Write the policy as rules. Turn the handbook’s PTO section into explicit checks: accrual rate, carryover cap, notice by request length, blackout dates, maximum people out per team.
- Map approvers and delegates. Pull the reporting line from the HRIS and add a delegate per approver.
- Build the PTO flow first. It is lower risk than timesheets and gets managers used to approving in chat.
- Calculate projected balances. Use the balance as of the leave date, including accruals between now and then, not today’s balance.
- Add timesheet checks. Start with missing days and possible overtime. Add project-code checks once the basic flow is stable.
- Tie it to the payroll calendar. Reminders, escalations and the lock all key off the payroll cutoff, so store pay schedules explicitly.
- Run one pay cycle in parallel. Compare the workflow’s flags with what payroll caught manually before turning off the old process.
The downloadable starter template below covers Slack PTO requests, model parsing, the balance and coverage checks against BambooHR, and the manager approval message.
What breaks in production
- Edited requests. An employee changes dates after approval. Treat edits as a new request linked to the old one, or balances get counted twice.
- Separate leave buckets. Many states and cities require paid sick leave that must be tracked separately from vacation. If buckets are merged in the rules, balances will be wrong.
- Partial days and shift workers. “Half day” means four hours for one person and five for another. Store standard hours per employee.
- Retroactive changes. A timesheet is corrected after approval but before payroll runs. Re-approval must be required, and payroll must see the change.
- Holiday calendars by entity. Different entities or locations observe different holidays, and the PTO math has to know which calendar applies.
- API limits at cutoff. Everyone submits in the last hour. Batch HRIS writes and retry with backoff instead of failing silently.
Timeline and cost
PTO approvals alone take about two weeks; adding timesheet checks and the payroll calendar brings it to around three. Lumeor builds this in the range of $4,000 to $9,000, depending on the HRIS, how many leave types and locations you have, and whether timesheets live in a separate tool. If approvals are only one of several bottlenecks, our guide to automating internal approvals shows how the same pattern extends to purchases and expenses.
How to measure success
- Median hours from PTO request to decision
- Share of timesheets approved before the payroll cutoff
- Payroll corrections per cycle caused by time or leave errors
- Possible-overtime flags caught before payroll rather than after
- Share of requests handled entirely in chat without opening the HRIS
- Escalations to delegates, which shows where approvers are overloaded
For professional services firms that bill by the hour, pair this with AI time entry drafting so the timesheets arriving for approval are more complete in the first place.