Contact Initial consultation

Case study · industry

Order approval in manufacturing with Power Automate and SharePoint

For a manufacturing company, I implemented a multi-stage approval process for customer orders with Power Automate and SharePoint. Engineering, installation, order management, purchasing, and a second purchasing review handle approvals in sequence; rejections are routed back to the appropriate step with a required explanation. Nine flows, eight SharePoint lists, escalation, and an audit trail form the core system.

Discuss a similar projectAll case studies
  • 06/2026 - 09/2026
  • Part of a group of companies with more than 12,000 employees
  • Implementation
Industry
Industry
Company size
Part of a group of companies with more than 12,000 employees
Scope
Internationally active company within a group of companies
Period
06/2026 - 09/2026
My role
Requirements clarification, design, architecture, and implementation
Type
Implementation

9

Power Automate flows in one solution

540+

actions in the flows

5

approval stages with paths for returning orders for revision

8

SharePoint lists for orders, approvals, log, and configuration

14

product types with their own project number rule

28

versioned solution exports during development

01The situation

Where the project started.

Customer orders had to be reviewed by several departments before further processing: engineering, installation with planning of the installation start date, order management, and purchasing with an additional cross-check by a second person. Each stage needed to be able to approve or reject with a reason, and every decision needed to remain traceable.

For this, the company was looking for a service provider for a role-based workflow with email approvals, escalations, and an audit trail based on Microsoft 365. An on-premises SQL Server was known as a later integration point but was deliberately not to be connected in the first stage.

The parties therefore initially agreed on a pilot or base system to validate the process technically and functionally with test data. Data was to be stored in SharePoint lists as a pragmatic approach, with approvals handled through standard Power Automate mechanisms rather than custom-programmed email buttons.

Goals

  • Map a multi-stage approval process with clearly defined roles in Power Automate
  • Allow rejections only with a reason and send the order back to the responsible party for revision
  • Keep a complete log of statuses, decisions, returns for revision, and errors in SharePoint
  • Allow roles, escalation rules, and project numbers to be maintained without changing the flows
  • Automatically escalate pending approvals after a fixed deadline
  • Create an extensible foundation for a later app interface and an ERP integration

02Solution

What I designed and built.

Modular flow architecture instead of a monolith

I split the process into nine cloud flows within one shared solution: a start flow, one flow each for engineering, installation, order management, purchasing, and the purchasing cross-check, a central email sending flow, a test flow for sending, and a scheduled escalation flow. The flows call each other via HTTP triggers with defined JSON schemas.

  • Workflow ID, SharePoint item reference, correlation ID, step, and role passed with every call
  • Department flows acknowledge the call immediately with HTTP 202 and then continue asynchronously
  • Order management flow with a switch for four scenarios: regular review and orders sent back from engineering, installation, and purchasing
  • Start flow limited to one concurrent run

SharePoint data model separating record, decision, and log

Before implementation, I described the data model in a workbook with lists, columns, indexes, views, and initial values, and then built it in SharePoint Online. Internal column names are in English, and display names are in German.

  • Order list with input data, current step, current role, and status per department
  • Approval list with one record per approval step, a flag for the current approval, and the escalation status
  • Audit trail with event type, old and new status, reason, and correlation ID
  • Configuration lists for roles, escalation rules, email templates, settings, and project numbers
  • Around 150 columns, plus views planned in the data model as work lists per department

Approvals with mandatory reasons and defined paths for revision

Decisions are made via Power Automate approvals (approve or reject). Since the comment field cannot be enforced as a required field there, I check the result in the flow itself. A rejection without a usable comment is not processed further, and the decision is requested again.

  • A rejection in engineering, installation, or purchasing goes back to order management with a reason
  • After correction, engineering receives the original reason for rejection together with the correction comment
  • A rejection in the purchasing cross-check leads back to the regular purchasing approval
  • In order management, Do until loops ensure a valid decision within the same processing context

Installation start date as a separate review step

The installation start date is maintained in the SharePoint record, and a link in the approval leads directly to the item. After the installation decision, the flow reads the current value from SharePoint again instead of relying on data captured at the start of the run. Order management reviews the date in a separate step and can reject just the date without rejecting the entire order.

  • Without a start date, the record does not move on to order management
  • A follow-up loop checks again every ten minutes, with a one-time reminder email and a time limit below the 30-day run duration of a flow
  • If the date is rejected, it is cleared, and the case is returned to installation with a reason.

Project numbers and a process that depends on the product type

For the selected product type, the start flow determines exactly one active project number rule and generates the next project number from prefix, format, and sequential number. The same rule also specifies whether the engineering review is skipped for this product type.

  • 14 product types configured, 5 of them without engineering review
  • Required field check of the input data with collected validation errors
  • Controlled error path for a missing or ambiguous rule

Centralized HTML email delivery

All notifications go through a dedicated sending flow with a fixed input schema. It generates consistent HTML emails with a status color, order data, comment, and record link, and immediately acknowledges receipt with HTTP 200.

  • Five message types: completion, rejection following review, blocking, configuration error, and escalation
  • Recipients of completion notices taken from the role list, with empty entries removed and duplicate addresses merged
  • Date values consistently in German format and local time
  • Retry policy turned off for calls that only send email so that no duplicate messages are sent

