The Problem Nobody Writes Down
Company car requests are one of those things that sounds trivial until you're on the inside. The actual sequence usually goes like this: an employee needs a company car for a two-day supplier visit on Tuesday and Wednesday. They send an email to the fleet manager or their direct manager, whoever handles it in their company. The fleet manager is on holiday, or in a meeting, or simply hasn't checked email yet. The employee follows up Thursday morning. By then, the answer is that the car was free the whole time, but they already took a train.
Or the opposite: two people independently book the same car by phone for the same date. Nobody double-checks the shared calendar, because the shared calendar is a spreadsheet that one person updates manually when they remember to. You end up with a conflict discovered at 7am on Monday when both colleagues arrive at the car park.
This is not a fleet management problem. This is a workflow problem. The process exists, it just runs through email, phone calls, and a spreadsheet that nobody trusts. The fix is to replace those three with one automated flow that anyone can trigger from Teams.
Before You Build: Three Things You Need
The flow itself takes half a day to build. The preparation can take a week if you skip it. Get these three things sorted first:
- A SharePoint list of vehicles. Each row is one car. Columns: vehicle ID, make and model, home site or department, registration plate. That is the minimum. Add fuel type, capacity, or special notes if relevant.
- A SharePoint list for bookings. Each row is one booking. Columns: vehicle ID (linked), requester name, start date, end date, status (Pending, Approved, Rejected), purpose. This is where the flow writes every confirmed request.
- Clarity on the approval chain. Does the fleet manager approve everything? Or does each department's manager approve for their own team? Define this before building the flow, not after. The approval routing is the one thing that changes between companies.
The 4-Step Flow
Step 1 — Employee submits a request via Teams
The entry point is a Teams tab or a shared link pointing to a simple form. The easiest option: a Microsoft Form or a Power Apps canvas app embedded in a Teams channel. The form fields are minimal — vehicle preference (or "any available"), requested dates, destination or purpose. The employee fills it in, hits submit, and that triggers the flow.
If you want the more polished version: use an Adaptive Card sent directly to the employee's Teams chat as a prompt. They fill it in without leaving Teams. The trigger for the flow is "When a new response is submitted" from Microsoft Forms, or "When an item is created" in a SharePoint list if you go the Power Apps route.
Step 2 — Flow checks availability against the bookings list
Once the request is submitted, the flow queries the SharePoint bookings list and asks: is the requested vehicle (or any vehicle from the home site) already booked for those dates? Use the "Get items" action from the SharePoint connector with a filter query on the date range and vehicle ID. If the vehicle is unavailable, the flow sends an automatic message back to the requester via Teams, showing which vehicles are free. No approval needed, no manual intervention.
If the vehicle is available, the flow moves to step 3. This check takes about two seconds in the background — the employee does not see it happening.
Step 3 — Approval card sent to the fleet manager (or direct manager) in Teams
The flow posts an Adaptive Card to the approver's Teams chat. The card shows: who is requesting, which vehicle, what dates, and the stated purpose. Two buttons: Approve and Reject. The approver clicks one button and that is it — they do not need to open an email, find a form, or navigate anywhere else.
Use the "Start and wait for an approval" action in Power Automate. Set a response timeout — 24 or 48 hours is reasonable. If the approver does not respond within that window, the flow can escalate automatically (send a reminder, or notify a backup approver if you define one). This removes the "I was in meetings all day" excuse for delayed approvals.
Step 4 — Confirmation sent, booking written, reminder set
When the approver clicks Approve, three things happen automatically in sequence: the flow creates a new item in the SharePoint bookings list (so the car is now marked as reserved), it sends a Teams message to the requester confirming the booking with the vehicle details, and it creates a calendar event or sends a reminder the day before the booking starts. No manual calendar update needed. No email from the fleet manager needed. The booking is in the system and the requester knows.
If the approver clicks Reject, the flow sends a Teams message to the requester with the rejection and, optionally, the approver's note. Clean, no orphaned requests sitting unanswered in someone's inbox.
Honest Notes on Complexity
This is genuinely a half-day project if you have the SharePoint lists ready. The Adaptive Card approval step is the trickiest part for someone building their first approval flow — not because it is difficult, but because the action name ("Start and wait for an approval") is not obvious to find in the Power Automate interface. Once you have found it and connected it to Teams, the rest is straightforward.
The availability check in step 2 requires a basic OData filter query on SharePoint. Something like: StartDate le '2026-04-15' and EndDate ge '2026-04-14' and VehicleID eq 'CAR001'. If you have never written an OData filter before, this is where most people get stuck for an hour. It is documented on Microsoft Learn, and it is worth reading before you start.
What you do not need: Power Automate Premium. All connectors used here (SharePoint, Teams, Forms, Approvals) are standard and included in M365. If your organisation already has M365 Business Standard or above, this costs nothing in new licences.
What You Can Add Later
The basic flow handles bookings cleanly. Once it is running without issues for a month, here are the natural extensions: a Power BI report showing vehicle utilisation by month (which cars are actually being used and which are sitting idle), a self-service cancellation card sent to the requester before the booking starts, or a mileage log form triggered automatically when a booking ends. None of these require rethinking the architecture — they are additions to the same SharePoint list and the same flow.
The first version of this does not need to be perfect. It needs to be better than an email chain. That bar is very low.
The real win here is not just efficiency. It is that the booking record now lives in SharePoint instead of someone's sent items folder. Disputes about whether a car was reserved, who confirmed it, and when are settled by the list — not by memory. That is worth more than any time saving in the first month of using it.
If your team manages a fleet of company cars and approval still runs through email or phone, this is a straightforward build. It does not require a developer, it does not require a new tool, and it does not cost anything you are not already paying for. You need one afternoon and a willingness to set up two SharePoint lists before you start.
For how to handle more complex approval chains, or for building a similar logic into contract workflows, see Contract Nemesis. For thinking through whether your team is ready to start automating at all, Where to Start With AI in Procurement gives a practical entry point. And if you are considering the Microsoft Copilot layer on top, Copilot for Procurement walks through what it actually does versus what is marketed.