Power Platform automation

The problem

A platform team of three serving 7,000 employees cannot hand-build every departmental request, and most of those requests are not development work. They are the same shapes repeating: notify this group when a document lands in that library, create a page from a template with the right metadata and permissions, roll a weekly report up from a list, chase an overdue task. Written as code, each one is a release, a deployment and a maintainer.

What I did

I built the layer below custom development: flows for onboarding at a group company, quality-document notifications across two plants, a data-protection register with a consistency checker, Planner rollups, newsletter conversion and more, from a one-action utility to a 146-action onboarding workflow. About a third are called by a Power App or over HTTP, so the flow is the server side of an application rather than a background notification.

For the legal knowledge base I built three Power Apps and their back-end flows, which let the legal team create a section, a page, a library and its permissions without a developer. Those flows mostly do not use the drag-and-drop connector at all: 100 of 105 connector calls are hand-written SharePoint REST requests, because the standard connector cannot set the fields the department required.

A decision and its cost

Flows rather than code for this layer, because a flow is owned where it runs: a site owner can read it, and the platform team can hand it over. An Azure Function doing the same job is a deployment, a secret, a monitor and a maintainer; that is a fair trade for complex logic and a bad one for "mail this group when a file lands". The 146-action onboarding flow is the honest edge of that argument, where the trade starts going the other way.

The raw REST calls carry their own cost: they are the part most likely to break on an API change, and the part a colleague finds hardest to pick up.