Escalation and error handling

A scheduled flow checks all open current approvals Monday to Friday at 8 a.m., looks up the matching escalation rule for the step and role, and escalates once after five working days without a decision. Each flow is structured into scopes following the pattern of processing and error handling.

  • Due date that takes weekends into account
  • The escalation is recorded on the approval and the order and logged in the audit trail
  • The error scope evaluates failed actions, sets the order status, and sends a notification with a link to the run
  • Check for exactly one role or exactly one current approval before each step

Design for a second phase with a canvas app

The tests showed that starting via flow variables is not sufficient for everyday use. For the next stage, I therefore created a functional design with a statement of work. This stage has not yet been implemented.

  • Shared canvas app for order management, service, and installation with an overview, search, filters, and a start action
  • Second process variant for service orders without installation
  • Resumption with its own run identifier and protection against late responses to old tasks
  • Reminders, two escalation levels, and time-limited delegation per role
  • Optional analysis of an ERP integration with field mapping and the system of record for each field

03In detail

Apps, processes, and data at a glance.

Names and content are described in neutral terms - I never name clients.

Cloud flows9

  • Start and project number assignmentTrigger: manual (button)Receives the input data, checks required fields, assigns the project number by product type, creates the order, approval, and log, and starts engineering or installation.
  • Engineering approvalTrigger: HTTP requestApproval by engineering with a mandatory reason for rejection, then handover to installation or return to order management.
  • Installation approvalTrigger: HTTP requestApproval by installation, a follow-up loop to re-read and check the installation start date, and handover to order management.
  • Order management reviewTrigger: HTTP requestThe largest flow with more than 200 actions and five approvals: regular review, a separate date review, and orders sent back from engineering, installation, and purchasing.
  • Purchasing approvalTrigger: HTTP requestPurchasing approval, handover to the cross-check if approved, return to order management if rejected.
  • Purchasing cross-checkTrigger: HTTP requestSecond purchasing decision; if approved, the record is completed and a completion email is sent to the configured roles.
  • Centralized email deliveryTrigger: HTTP requestValidates the payload, generates HTML emails for all message types, and immediately acknowledges receipt.
  • Test email deliveryTrigger: manual (button)Sends a test request to the central email delivery flow.
  • Escalation of pending approvalsTrigger: schedule (Mon-Fri 8:00 a.m.)Checks pending approvals against the escalation rules and escalates once after five working days.

Data model8

  • OrdersSharePoint listRecord with input data, current step, role, status per department, installation start date, and error state
  • ApprovalsSharePoint listOne record per approval step with assignment, decision, comment, due date, and escalation status
  • Audit trailSharePoint listEvent log with status changes, reasons, and correlation ID
  • RolesSharePoint listAssignees or groups per role and a flag for the completion notice
  • Escalation rulesSharePoint listMapping of step and role to escalation level and recipients
  • Email templatesSharePoint listSubject and body templates with placeholders per message type
  • SettingsSharePoint listPlanned central configuration values
  • Project number rulesSharePoint listPrefix, format, and sequential number per product type, plus a flag for skipping engineering

Integrations4

  • Internal HTTP calls with a JSON schema between the flows
  • Power Automate approvals for all approval decisions
  • SharePoint Online via the standard connector with OData filters
  • Office 365 Outlook for notifications

04Tricky parts

Challenges and how I solved them.

Mandatory reason for standard approvals

Power Automate approvals do not enforce a comment for rejections. I check the outcome and the comment with an expression and request the decision again if the reason is missing. In order management, this happens in Do until loops so that no additional approval record is created by a new flow call.

Date rejection separate from order rejection

Instead of guessing from free text whether only the installation date or the entire order is being rejected, I built the date review as a separate approval. If the date is rejected, it is cleared, and the case is returned to installation with a reason.

Missing required data after a decision

An installation approval without a start date initially just blocked the record. Later, I added a limited follow-up loop: the flow re-reads the order every ten minutes, sends a one-time reminder, and continues as soon as the date has been entered.

Root cause of HTTP 502 errors

In tests, errors appeared in several department flows, all of which were traced back to the call to the central email flow. I separated the functional status, sending, and response behavior, changed sending to an immediate response with HTTP 200, corrected an incorrect check for an empty value applied to a number, and turned off retries for email calls.

SharePoint choice values in JSON

In the escalation, a choice field arrived as an object instead of text and produced invalid JSON. The expressions now explicitly handle both return formats.

Unambiguous configuration

Before each step, the flows check that exactly one matching role, rule, or current approval exists. Missing or duplicate entries end up in a controlled error path with a log entry and a notification.

05Approach

