Blog

Why this project mattered

Small businesses often reach a point where informal processes begin creating friction. A time off request may start as a quick text message, an email to a manager, or a note on a shared calendar. That can work for a very small team, but as the business grows, those manual steps become harder to track.

Who approved the request? Was the employee notified? Was the time off added to the calendar? Is there a historical record of the decision? These are the kinds of questions that turn a simple administrative process into an operational problem.

For a small business project in Columbus, Ohio, I helped create a lightweight time off approval system using Microsoft 365 tools that were already available to the organization. The solution used Microsoft Lists as the request database, Power Automate as the approval engine, Planner for task visibility, Outlook for notifications, Microsoft 365 Groups for the shared calendar, and Power Apps to improve the request form experience.

The original project request was to create a time off request system with an approval process and place approved requests on a group calendar. The documented solution used Microsoft Lists, Power Automate, and Power Apps as the core components.

The business problem

The organization needed a more structured way to manage employee time off requests without purchasing a dedicated HR platform or building a custom application from scratch. The requirement was not overly complex, but it needed to be reliable and easy for both employees and managers to use.

The business needed the ability to:

• Create a centralized request form for employee time off.
• Capture the time off category, reason, start date, and end date.
• Route the request to an approver.
• Capture approval comments.
• Update the request approval status.
• Notify the employee whether the request was approved or denied.
• Add approved time off to a shared group calendar.
• Create and complete a Planner task for visibility.

This is exactly the kind of practical workflow where Microsoft 365 and the Power Platform can deliver value quickly. Instead of introducing another standalone system, the business could use tools that were already part of its Microsoft environment.

Solution overview

The solution was built around three primary Microsoft 365 services:

• Microsoft Lists — used as the system of record for time off requests.
• Power Automate — used to route the approval, update status, create Planner tasks, send notifications, and add approved requests to the calendar.
• Power Apps — used to customize the Microsoft Lists form and improve the user experience.

Additional Microsoft 365 services were also used, including Planner, Outlook, and Microsoft 365 Groups. Each service had a focused role in the process, which helped keep the solution understandable and maintainable.

Step 1: Create the Microsoft List

The first step was creating a Microsoft List to store each time off request. This list became the central location where requests could be submitted, reviewed, approved, denied, and referenced later.

The list included the following key columns:

• Title — a single line of text used to identify the request.
• Time Off Category — a choice column for the type of time off.
• Reason — a multiple lines of text column for additional context.
• Time Off Start — a date and time column with time included.
• Time Off End — a date and time column with time included.
• Send for Approval — a placeholder column later formatted as a button.
• Approval Status — a system column used with content approval.
• Approver Comments — used to retain comments from the approval process.
• Created By — used to identify and notify the original requestor.

The time off category field included options such as paid full day, paid first half day off, paid second half day off, unpaid, and vacation. This gave the business enough structure to classify requests without making the form too complicated.

Step 2: Enable approval tracking

The list was configured for content approval so that each request could move through a structured approval state. This allowed the workflow to update the item as submitted, approved, or rejected.

In the list view, additional system columns were included so that users and managers could see approval status, approver comments, and who created the request. This turned the list into more than a simple form. It became a lightweight approval tracking system.

Step 3: Build the Power Automate flow

The core workflow was built in Power Automate. The flow was named Time Off Approval with Task Creation.

The flow started with the SharePoint trigger For a selected item. This allowed the workflow to be launched manually from a specific Microsoft Lists item. Two inputs were added to the trigger:

• Approver — the person responsible for approving or denying the request.
• Message — additional detail to include in the approval request.

This approach gave the business flexibility. The request could be created in the list first, and then the approval could be started when ready.

Step 4: Retrieve the request details

After the flow started, a SharePoint Get item action retrieved the full details of the selected list item.

This is a common Power Automate pattern. The selected item trigger provides the item ID, and the Get item action retrieves the full set of column values needed later in the workflow. Those values were then used in the approval request, Planner task, email notification, and calendar event.

Step 5: Create a Planner task

The next step created a task in Microsoft Planner. The task was placed in the time off approvals plan and assigned to the selected approver.

This was a useful operational improvement. Approvals often get lost when they only live in email. By creating a Planner task, the business gained another visual way to track pending requests. It also helped managers see approval work alongside other operational tasks.

The task title used the request title from the Microsoft List, and the assigned user came from the approver input collected when the flow was launched.

Step 6: Start and wait for the approval

The flow then used the Power Automate approval action Start and wait for an approval.

The approval type was configured as Approve/Reject — First to respond. The approval included:

• A title based on the time off request.
• The selected approver as the assigned user.
• The message entered when the flow was launched.
• A link back to the original list item.
• The request title as the item link description.

This gave the approver enough information to make a decision while also preserving a direct path back to the original request.

Step 7: Capture approval comments

Approval comments are important because they provide context. If a request is denied, the employee should understand why. If a request is approved, comments can still help document any conditions or notes related to the decision.

To handle comments, the flow initialized a string variable named varComments. After the approval response was received, the comments from the approval action were stored in that variable.

Because some approval response outputs can be returned as collections, the comment handling was wrapped in an Apply to each step. This is one of those practical Power Automate details that matters when moving from a simple demo to a real business workflow.

Step 8: Update the content approval status

