Purchase Request and Approval Automation in Microsoft Teams — Power Automate, SharePoint and Teams Approvals

A working purchase request and approval workflow in your own tenant: a request form (Power Apps form on a SharePoint list, or Microsoft Forms), a purchase request register with permissions and views, a routing-rules list your finance team maintains, Power Automate flows that route each request by amount and cost centre through up to three stages (line manager, budget owner, finance) with reminders and backup-approver escalation, Teams Approvals cards for every decision, requester notifications, a decision log, an Excel export or one-page Power BI report, optional PO numbering, the administrator and user guides, and one month of break-fix after closure. The price is fixed and quoted in writing; you pay after you approve delivery.

You do. In the design workshop your finance owner gives us the approval matrix — for example, line manager only below your first threshold, manager plus budget owner up to the next, and finance on top above it — and the budget owner for each cost centre. We store both in a routing-rules list in SharePoint rather than hard-coding them, so when finance changes a threshold or a budget owner moves, someone edits a list row and the next request follows the new rule. The line manager is looked up from Microsoft Entra ID at submission time; where your directory is not maintained we use an explicit approver column instead.

Wherever they already are. Each stage is a Microsoft Approvals request, so it shows up in the Approvals app in Teams, as a card in the Teams activity feed, as an actionable message in Outlook and in the Power Automate mobile app. Approvers see the summary, the amount, the cost centre and a link to the quote, and answer Approve, Reject or Return for information with a comment. If they are the wrong person, they can reassign the pending request to the right one and the reassignment is recorded.

Not for the standard build. It uses only standard connectors — SharePoint, Forms, Teams, Approvals, Office 365 Users and Outlook — which are covered by the Power Automate and Power Apps rights included in Microsoft 365 Business Basic, Standard and Premium and in E3 and E5. You need premium licences if you choose a Dataverse register instead of a SharePoint list, or if an option adds a premium connector: then the users who run those flows and apps need Power Automate Premium or Power Apps Premium. Those are Microsoft's per-user charges, we confirm them in the design workshop before you decide, and we sell them at Microsoft's list price if you want them through us.

For a simple sign-off by a fixed set of people, yes, and we will say so. SharePoint's built-in list approvals and the Approvals app's templates let someone request a decision from named approvers without any flow. What they do not do is read the amount and cost centre to decide who has to sign, chase approvers, escalate to a backup, keep a decision log finance can search, produce a report or issue a PO number. Those are the things a purchasing process needs, and they live in Power Automate — which is what this service builds on top of the same Approvals cards.

Our default is a Power Apps form on the SharePoint list: the quote is attached to the request record itself, requesters see their own status in the register, validation is richer, and everything stays in one place. Microsoft Forms is the right choice when you want the simplest possible capture and do not need requesters to see status in a list — but its file uploads land in the form owner's OneDrive and it only accepts uploads from people inside your organization, so our flow copies each upload and response onto the request record. Either way the routing, approvals, log and reporting are the same.

Three things, in order. A reminder goes out after the window you set. After the escalation window, the request moves to the backup approver named for that stage in the matrix, and the escalation is logged. At any point the approver can reassign a pending request from Teams or Power Automate to a colleague. Microsoft's approval requests expire after 30 days; the reminders and escalation are designed so that never happens, and if it does the request is marked Expired, the requester is told, and it can be resubmitted from the register.

Every decision is written twice: onto the request record (stage, approver, decision, comment, timestamp) and into a separate decision-log list with one row per decision. The register keeps version history, so field changes are tracked too, and the Approvals app keeps Microsoft's own record of each request. Finance or an auditor filters the log by requester, cost centre, approver or date range in SharePoint, or exports it to Excel — no need to open Power Automate run history to answer who approved what and when.

It is a unique, sequential number in the format you choose (for example PO-2026-0001) that the flow assigns on final approval, stores on the request and prints in the approval notice, so the requester can quote it to the vendor and finance can match it later. It is not a purchase order document in your accounting system. Creating the purchase order or bill in QuickBooks Online or Dynamics 365 Business Central from the approved request is the ERP add-on, scoped and priced separately.

Yes, as an add-on built on top of this workflow. Our QuickBooks Online + Microsoft 365 Integration and Dynamics 365 Business Central Integration Development services cover posting the approved request as a purchase order or bill, with the field mapping and controls your finance team specifies. We keep it separate because ledger posting needs its own licensing, error handling and accounting sign-off; the approval workflow on this page is complete and useful on its own, and the add-on plugs into the approved-request record we already create.

Two weeks. Days 1–2 are the design workshop and sign-off, days 3–5 the register, form and routing rules, days 6–7 the flows and notifications, days 8–9 acceptance testing with your pilot group, day 10 go-live and handover. From you we need a finance owner who can sign off the approval matrix, the thresholds and approver names before the build starts, a licensed service account to own the flows, administrator access for the build, and a pilot group of two or three requesters, one approver per stage and the finance owner in week 2. Late decisions move the calendar, not the price.

You do, from day one. The flows are created under a service account in your tenant with your administrators as co-owners, the register and routing rules are SharePoint lists you administer, and we hand over an exported package plus an administrator guide that shows how to change thresholds, approvers and fields. Nothing runs through IT Partner systems and nothing needs us to keep working. That is our standing policy — no lock-in, in either direction — and the workflow keeps running exactly the same the day after any engagement with us ends.

No. Requests, attachments, the routing rules and the decision log live in a SharePoint site in your tenant; the flows run in your Power Platform environment; the Approvals requests are stored by Microsoft in the Approvals solution in your default Dataverse environment. No third-party service, no IT Partner infrastructure, no connector outside Microsoft 365 in the standard build.

One month of break-fix on what we built, starting at project closure — if a flow fails or a rule misbehaves, we fix it. Organizations that buy their Microsoft licensing through IT Partner already have unlimited break-fix support during business hours as part of that relationship. New stages, fields or reports after the design sheet is signed are change requests, quoted before we build them; ongoing administration is available as a managed-services add-on.