Dutch-headquartered food retail group · one of the biggest globally · centres worldwide
Procurement on Power Platform for a Global Food Retail Group
A premium licence for someone who files the odd request is a cost tied to headcount, not value. A food retailer ranked among the largest in the world handled procurement in a Power App that had grown past its original design. We turned it into the single system for every procurement request in scope, It now carries an approval chain and segregation of duties, uses licences in a way that holds costs down, and feeds Power BI reports to each level of management.

- Industry
- Retail & E-commerce
- Function
- Procurement
- Region
- Netherlands
Results
- 1
- single system covering all in-scope procurement
- Request, approvals, record and reporting together. This counts scope, not savings.
- 2
- ways in, licensed according to user type
- Occasional requesters use forms and flows; the procurement team uses the Dataverse app. Licence savings not measured.
- 3
- reporting cycles for top management
- Power BI reports every quarter, half-year and year, with role-level security. A scope figure.
01
The challenge
The client ranks among the largest food retail groups in the world. It is headquartered in the Netherlands and runs centres around the globe. Group-wide, procurement requests went through a model-driven Power App built on Microsoft Dataverse. The app did its job, but it had grown past what it was designed for.
Its users fell into two very different groups. The procurement team lives in the system every day. Everyone else in the business raises a request only occasionally. Yet both sat in the same model-driven app, and both required the same premium licence.
The cost of the old set-up
- Licence spend tied to headcount. Dataverse charges a premium licence for every person using a model-driven app. With many people who only request things occasionally, the bill followed the number of users rather than the value each of them got.
- Worldwide, yet not centralised. Centres across the globe had to work to a single operating model, and the existing set-up could not provide one.
- Controls not enforced. Procurement with no enforced approval chain and no segregation of duties is a weak point in control.
- Management had no clear view. Leaders wanted procurement reports every quarter, half-year and year, filtered to what each level of the organisation may see. No one could produce them cleanly.
02
What we did
On the Microsoft cloud, we extended the existing platform until it became the one system every procurement request in scope passed through, from the request and its approvals to the record and the reports. The procurement team got a fuller model-driven app, and everybody else a simpler entrance.
What we delivered
- A single procurement system. Employees use the platform to ask for whatever products and services they need. Every request goes through the same approval chain.
- A richer model-driven app. For the people who run procurement, we added functionality to the Power App they already had, the model-driven one on Dataverse.
- An entry point shaped by licensing. Requesters work in custom forms driven by Power Automate flows, and part of the data lives in SharePoint. That way occasional users need no premium Dataverse licence. Dataverse remains the home of the core records and of the people who manage them.
- Approvals with segregation of duties. Power Automate sends each request to its defined approvers. Nobody can approve a request they raised.
- Multi-tenant architecture. Centres worldwide share one centralised model and still run their own operations.
- Reporting for management. Top management gets Power BI procurement reports every quarter, half-year and year. Role-level security and access controls give each level of the organisation its own view.
Licensing and security as one design
We decided early which users work in Dataverse and which use SharePoint forms and flows, and we decided it alongside the security model. Segregation of duties usually fails at exactly that boundary. So we made sure it holds on both sides: in the approval chain and in who can see which reports.
Stack
| Layer | Tools |
|---|---|
| Core app | Model-driven Power Apps on Microsoft Dataverse |
| Request intake | SharePoint Online, custom Power Apps forms |
| Request routing and approvals | Power Automate |
| Reporting | Power BI, role-level security |
| Identity and access | Azure AD access control, Microsoft 365 |
03
The outcome
Every procurement request in scope now goes through a single system. Centres worldwide share one approval chain and one reporting model.
| Before | After | |
|---|---|---|
| Destination of procurement requests | A model-driven app stretched past its design | A single system for everything in scope |
| Occasional requester's licence | A premium Dataverse licence for each user | Power Automate flows and SharePoint forms |
| Approvals | No enforcement by the system | A defined approval chain, self-approval blocked |
| Centres worldwide | No shared operating model | A single multi-tenant, centralised model |
| Reporting for management | Could not be produced cleanly | Power BI reports per organisational level, every quarter, half-year and year |
- One streamlined system with an approval chain for all procurement in scope.
- Segregation of duties applied to approvals and to report access.
- Lower licence costs across Microsoft products. Occasional users go through SharePoint and Power Automate, and premium Dataverse licences are kept for people who need the full app.
- Reports for management every quarter, half-year and year, split by organisational level.
- The client gave positive feedback.
- This page describes scope, not savings. We did not measure time or licence savings. The figures here describe what was built.
A risk that often goes unnoticed
Power Platform projects tend to be designed around function, and the cost only becomes clear later. A model-driven app on Dataverse suits the procurement team well, but it is the wrong licence for a person who files two requests a year. Choosing early which users go into Dataverse and which use forms and flows keeps a global rollout affordable. That choice must be made together with the security model. Otherwise segregation of duties breaks where the two meet.
Built with
The platforms and tools this engagement runs on.
More case studies
Similar problems, measured the same way.

Investment group, Europe · €150M IFC sustainability-linked loan carrying ESG covenants
ESG Covenant Compliance Platform
- IFC facility protected by the platform
- €150M
- IFC facility protected by the platform
- scanned documents, now one task register
- 70
- scanned documents, now one task register

Chartered accountancy practice · London · works with high-net-worth clients
Secure Client Onboarding on Dataverse for a UK Accountancy Firm
- secure portal covering details, ID and chat
- 1
- secure portal covering details, ID and chat
- client details typed again by staff
- 0
- client details typed again by staff

Global pharmaceutical company · among the largest worldwide · used from the CEO downwards
Offline-Ready Investor Relations App for a Global Pharma Company
- slides turned into structured data
- ~350
- slides turned into structured data
- platforms, connected or offline
- 5
- platforms, connected or offline




