A leave request process often starts as a shared spreadsheet and an email to a manager. It works until two people book the same week, a manager is away, or payroll needs a reliable record. This Power Apps leave request example shows what a useful internal app should do: give employees a simple way to request time off, give managers a clear approval decision, and leave HR or operations with an auditable record.

The aim is not to build a miniature HR platform. For most small and mid-sized organisations, it is to remove the manual handoffs around annual leave while keeping the process inside Microsoft 365.

What a practical Power Apps leave request example includes

A good app has three distinct views: an employee request form, a manager approval view and an administrative view. Trying to put every option on one screen usually creates an app that feels more complicated than the inbox and spreadsheet it was meant to replace.

For employees, the form should ask for leave type, start date, end date, whether the request covers full or half days, and an optional comment. It should then show the number of days requested before submission. That small calculation matters. People should not have to count working days manually or wait for someone in HR to tell them whether they have entered the dates correctly.

A manager needs different information. They should see who is requesting leave, the dates, requested days, available allowance where appropriate, and any overlapping approved absence in their team. The action itself should be simple: approve, reject or return the request with a comment.

Administrators need a complete register with filters by employee, status, date range and leave type. They also need controlled ways to correct an allowance, amend a request or deal with an approval that has stalled because a manager is absent. Those exceptions are where spreadsheet processes tend to unravel.

The data structure behind the app

For a straightforward deployment, SharePoint lists are usually a sensible place to start. They are already within the Microsoft 365 tenant, are understandable to business users and provide version history without introducing another system.

A basic leave request list might contain the employee, leave type, start and end dates, requested days, status, manager, manager comment, submitted date and decision date. A separate entitlement list can hold each employee’s annual allowance, carried-over days and any adjustment made during the year. A holiday calendar list gives the app a source for bank holidays and organisation-specific closure dates.

Keep the leave types deliberate. Annual leave, unpaid leave, compassionate leave and study leave may follow different policies. Sickness absence may need separate handling altogether, particularly where access should be more restricted. Combining every absence type into one generic form is possible, but it often creates difficult reporting and privacy problems later.

Employee and manager data also deserves thought. If managers are maintained manually in a list, someone must own that information when staff move roles. For organisations with a clean Microsoft 365 directory, the app can use reporting-line information instead. Neither approach is automatically right. Directory data reduces duplication; a maintained list can be more flexible where approval routes do not match the formal organisation chart.

Building the request screen in Power Apps

Start with the minimum path an employee needs to complete. The app should identify the signed-in person automatically rather than asking them to select their own name. Default their line manager where that is dependable, then allow an administrator to apply an exception if needed.

The important calculation is working days. A simple date difference is not enough because it includes weekends and may include bank holidays. The app needs to count weekdays in the selected period, then subtract dates held in the holiday calendar. Half-day requests can be managed with a start-day and end-day option, but define the policy first. A half day on a single date is easy. Half days across a multi-day request need clear rules or they will produce confusing totals.

Before submitting, validate the request. At minimum, prevent an end date before the start date, block requests that overlap an existing approved request, and check that the employee has enough available entitlement if the leave type uses an allowance. It is usually better to show a clear explanation on screen than to let a workflow reject the request later.

A useful confirmation message might state: “Your request for 3.5 days from 14 to 18 July has been sent to your manager.” It sounds ordinary, but it reduces follow-up messages because the employee knows the request was recorded and has not simply disappeared.

Balances need a defined source of truth

Balance calculations are where apparently simple leave apps become more involved. You need to decide whether the entitlement list stores a live balance or an annual allowance from which approved leave is calculated.

For many organisations, storing the allowance and calculating approved days works well. The app can show available leave as allowance, plus carry-over and adjustments, less approved leave. Pending requests should normally be displayed separately rather than deducted immediately, otherwise rejected requests can make balances look wrong.

This approach is transparent, but it needs sensible performance testing as request volumes grow. Filtering and summing a large SharePoint list directly in the app can be unreliable if the formula is not designed around delegation limits. For a modest workforce and one leave year, it may be perfectly adequate. For a larger or more complex environment, calculate balances in a controlled process and write the result back to the entitlement record.

The key point is to avoid maintaining the same balance in several places. If payroll, HR and a SharePoint list all hold different figures, the app will not fix the underlying process.

Use Power Automate for the approval, not as a substitute for design

When an employee submits a request, Power Automate can create the approval, notify the manager and update the SharePoint record with the outcome. It can also send the employee a confirmation, notify a delegated approver and remind managers about requests that have been waiting too long.

The approval route should reflect how the business actually works. A single manager approval is enough for many teams. Other organisations may require a second approval for long periods of leave, unpaid leave or dates that clash with a business-critical period. Add that complexity only where there is a real policy requirement. Every extra stage increases the chance that requests sit waiting in a queue.

Delegation is not optional. Managers take leave too. Define who can approve when the normal manager is unavailable, whether that delegation is temporary, and who has authority to override an outcome. An operations or HR administrator should be able to resolve a stuck request without editing hidden workflow settings.

It is also worth deciding what happens after approval. Some organisations simply update the record and let managers plan around it. Others create an entry in a shared team calendar. Calendar visibility can help resource planning, but it should not expose sensitive absence categories. A calendar entry labelled “Unavailable” may be more appropriate than publishing the leave type.

Permissions, privacy and governance

Leave data is personal data, so a standard SharePoint list with broad read access is rarely the right answer. Employees should normally see their own requests, managers should see requests they need to act on, and authorised administrators should see the full register.

There is a trade-off here. Item-level permissions can provide tight control, but applying unique permissions to every request creates administration and scale considerations. In a smaller organisation with ordinary annual leave, a manager view filtered by user and a carefully controlled site may be sufficient. Where the app records sensitive categories, separate lists or a more restricted process may be the better design.

Do not rely solely on what the Power Apps screen hides. Configure the underlying data permissions properly. Anyone with access to the list can potentially see more than the app displays.

Governance also means deciding who owns the app after launch. Someone needs to update the leave year, bank holiday dates, policy wording, approver exceptions and entitlement adjustments. Give that person a short operating guide and avoid building a solution that only its original developer can maintain.

Test the cases that cause arguments

Before rolling out, test more than the happy path. Submit a request across a weekend, include a bank holiday, request a half day, create an overlap, reject a request, change a manager and test a manager who is unavailable. Test what an employee sees after a decision and what happens if they withdraw a pending request.

Also test against real policy questions. Can someone request leave before they have accrued it? Is there a maximum consecutive absence period? Are leave allowances pro-rated for starters and leavers? The app cannot answer those questions, but it should enforce the decisions the organisation has made.

A well-built leave request app saves time because people stop chasing approvals and reconciling spreadsheets. More importantly, it gives managers a current view of availability and gives the business one record it can trust. Start with the policy and the process people will genuinely follow, then use Power Apps and Power Automate to make that process quicker, clearer and easier to manage.