A leave request should not spend three days in an inbox because a manager is in meetings, another colleague is copied in unnecessarily, or nobody is sure who has authority to approve it. Yet that is still how many small and mid-sized organisations handle annual leave: email, spreadsheet, reminder, chase, update calendar, repeat.
When you automate leave approvals, the objective is not to remove management judgement. It is to put that judgement at the right point in a controlled process, with the information needed to make a quick decision. Employees get a clear answer, managers see what matters, and HR or operations teams stop reconciling scattered messages at the end of the month.
For organisations already using Microsoft 365, this is usually a practical Power Automate and SharePoint exercise rather than a large software procurement. The hard part is rarely the technology. It is agreeing the rules before the workflow goes live.
What a useful leave approval workflow actually does
A basic automated process starts with a simple request form. The employee enters the leave type, start and end dates, whether the request is a full or partial day, and any useful note for their manager. The request is then recorded centrally, rather than disappearing into an individual mailbox.
From there, Power Automate can identify the appropriate approver, send an approval request and record the decision. The employee receives confirmation, while the central record updates with the status, approver, date and any comments. A team calendar can show approved absences so managers can spot gaps before they become a problem.
That is the core process. In most organisations, it also needs a few controls: date validation, delegation when a manager is away, reminders for unanswered requests and a route for rejected or cancelled leave. These are not decorative extras. They are what prevent an apparently automated process becoming another queue that someone has to chase.
Start with policy, not the flow diagram
It is tempting to begin with the approval action in Power Automate. Start instead with the questions your policy needs to answer. Who approves leave for each employee? Can a manager approve their own request? What happens when the normal approver is absent? Does every leave type follow the same route? Can people request leave after the fact, and who can amend an approved request?
The answers are often less consistent than expected. A department may rely on an informal stand-in manager. Another may require a second approval for extended leave. Some teams may need to protect minimum staffing levels, while others simply need visibility of who is out.
There is no universal approval pattern. A ten-person office may sensibly use one manager approval and an automatic calendar update. A business with shift-based teams, regulated roles or customer-facing cover requirements may need a second check before confirmation. The point is to make the exceptions explicit, rather than burying them in email habits.
Build the request around the decision
A good form asks for only the information needed to process the request. Long forms reduce adoption and create poor-quality data. In most cases, the employee should select their dates and leave category, state whether they are taking a full day or part day, and add a short note only where it is genuinely useful.
The approval request should give the manager enough context to act without hunting through calendars and staff lists. That normally means the employee name, requested dates, duration, leave type, current status and a direct approve or reject decision. If cover is a concern, include the relevant team absence view or identify colleagues already approved as away over the same period.
Keep absence reasons proportionate. Annual leave generally requires no explanation. Sickness and other sensitive absence categories may need a separate, more restricted process. Putting every detail into a broad SharePoint list can create an unnecessary confidentiality issue, especially where managers should see only their own team’s information.
Use a clear source of truth
A SharePoint list is a sensible place to hold requests, approvals and statuses for many organisations. It supports reporting, permissions, views and workflow triggers without introducing another platform. It also gives HR and operations a single place to answer straightforward questions: what is pending, what was approved, and who changed it?
However, a leave workflow should not pretend to be a full HR system if it is not one. Leave entitlement, carry-over rules and payroll calculations may already sit elsewhere. If that system is the authoritative record for balances, decide whether the workflow should integrate with it or simply record approval and notify the relevant team. Trying to recreate complex entitlement calculations in a first version often adds cost and fragility without improving the employee experience.
Set approval rules that survive real life
The most common failure in automated leave approval is a workflow that works perfectly until the approver is on leave themselves. Avoid a design that relies on one named person with no alternative.
Manager details can be maintained in Microsoft 365 profile information or in a controlled team structure, allowing the workflow to route a request automatically. For delegation, define whether an alternate approver takes over after a set period or whether employees can choose from an approved list. The former is more controlled; the latter can suit smaller teams but needs careful governance.
Reminders matter too. An approval waiting for 24 or 48 hours should prompt the manager. After a defined period, the request can escalate to a delegate or a senior manager. Escalation should be visible and predictable, not a silent reassignment that leaves the original manager confused.
It is also worth deciding whether the employee can cancel or edit a request after approval. Cancellation is usually straightforward: update the record, notify the manager and remove or amend the calendar entry. Changes are more awkward because they may affect cover. In many cases, treating a date change as a cancellation plus a new request produces a cleaner audit trail.
Make the result visible without exposing too much
An automated decision is only useful if people can see its outcome in the place where they work. Employee notifications can arrive through email or Teams, while managers may benefit from a dashboard showing outstanding approvals and upcoming team absence.
For a SharePoint intranet, an absence page can make approved leave more visible without publishing sensitive details. A simple calendar or filtered list may be enough. Different audiences should see different information: employees may only need names and dates for their own team, whereas HR may require wider reporting and the underlying leave category.
This is where permissions deserve proper attention. Do not assume that hiding a column in a list view protects confidential data. Configure access so users can only read and edit the records they should handle. Test the experience as an employee, manager, delegate and HR administrator before release.
Test the awkward scenarios first
Before rolling out, test more than the happy path. Submit overlapping requests, partial-day leave, requests spanning a public holiday, a manager who is away, a rejected request, a cancelled request and a request from someone who has moved teams. Check that notifications are clear and that the calendar is not updated twice.
You should also test what happens when a workflow action fails. Microsoft 365 automation is dependable, but credentials change, connections expire and fields are occasionally renamed. A named process owner should know how to identify failed runs and correct a request without asking the employee to start again.
A short pilot with one department is usually more valuable than weeks of internal debate. It reveals whether managers need more context, whether the form is too demanding, and whether the policy has gaps. Once the pattern is proven, the same foundations can support other routine approvals such as expenses, equipment requests or policy acknowledgements.
When standard automation needs more design
A straightforward leave process can be delivered quickly when the rules are clear. The work becomes more involved where an organisation needs live entitlement checks, rostering integration, multiple approval stages, different regional holidays or strict segregation between teams.
That does not mean the project is unsuitable for Microsoft 365. It means the scope should be honest. Start with the operational problem that creates the most manual work, then decide whether integrations and advanced rules are essential for launch or sensible later improvements. A simpler first release that managers actually use is preferable to a heavily customised workflow that takes months to finalise.
ThePoint works with organisations that want to turn this kind of everyday friction into a practical SharePoint and Power Automate process, with senior Microsoft guidance rather than a generic template dropped into the tenant. The right approach is shaped around your policy, existing data and who needs to act on the request.
The best leave workflow is not the one with the most branches. It is the one employees trust to submit, managers can approve in moments, and operations teams no longer have to reconstruct from emails.