Power Platform Procurement System for a Global Food Retailer

Anonymised engagement

Client: Food retail group · Netherlands · one of the world's largest food retailers, centres worldwide
Industry: Retail & E-commerce
Department: Procurement
Region: Netherlands · Benelux

An occasional requester on a premium licence is a cost that grows with headcount, not with value. One of the world's largest food retailers ran procurement on a Power App that had outgrown its design. We extended it into the one system all procurement in scope went through, with an approval chain, segregation of duties, a licensing design that kept costs down and Power BI reporting for every level of management.

A working model of the approach on sample data. It plays on its own and pauses when scrolled away; nothing here touches a live system.

Procurement · two doors, one chain

Standard M365

Purchase request

Category: IT hardware
Amount: €3,850
Centre: EU-North
Cost centre: CC-4120

Submit

occasional requesters

Premium

Active purchase requests

Request ID	Centre	Amount	Stage
PR-2026-0432	US-East	$18,400	Escalated
PR-2026-0435	EU-North	€12,300	Approved
PR-2026-0433	EU-South	€920	In approval
PR-2026-0434	APAC	€5,600	Submitted

procurement team

Power Automate · one approval chain

Line managerCategory managerFinance controllerOutcome

PO-78104

Escalated

Approver is the requester · blocked0432 · over the budget line

Power BI · management reporting

QuarterlyHalf-yearAnnualGroupRegionCentre

Goods

Services

IT hardware

Other

Row-level security · Region

Quarterly, half-year and annual reports; each level sees its own view.

The results

1
system for all procurement in scope: Request, approval chain, record and reporting in one platform. Scope figure, not a saving.; 2
routes in, licensed by type of user: Forms and flows for occasional requesters, the Dataverse app for the procurement team. Licence savings were not measured.; 3
reporting cadences for top management: Quarterly, half-year and annual Power BI reports with role-level security. Scope figure.

The challenge

Our client is one of the world's largest food retail groups, headquartered in the Netherlands, with centres around the world. Procurement requests across the group ran through a model-driven Power App on Microsoft Dataverse. It worked, but it had outgrown its design.

Two very different groups used it. The procurement team works in the system every day. Staff across the business submit a request only now and then. Both were on the same model-driven app, and both needed the same premium licence to use it.

What it was costing them

A licence bill that grew with headcount. A model-driven app on Dataverse needs a premium licence per user. With a large population of occasional requesters, cost scaled with the number of people, not with the value they got from the system.
Global, but not centralised. Centres around the world needed to work in one operating model, which the existing set-up did not support.
Approvals without enforced controls. Procurement without an enforced approval chain and segregation of duties is a control weakness.
No management view. Leadership needed quarterly, half-year and annual procurement reporting, cut to what each level of the organisation is allowed to see, and nobody could produce it cleanly.

Two kinds of user, two ways in

Both needed the same premium licence; occasional users now go through forms and flows.

The approach

We extended the existing platform on the Microsoft cloud into the single system all procurement in scope went through: request, approval chain, record and reporting. The procurement team kept a richer model-driven app; everyone else got a lighter route in.

What we built

One procurement system. Staff request the products and services they need through the platform, and every request follows the same approval chain.
The model-driven app, extended. We upgraded the existing model-driven Power App on Dataverse with additional functionality for the people who manage procurement.
A licensing-aware front door. Requesters use custom forms backed by Power Automate flows, with part of the data held in SharePoint, so occasional users do not need premium Dataverse licences. Dataverse stays for the core records and the people who manage them.
Approval chain with segregation of duties. Power Automate routes each request through defined approvers, and no one approves their own request.
Multi-tenant architecture. Centres around the world run on one centralised model while keeping their own operations.
Management reporting. Power BI reports on procurement at quarterly, half-year and annual cadence for top management, with role-level security and access controls so each level of the organisation sees its own view.

Two routes into one procurement system

Licensing and security, designed together

Which users touch Dataverse and which go through SharePoint forms and flows was decided up front, together with the security model. That boundary is exactly where segregation of duties tends to break, so it was designed to hold in both places: in the approval chain and in who sees which reports.

Technology

Layer	What we used
Core application	Power Apps model-driven app on Microsoft Dataverse
Requester intake	Power Apps custom forms, SharePoint Online
Approvals and request flows	Power Automate
Reporting	Power BI with role-level security
Identity and access	Microsoft 365, Azure AD access control

The outcome

All procurement in scope now runs through one system, with one approval chain and one reporting model for centres worldwide.

	Before	After
Where procurement requests go	A model-driven app that had outgrown its design	One system for all procurement in scope
Licence for an occasional requester	Premium Dataverse licence per user	SharePoint forms and Power Automate flows
Approvals	Not enforced by the system	Defined approval chain, no self-approval
Centres worldwide	No common operating model	One centralised, multi-tenant model
Management reporting	Nobody could produce it cleanly	Quarterly, half-year and annual Power BI reports by organisational level

All procurement in scope through one streamlined system with an approval chain.
Segregation of duties in approvals and in reporting access.
Licence costs optimised across the Microsoft products by routing occasional users through SharePoint and Power Automate, so premium Dataverse licences go to the people who need the full app.
Management reporting at quarterly, half-year and annual cadence, by organisational level.
Positive feedback from the client.
Scope, not savings. Time and licence savings were not measured; the figures on this page describe what was built.

The risk most teams miss

Power Platform projects are usually designed for function and discovered to be expensive later. A model-driven app on Dataverse is the right tool for the procurement team and the wrong licence for someone who submits a request twice a year. Deciding up front which users touch Dataverse and which go through forms and flows is what keeps a global rollout affordable, and it has to be designed together with the security model, or segregation of duties breaks at the boundary.

Built with

The tools this ran on, by the layer each one carried.

Next step

Start the same conversation

Tell us the process that keeps breaking. We will come back with what it would take to fix it, what it would cost, and what we would measure.

Book a working session See ways to start

Or write to us directly: •••••@•••••••.•••

A reply from a partner within one business day
Fixed scope and fixed fee, agreed before we start
The maps and the backlog are yours either way