KT Sparks

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.

Procurement on Power Platform for a Global Food Retail Group
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

  1. 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.
  2. 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.
  3. 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.
  4. Approvals with segregation of duties. Power Automate sends each request to its defined approvers. Nobody can approve a request they raised.
  5. Multi-tenant architecture. Centres worldwide share one centralised model and still run their own operations.
  6. 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

LayerTools
Core appModel-driven Power Apps on Microsoft Dataverse
Request intakeSharePoint Online, custom Power Apps forms
Request routing and approvalsPower Automate
ReportingPower BI, role-level security
Identity and accessAzure 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.

BeforeAfter
Destination of procurement requestsA model-driven app stretched past its designA single system for everything in scope
Occasional requester's licenceA premium Dataverse licence for each userPower Automate flows and SharePoint forms
ApprovalsNo enforcement by the systemA defined approval chain, self-approval blocked
Centres worldwideNo shared operating modelA single multi-tenant, centralised model
Reporting for managementCould not be produced cleanlyPower 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.