After the approval response was received, the flow updated the Microsoft List item’s approval status.

The process included setting the item to submitted and then updating the final approval status based on the approval outcome. The approval comments stored in varComments were written back to the item as part of this step.

One important implementation detail was the use of the SharePoint ETag value when setting the final content approval status. Forgetting the ETag can cause problems when updating approval status, so it is worth calling out as a key lesson from the build.

Step 9: Branch based on approval outcome

The flow then used a condition to check whether the approval outcome was equal to Approve.

This split the process into two paths:

• Yes branch — the request was approved.
• No branch — the request was denied.

This branching logic allowed the workflow to take the correct business action depending on the decision.

Step 10: If approved, create a group calendar event

If the request was approved, the flow created a Microsoft 365 group calendar event.

The calendar event used:

• Subject — the title of the time off request.
• Start time — the Time Off Start value from the list item.
• End time — the Time Off End value from the list item.

This step solved one of the most important business problems: ensuring approved time off actually appeared where the team could see it.

In the original build, the desired Microsoft 365 group was not showing in the searchable list inside the action. The workaround was to locate and use the group ID directly. This is a realistic implementation detail that often appears in Microsoft 365 projects. Sometimes the designer experience does not show every object you expect, and knowing how to locate the underlying ID helps complete the solution.

Step 11: Notify the requestor

Once the decision was made, the workflow sent an email to the employee who created the request.

For approved requests, the email notified the employee that the request had been approved. For denied requests, the email included the comments captured from the approver.

This closed the communication loop and reduced the need for managers to send separate follow-up messages.

Step 12: Complete the Planner task

In both the approved and denied branches, the flow updated the Planner task and marked it as completed.

This kept Planner from becoming cluttered with old approval tasks. Once a decision was made, the associated task no longer needed to remain open.

Step 13: Improve the request form with Power Apps

The final part of the solution improved the Microsoft Lists form using Power Apps.

From the list, the form was customized by selecting Integrate > Power Apps > Customize forms. This allowed the default list form to be refined into a cleaner data entry experience.

One practical improvement involved the date and time picker. The default form experience used a 24-hour time format, but the business preferred a 12-hour AM/PM format. To support that, the form was customized with an AM/PM dropdown and adjusted hour controls.

This is a good example of using Power Apps in a targeted way. The project did not require a full standalone application. Power Apps was used only where it improved the user experience.

Step 14: Add a Send for Approval button

To make the process easier for users, the Send for Approval column was formatted as a button in Microsoft Lists.

The button used SharePoint column formatting JSON and the Power Automate flow ID. Once configured, users could launch the approval process directly from the list item instead of opening Power Automate separately.

This small user experience improvement made the workflow feel much more integrated. For business users, a visible button is easier to understand than a separate automation menu or back-end workflow.

Why this worked well for a small business

This solution worked because it was practical. It did not attempt to over-engineer a simple process. Instead, it used the right Microsoft 365 service for each part of the workflow.

• Microsoft Lists provided the structured request log.
• Power Automate handled the approval workflow and business logic.
• Planner gave managers task visibility.
• Outlook handled employee notifications.
• Microsoft 365 Groups provided the shared calendar destination.
• Power Apps improved the form experience.

For a small business, that combination is powerful. The organization gets a workflow that feels custom, but it is still built on familiar Microsoft 365 services.

Lessons learned

A few lessons stood out from this project:

• Start with the business process. Before building the flow, define who submits the request, who approves it, what happens after approval, and what happens after denial.
• Keep Microsoft Lists as the system of record. The list gives the business a structured history of requests, statuses, comments, and requestors.
• Use Planner when visibility matters. A Planner task gives approvers another way to track pending requests outside of email.
• Capture approval comments. Comments are important for transparency and recordkeeping.
• Use Power Apps surgically. Not every solution needs a full custom app. Sometimes customizing the list form is enough.
• Make the workflow easy to launch. A formatted button in Microsoft Lists can improve adoption by giving users an obvious next step.
• Document implementation details. Items like group IDs, ETags, and renamed Power Apps controls matter when troubleshooting or maintaining the solution later.

Potential enhancements

This type of solution can start simple and grow over time. Potential enhancements could include:

• Automatic manager lookup based on the requestor.
• Department-specific approval routing.
• Calendar conflict checks before approval.
• Holiday or blackout date validation.
• Automated reminders for pending approvals.
• Power BI reporting for time off trends.
• Separate approval paths for paid, unpaid, vacation, or partial-day requests.
• Integration with payroll or HR systems.
• A dedicated mobile-friendly Power App for employees.

The important point is that the foundation does not need to be replaced. Microsoft Lists and Power Automate provide a flexible base that can evolve as the business process matures.

Final thoughts

This time off approval system is a strong example of what the Power Platform can do for small businesses. It replaced a manual, easy-to-miss process with a structured workflow that captured requests, routed approvals, updated status, notified employees, and placed approved time off on a shared calendar.

For small businesses in Columbus and similar markets, these kinds of Microsoft 365 automations can create immediate operational value. They reduce manual follow-up, improve accountability, and make everyday administrative work easier without requiring a large software investment.

The best Power Platform projects are often not the most complicated ones. They are the ones that solve a clear business problem, fit naturally into the tools people already use, and make the process easier for everyone involved.