Step by step to the result.

  1. 1

    Requirements clarification and contract (05-06/2026)

    I gathered the requirements, defined the pilot scope to exclude SQL integration, forms, and rollout, and established the contractual basis. This was accompanied by supplier onboarding for the group of companies with an information security questionnaire.

  2. 2

    Data model (07/2026)

    I described the eight SharePoint lists with columns, indexes, views, and initial values in a workbook and created them in the client's environment.

  3. 3

    Implementation of the flows (07-08/2026)

    Based on my template for processing and error handling, the start flow and department flows were created first; the central email sending flow and the test flow followed in August. I exported and backed up each version as a solution.

  4. 4

    Functional tests and corrections (07-09/2026)

    The business department ran through the processes with test records. I incorporated feedback on return paths, date review, date format, and notifications in small change packages. In September, I provided the solution for a joint functional review and exported it as a managed solution.

  5. 5

    Design for phase 2 (09/2026)

    Based on the test experience, I created a functional design with work packages for a canvas app, a service process, resumptions, delegations, and ERP preparation.

06Result

What works differently today.

  • The base system covers the complete approval path from entry to completion, including all agreed paths for returning orders for revision and an automatic completion email.
  • In test operation, 20 test records were created, 7 of which passed through all stages to completion. The audit trail contains 178 logged events for them.
  • Roles, escalation rules, email recipients, and project numbers can be maintained in SharePoint without changing the flows.
  • The solution is available as a versioned solution and is the foundation for a later app interface and ERP integration.

Technologies

  • Microsoft Power Automate (cloud flows)
  • Power Automate Approvals
  • Microsoft SharePoint Online (lists)
  • Office 365 Outlook
  • Power Platform solutions (managed and unmanaged)
  • HTTP triggers and JSON-based integrations between flows
  • HTML email templates

Demonstrated skills

  • Designing and implementing multi-stage approval processes with Power Automate approvals
  • Modular flow architectures with HTTP triggers and JSON schemas
  • SharePoint data models for records, decisions, log, and configuration
  • Error handling with scopes, result evaluation, and controlled error paths
  • Scheduled escalation with working day logic
  • Error analysis at the boundary between the SharePoint connector, the expression language, and HTTP
  • Solution management with unmanaged and managed exports
  • Functional designs and scope definition for follow-up stages with a canvas app and ERP integration

07Questions and answers

Frequently asked questions

Can you require a reason for a rejection in Power Automate approvals?
Not directly in the standard approval. However, after the decision, the flow can check whether a comment was entered for a rejection and otherwise send the approval again. With a Do until loop, this stays within the same flow run and does not create additional records.
Why several flows instead of one large approval flow?
Separate flows per department remain manageable, can be tested and corrected individually, and keep each run shorter. They pass defined data via HTTP triggers with a fixed JSON schema, and a shared sending flow avoids duplicate email logic.
What should you consider with long waiting times in Power Automate?
A cloud flow can run for at most 30 days. Waiting loops and approvals should therefore have their own shorter time limits. Pending states should be stored in the data source so that a process can be resumed in a controlled way or restarted after the run expires.
Is SharePoint sufficient as the data source for an approval process?
For a pilot or a base system with a manageable volume, yes, if records, decisions, and the log are kept in separate, indexed lists. For a later ERP or SQL integration, internal column names and keys should be planned to remain stable from the start.

08More case studies

More projects in detail.

Specialist retailer of fireplaces and stoves with delivery and installationsince 02/2022 Order processing for a stove retailer with Power Apps and SharePoint For almost five years, I developed the central order processing system for a fireplace and stove retailer with several companies and locations, based on SharePoint, Power Automate, and Power Apps, and I still support it today. Quotes with digital signatures, invoices and payment reminders via sevDesk, Planner tasks, customer surveys with Forms, Power BI, and a mobile installation report on tablets all work together. The solution gave rise to the industry platform FLAMOX365. more than 50 employees SharePoint Online (lists and libraries)Power Automate (cloud flows)Power Automate approvalsPower Apps (canvas apps)Forms (customer surveys) Read case study Energy and cable industry12/2025 - 09/2026 SharePoint migration, Power Apps, and Azure in the cable industry For an international group in the energy and cable industry, I supported the migration of SharePoint and Power Platform applications. I developed the security and Azure architecture concept for a QHSE application and rebuilt three Power Apps for hazardous substance management, replacing an on-premises SharePoint solution with Nintex workflows. more than 10,000 employees Power Automate (cloud flows)Power Apps (canvas apps)SharePoint OnlineOn-premises SharePoint (source system)SharePoint REST API Read case study Metalworking - precision turned and milled partssince 11/2025 Digital quality inspection with Power Apps in precision machining For a manufacturer of precision turned and milled parts, I designed and implemented a responsive canvas app for quality inspections in production. It determines which inspection characteristics are due for each machine, part, and inspection trigger, evaluates measured values against tolerances, and stores the results in an auditable form in SharePoint, with versioning and restricted editing rights. In addition, I advise on migrating an existing production app that has evolved over time into separate environments. more than 100 employees Power Automate (cloud flows)Power Apps (canvas app, responsive design)SharePoint OnlineAzure SQLEntra ID and Microsoft 365 groups Read case study

A similar project? Let's talk.

Tell me where things get stuck today - in a free, no-obligation initial consultation via Microsoft Teams, we will clarify what the Power Platform can do for your process and what a sensible first step looks like.

Book a free initial consultation Send an inquiry +49 160 125 01 75