Power Platform: The Questions That Keep Coming Back

Power Platform programmes tend to hit the same set of questions at roughly the same point: usually a few months in, when the first application has succeeded and a second team wants one. These are those questions, with the reasoning that makes the answers portable.

Choosing what to build

Canvas or model-driven?

Ask what will change most often. A canvas app starts from a screen you design; a model-driven app is generated from a Dataverse schema. If the thing that changes most is the data model, the relationships and who may see which rows, choose model-driven and let the platform generate the interface. If the thing that changes most is the screen — its layout, its interaction, its branding — choose canvas and accept that you own the data-access rules.

The security model usually settles it. Requirements phrased as "managers see only their team's records" describe the Dataverse security model. Reimplementing that inside a canvas app is possible and rarely wise.

Power Automate or Logic Apps?

Ask who gets the call when it breaks. If a business team should be able to fix it themselves, Power Automate. If an engineering team owns it, needs it in source control, needs alerting and needs it to run regardless of who is employed, Logic Apps.

Dataverse or SharePoint lists?

On capability, not on cost. Dataverse gives you a real relational model, row-level security, server-side business logic, transactions and auditing. SharePoint lists give you a list with columns and a permission model that was designed for documents. If the requirement mentions relationships, row-level access or referential integrity, that is Dataverse describing itself.

Environments

How many environments do we need?

At minimum three for anything that matters: development, test and production, with solutions moving between them. Add a sandbox for experiments so that development does not double as a scratch pad.

The default environment deserves specific attention. Everyone can create in it, it cannot be deleted, and it accumulates. Treat it as a personal-productivity space and put nothing operational there — the fastest governance improvement most tenants can make.

Who should be able to create environments?

Restrict it. Uncontrolled environment creation produces a tenant nobody can inventory, with data in places nobody knows about. Restricting creation and providing a fast request route works far better than either extreme.

Solutions and ALM

Do I really need a solution for a small app?

Yes, and this is the answer most often ignored to later regret. Components created outside a solution are painful to package afterwards, and "small" apps become important apps with startling regularity. Create a publisher and a solution before the first table.

Managed or unmanaged?

Unmanaged in development, managed everywhere else. Managed solutions can be uninstalled cleanly and prevent direct edits in the target environment. Editing directly in production is precisely the habit that makes an application impossible to deploy repeatably.

What are connection references and environment variables for?

They are what make a solution portable. A connection reference separates a flow's logic from the specific connection it uses, so the same solution can be imported into test and production with different credentials. An environment variable does the same for configuration values — a site URL, an email address, an identifier. Without both, every deployment involves editing components by hand in the target environment.

Connectors and licensing

What makes a connector premium?

Licensing, not capability. Premium connectors require a Power Apps or Power Automate licence beyond what a Microsoft 365 subscription includes. The set is defined by Microsoft and does change, so verify the current list against your intended design.

The trap to know about: a custom connector to your own API is premium, and so is the Dataverse connector when used outside its licensed contexts. Discovering that at go-live is expensive.

Can I avoid premium licensing by using an HTTP call?

The HTTP action is itself premium. Attempts to route around licensing through indirection usually fail, and the ones that work tend to breach the terms rather than the technology. Design against the licence you intend to buy.

Governance

What does a DLP policy actually stop?

It stops connectors in different data groups being used in the same app or flow. It is a combination control, not a per-connector switch: business and non-business are labels whose only effect is that connectors from the two groups cannot be mixed.

Two consequences people miss. Policies apply at environment scope, so a permissive default environment undermines a strict production policy. And an existing app that violates a new policy stops working — announce changes before making them.

What happens when the person who built a flow leaves?

If it is a personal flow with personal connections, it stops when their account is disabled. This is the most common preventable Power Platform incident.

The fix is structural: important automation lives in a solution, uses connection references bound to a service principal or a service account, and has more than one owner. Ownership is a governance decision, not a technical one, and it has to be made before the person leaves.

How do we know what exists in the tenant?

The Center of Excellence starter kit is the usual answer — it inventories apps, flows, environments and makers, and surfaces what is orphaned or unused. Whatever the tool, the requirement is real: you cannot govern an estate you cannot list.

Common mistakes

• Building in the default environment. No lifecycle, no boundary, permanent.
• Skipping solutions early. Retrofitting is far more work than starting inside one.
• Editing directly in production. The application becomes impossible to redeploy.
• Personal connections on business-critical flows. A resignation becomes an outage.
• Discovering premium licensing at the end. It can invalidate a design.
• DLP policies imposed without warning. Working apps break; goodwill goes with them.

Frequently asked questions

Can a canvas app be embedded in a model-driven app?

Yes, via a custom page. That is the right answer when one step of a data-shaped process genuinely needs a designed screen.

How do we handle source control?

Export the solution unpacked into a repository and build the deployment package from source. Pipelines and the platform's own ALM tooling both support this, and it turns a solution into a reviewable artefact.

Do makers need to be developers?

No, and expecting it defeats the point. What they need is a governed place to build, a clear boundary between personal productivity and production, and a route to hand something over when it outgrows them.

Where do current licensing details live?

The Microsoft licensing documentation. Any figure quoted in an article — this one included — has a short shelf life, and licensing questions are exactly the ones where being a year out of date is expensive.

The pattern

Nearly every question here resolves to the same principle: decide ownership and lifecycle before capability. Which environment, inside which solution, owned by whom, deployed how. Programmes that answer those four questions early spend their time building; the ones that do not spend it untangling.