For citizen-built apps nobody in IT ever signed off on
Power Platform
Power Platform earns its reputation twice. It lets a team ship a working app in a week, then lets two hundred of those apps pile up with no owner and no environment strategy. This practice builds the apps and automations that justify the platform, and the governance layer that keeps them from becoming the next audit finding.
How Power Platform governance gets designed here
Canvas versus model-driven, ALM strategy, and the guardrails that hold as apps multiply.
90 secSample frame · video pending01Before the first screen gets designed
Canvas or model-driven is a real decision.
The app type gets chosen by whichever tutorial the builder watched last far too often. Four questions settle it against your actual data and users.
Is the data already structured in Dataverse?
A model-driven app generates its interface from a Dataverse schema and suits structured, relational data well. A canvas app fits data spread across several disconnected sources instead.
How much control does the layout need?
Canvas apps give pixel-level control over every screen, useful for a specific, opinionated workflow. Model-driven apps trade that control for a consistent, faster-to-build interface.
How many entities does the app manage?
A handful of related entities suit a model-driven app's built-in views and forms well. A single-purpose task often needs only the screens a canvas app provides.
Who else needs to build on this later?
Model-driven apps inherit Dataverse's security and extensibility model automatically. A canvas app needs that governance layered on deliberately if others will extend it later.
| Canvas app | Model-driven app | |
|---|---|---|
| Data source | Any connected source | Dataverse |
| Layout control | Full, pixel-level | Generated from the schema |
| Best fit | A specific, focused workflow | Managing structured, related entities |
| Built-in governance | Layered on deliberately | Inherited from Dataverse |
02Agreed before the first app ships
The ledger that keeps a Power Platform build honest
Power Platform engagements slip when governance gets treated as a policy to write later instead of a decision made up front. This ledger fixes what you bring, what we build or govern, what returns to you, and what your team keeps control of throughout.
- Your side
You bring
- The exact process the app or flow needs to replace
- Who uses it and how often
- Any data it needs to read from or write to
- Our side
We build
- A Power Apps build or Power Automate flow scoped to that process
- A Dataverse data model if the process needs structured storage
- Testing against the real people who will use it daily
- Your side
You receive
- A working app or automation in production
- Documentation of the data model and its logic
- A clear owner assigned inside your team
Never leaves you
- The decision on how the process itself should work
- Ownership of the app once it ships
- Authority over what gets automated next
Where the line sitsWe build the app around your process; you keep the judgment on whether that process still makes sense.
03From process map to a governed release
Four stages, each closing on real evidence
Apps that sprawl unmanaged usually skipped a stage here rather than a step inside one. This system closes each stage with something an IT owner can actually verify.
Map the process, then choose the app
The actual task gets documented before deciding between a canvas app, a model-driven app or a Power Automate flow. The app type follows the process, never the other way round.
The workflow before the app typeModel the data in Dataverse deliberately
Entities and relationships get designed for where the app is going, not just what it needs on day one. A schema built this way survives the app's second and third version.
A schema that will not need rebuildingSet up ALM and environment strategy
Development, test and production environments get established with a managed pipeline between them before wide building starts. Nobody tests a change directly against live business data here.
Environments separated before anyone buildsGovern what already exists, then what's new
Existing apps and flows get catalogued, given an owner and reviewed for what they touch. New builds enter under the same governance from their very first version.
Every app owned, every flow reviewed
04What actually moves the number
Four drivers, priced from the assessment
Power Platform work is priced against the scoping assessment, because these four factors change effort by multiples once real usage is accounted for.
Number of apps and flows in scope
A single new app costs far less than an audit and governance rebuild across two hundred apps nobody has reviewed.
Dataverse modelling complexity
A handful of related entities model quickly. A schema covering dozens of interconnected business objects takes meaningfully longer to design well.
ALM and environment maturity
Teams with no environment separation need that foundation built first, which adds real effort before any new app gets started.
Governance and citizen-developer scope
Governing one department's apps is simpler than establishing rules that hold across every business unit building on the platform.
05Evidence and proof
An estate of apps with an owner for every one.
Power Platform proof is a governed inventory, not a slide claiming sprawl is under control. Every record here waits for written client approval before production.
Explore case studiesTwo hundred ungoverned apps reduced to one owned register.
Pillar Learning had over two hundred Power Apps and flows built by different teams with no owner and no review. An assessment catalogued every one, assigned real owners, and retired what nobody could justify keeping.
- Apps and flows catalogued
- 214
- Retired with no owner found
- 38
A manual approval process replaced by a governed Power Automate flow.
Aster North routed purchase approvals through email threads that regularly lost track of who had signed off. A Power Apps form and Power Automate flow gave every approval a visible, auditable owner.
- Approval steps tracked automatically
- All of them
- Average approval time
- Cut by more than half
We finally know which app touches which data, and who is responsible for each one.
Sample · pending client approval
06Read this first
When Power Platform is the wrong answer
Building a low-code app for a process that needs enterprise-grade compliance controls is a mismatch dressed up as speed. The exits below are marked plainly.
- Software architecture
The process needs regulated, audited transaction handling
Financial or compliance-critical processes with strict audit trails often need a purpose-built system rather than a low-code app.
The requirement changes shape weekly
Building an app around a process still being redesigned means rebuilding the app again shortly after. Stabilise the process first.
- Team extension
You need Power Platform developers, not a delivery team
If your team already owns the platform roadmap and needs capacity, team extension fits better than a commissioned build.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | App or flow scope is known | Access decisions and priorities | Build and delivery |
| Delivery pod | Requirements will evolve across apps | Product decisions each cycle | Engineering and governance |
| Team extension | Your leads own the platform roadmap | Architecture and standards | Named developers and continuity |
07Straight answers
Asked before a Power Platform budget is signed off.
01Do you build Power Apps, Power Automate flows, or both?
Both, usually together. Most real processes need an app for input and a flow for what happens after submission, so they get scoped and built as one connected piece of work.
02Should we build a canvas app or a model-driven app?
Whichever your data and users actually need, decided against those four questions. Structured, related data in Dataverse usually points toward a model-driven app.
03Can you fix the sprawl of apps our teams already built themselves?
Yes, and that is one of the most requested engagements here. The assessment catalogues what exists, assigns real owners, and proposes guardrails before anyone builds anything new.
04What is ALM and why does our Power Platform setup need it?
Application lifecycle management: separate environments and a managed pipeline for moving changes between them safely. Without it, changes get tested directly against live business data, which eventually breaks something important.
05What does Power Platform consulting cost?
Priced against app count, Dataverse complexity and governance scope, from the scoping assessment. A single new app costs far less than an estate-wide governance rebuild.
06Can you integrate Power Platform with Dynamics 365 or SharePoint?
Yes, Dataverse and Power Automate connect naturally to both, and that integration is one of the more common reasons teams reach for Power Platform in the first place.
07Will governance slow down teams that are already building quickly?
Done well, it should not. Good guardrails let teams keep shipping while someone can answer for what a flow touches, rather than adding approval steps for their own sake.
08Is this a staffing arrangement or a delivery engagement?
It is delivery and governance work, not a placement. Our team builds the app, sets up the pipeline, or governs the sprawl, and you receive a finished outcome rather than a resume.