Microsoft Power Apps: The Complete Guide to Building, Sharing, and Governing Business Applications

Microsoft Power Apps has become the default low-code platform for organizations already invested in the Microsoft 365 ecosystem. But the gap between “we built a simple form” and “we have a governed application portfolio” is enormous — and it’s where most organizations stall out. This guide covers the platform end to end: what Power Apps actually is, how the different app types work, how sharing and external access function at a technical level, where governance becomes non-negotiable, and the licensing and architecture decisions that separate successful deployments from expensive experiments.

What Microsoft Power Apps Actually Is (And What It Isn’t)

Microsoft Power Apps is a low-code application development platform within the broader Microsoft Power Platform (which also includes Power Automate, Power BI, and Power Virtual Agents). It allows users — ranging from business analysts to professional developers — to build custom applications that connect to data sources across Microsoft’s ecosystem and beyond.

What it isn’t: a replacement for custom software development. Power Apps handles a specific band of application complexity well. Internal data capture forms, approval workflows, field inspection tools, inventory trackers, and customer-facing portals with structured data — these are its sweet spots. If you need heavy computation, complex real-time integrations, or pixel-perfect consumer-grade UIs, you’ll outgrow Power Apps quickly or spend more time fighting it than building in it.

The platform ships in three primary flavors:

• Canvas apps give you a blank screen and full control over layout. You drag and drop controls, write formulas in Power Fx (a language derived from Excel), and connect to hundreds of data sources. Think of these as custom front-ends for your data.
• Model-driven apps start with your data model in Microsoft Dataverse and auto-generate the UI. They’re better suited for complex business processes with relationships between entities — case management, CRM-like workflows, or anything where the data structure drives the experience.
• Power Pages (formerly Power Apps Portals) extend your Dataverse data to external, authenticated or anonymous users through web portals. This is how organizations expose self-service experiences to customers, vendors, or partners.

Understanding which app type fits which scenario is the first real architectural decision, and getting it wrong creates rework that compounds over months.

Canvas Apps vs. Model-Driven Apps: Making the Right Architectural Choice

The canvas-vs-model-driven decision isn’t about which is “better.” It’s about where complexity lives in your application.

Canvas apps excel when the user experience is the primary concern. If you need a mobile-first field inspection app where technicians tap through a specific sequence of screens, canvas is the right call. You control every pixel. The tradeoff: you also own every pixel. As apps grow, canvas formulas can become unwieldy, and performance degrades when data volumes increase without careful delegation patterns.

Model-driven apps excel when the data model is complex and the user experience can follow standard patterns. If you’re building an internal case tracking system with multiple related entities — customers, tickets, activities, resolutions — model-driven apps generate navigation, forms, and views from your Dataverse schema. You lose layout flexibility but gain consistency, role-based views, and built-in business rule enforcement.

A pattern we see frequently in mid-market organizations: canvas apps for the front-line experience (a technician in the field, a warehouse worker scanning inventory) paired with model-driven apps for the back-office management layer (supervisors reviewing submissions, managers running reports). Both connect to the same Dataverse tables, but the experience is tuned for each audience.

The mistake to avoid: building a model-driven app when your users expect a consumer-grade mobile experience, or building a sprawling canvas app when your actual need is structured data management across 15 related tables.

How Sharing Works — And Where It Gets Complicated

Building the app is half the challenge. Getting it into the hands of the right people — with the right permissions — is where most organizations hit unexpected friction.

Internal Sharing

For canvas apps shared within your organization, the mechanics are straightforward but the implications are not. According to Microsoft’s documentation on sharing canvas apps, you can share an app by assigning either Co-owner or User permissions to individuals, security groups, or your entire organization. Co-owners can edit, share, and manage the app. Users can only run it.

The critical detail most admins overlook: sharing the app does not automatically share the underlying data connections. If your canvas app connects to a SharePoint list, a SQL database, or a custom connector, you need to ensure that each user has appropriate access to those data sources independently. Power Apps will prompt users to authorize connections on first launch, but if they lack permissions to the underlying data, the app breaks silently — fields show blank, or the app throws cryptic delegation warnings.

For model-driven apps, sharing is governed through Dataverse security roles. You assign a security role to a user or team, and that role defines which tables they can read, write, create, or delete — and at what scope (their own records, their business unit, or the entire organization). This is more granular than canvas app sharing, but it also requires deliberate planning. If you’ve built an application for B2B use cases, we’ve covered the architectural and licensing dimensions in depth in our Power App Strategy for B2B Organizations guide.

External Sharing and Guest Access

Sharing apps with people outside your organization introduces an entirely different layer of configuration. This isn’t just a Power Apps setting — it’s a cross-platform identity and governance decision.

For canvas apps shared with external users, Microsoft requires B2B guest access through Microsoft Entra ID (formerly Azure AD). As outlined in Microsoft’s documentation on sharing canvas apps with guest users, you must first enable B2B external collaboration settings in your Entra ID tenant, then invite the external user as a guest, and finally share the app with their guest account. The guest user needs a Power Apps license — either per-app or per-user — assigned in your tenant, or they need to be covered by a pay-as-you-go plan.

This is where licensing costs for external collaboration escalate quickly if you don’t plan ahead. A vendor portal shared with 200 external users, each needing per-app licensing, is a fundamentally different cost model than 10 internal users running the same app.

External Collaboration: B2B, Portals, and the Security Surface Area

The decision to extend Power Apps beyond your organization’s boundary isn’t just technical — it’s a security and compliance decision. Two primary patterns exist, and they serve very different purposes.

Pattern 1: B2B Guest Access for Named External Users

This approach works when you have a known, finite set of external collaborators — a handful of partner organizations, key vendors, or contract workers who need access to internal tools. You invite them as Entra ID guests, assign licenses, share apps, and manage their access through Conditional Access policies.

As detailed in a LinkedIn analysis on configuring Power Platform for external users, the recommended approach layers Conditional Access on top of B2B collaboration. This means you can require MFA from guest users, restrict access to compliant devices, block access from specific geographies, or limit session duration. Without Conditional Access, a guest account is a relatively open door into your tenant’s Power Apps environment.

There’s also the question of tenant isolation. According to Microsoft’s documentation on cross-tenant restrictions, administrators can configure tenant-level isolation to restrict inbound and outbound connections. This controls whether users from other tenants can access your Power Platform resources and whether your users can access external tenants’ resources. If you enable tenant isolation, you’ll need to explicitly allowlist partner tenants that require B2B collaboration — otherwise, guest access will fail even if the user has been properly invited.

This is a detail that trips up organizations during initial deployment. They configure B2B guest access correctly, invite external users, and then discover that tenant isolation policies (sometimes enabled by a different team or inherited from a security baseline) block the connection entirely.

Pattern 2: Power Pages for Broad External Access

When your external audience is large, varied, or partially anonymous — think customer self-service portals, vendor onboarding forms, or public-facing data lookups — Power Pages is the appropriate tool. According to Microsoft’s documentation on Power Apps portals with finance and operations, Power Pages can surface Dataverse data to external users, including anonymous access scenarios where authentication isn’t required.

The security model here is fundamentally different from B2B guest access. Power Pages uses table permissions and web roles to control what authenticated portal users can see, and you define explicit rules for anonymous access. This decouples external user identity from your Entra ID tenant — external users authenticate through local registration, Azure AD B2C, or federated identity providers rather than becoming guests in your directory.

For organizations weighing these two patterns, the decision matrix looks like this: If you have fewer than ~50 external users who need access to internal Power Apps, B2B guest access is manageable. Above that threshold — or when you don’t control who the external users are — Power Pages offers a more scalable and securable architecture. We’ve explored the practical configuration requirements in our guide on Power App for External Collaboration.

Governance: What Happens After the First 20 Apps

The real challenge with Microsoft Power Apps isn’t building the first app. It’s what happens after citizen developers across the organization discover they can build their own tools. Without governance, you end up with hundreds of unmanaged apps, orphaned data connections, and security blind spots.

Effective Power Apps governance operates on three levels:

Environment strategy. Microsoft provides environments as containers for apps, flows, and data. At minimum, organizations need a production environment, a development/sandbox environment, and ideally a default environment that’s locked down (since every user with a license gets access to the default environment automatically). The default environment is where ungoverned shadow apps accumulate — address it early.

Data Loss Prevention (DLP) policies. DLP policies in the Power Platform admin center classify connectors as “Business,” “Non-Business,” or “Blocked.” Connectors within the same group can be used together in an app; connectors across groups cannot. This prevents a citizen developer from building an app that sends Dataverse records to a personal Gmail account via the Gmail connector. The subtlety: DLP policies apply per environment, and you need to design your policy set to match your environment strategy.

Maker and app lifecycle management. Who can create apps? Who reviews them before they go into production? How are apps updated without breaking existing users? Microsoft provides solutions packaging for ALM (Application Lifecycle Management) — apps, flows, and Dataverse customizations bundled into a solution that can be exported from dev and imported into production. Organizations that skip this step end up editing production apps directly, which works until it doesn’t.

Licensing: The Part Nobody Finds Exciting Until They Get the Bill

Power Apps licensing is one of the most frequently misunderstood aspects of the platform. The current model (as of 2024) includes several tiers, and the right choice depends on your usage pattern.

Per-app plans grant a user access to a single app (canvas or model-driven) plus one portal. This works for scenarios where you have a specific app with a large, occasional-use audience.

Per-user plans grant a user access to unlimited apps. This is appropriate for power users, business analysts, or teams that interact with multiple Power Apps daily.

Pay-as-you-go charges based on monthly active users per app, billed through an Azure subscription. This is useful for unpredictable usage patterns — seasonal apps, pilot projects, or external-facing apps where you can’t predict adoption.

Seeded/included licenses come with certain Microsoft 365 and Dynamics 365 plans, but with significant limitations. Microsoft 365 E3/E5 licenses include the ability to build and run apps that use standard connectors only — no premium connectors, no Dataverse (beyond Dataverse for Teams), no custom connectors. This is the gap that catches most organizations: they assume their M365 license covers everything, build an app on Dataverse, and then discover they need additional licensing for every user.

For a deeper dive into how licensing intersects with external access decisions, see our Power Apps Licensing and External Access breakdown.

Integration: Where Power Apps Fits in the Microsoft Stack

Power Apps doesn’t exist in isolation. Its value compounds when it’s connected to the broader Microsoft ecosystem — but those connections need to be deliberate.

Dataverse is the backbone. While canvas apps can connect to SharePoint, SQL, Excel, and hundreds of other sources, Dataverse provides relational data storage with built-in security, business logic, and integration with Dynamics 365. If you’re building anything beyond a single-form app, Dataverse should be your primary data store.

Power Automate handles process automation. The typical pattern: a Power App captures data from a user, a Power Automate flow processes it — sending approvals, updating external systems, generating documents, or triggering notifications. Apps without automation are just digital forms; apps with automation become business process tools.

Azure services extend the ceiling. When Power Apps hits its limits — complex calculations, machine learning models, integration with legacy APIs — Azure Functions, Azure Logic Apps, and Azure API Management fill the gap through custom connectors. This is how professional developers extend what citizen developers build, without replacing it.

Teams integration brings apps to where users already work. Canvas apps embedded in Teams tabs reduce adoption friction dramatically. The Dataverse for Teams environment provides a lightweight Dataverse instance within Teams, though with reduced capacity and feature limits compared to full Dataverse.

Common Pitfalls (and How to Avoid Them)

After working with organizations at various stages of Power Apps maturity, certain failure patterns repeat:

Building before defining the data model. Canvas apps make it easy to start with the screen and figure out the data later. This creates apps that work for demos but fail at scale. Start with your entities, relationships, and business rules — then build the UI.

Ignoring delegation limits. Canvas apps have a delegation limit (defaulting to 500 rows, configurable up to 2,000) for operations that can’t be processed server-side. If your SharePoint list has 10,000 items and your filter can’t be delegated, the app silently returns incomplete data. This isn’t a bug — it’s a fundamental design constraint that requires different query patterns or a move to Dataverse.

Treating external access as a checkbox. As the sources above make clear, sharing apps externally involves Entra ID configuration, licensing decisions, Conditional Access policies, tenant isolation settings, and DLP policies. Skipping any one of these creates either a security gap or a broken experience.

No environment strategy. Every licensed user can create apps in the default environment. Without policies restricting this, the default environment becomes a dumping ground. Establish environment rules before broad rollout.

Frequently Asked Questions

What is Microsoft Power Apps used for?

Microsoft Power Apps is a low-code platform for building custom business applications. Common use cases include internal data entry tools, approval workflows, field inspection apps, customer-facing portals, and process automation interfaces. It supports both simple single-screen forms and complex multi-table applications connected to Dataverse, SharePoint, SQL Server, and hundreds of other data sources.

Can I share a Power App with external users outside my organization?

Yes, through two primary methods. For named external users, you can invite them as B2B guests in Microsoft Entra ID and share canvas apps with their guest accounts — this requires enabling B2B external collaboration and assigning appropriate licenses. For broader external audiences, Power Pages (formerly portals) provides authenticated or anonymous web access to Dataverse data without requiring guest accounts in your directory.

Do I need a separate license for Power Apps if I have Microsoft 365?

Microsoft 365 E3 and E5 licenses include the ability to create and run Power Apps that use standard connectors only. If your app uses premium connectors, Dataverse (outside of Teams), custom connectors, or on-premises data gateways, you need a standalone Power Apps per-app or per-user license. This distinction catches many organizations off guard during deployment.

What’s the difference between canvas apps and model-driven apps?

Canvas apps give you full control over the user interface — you design every screen from scratch and connect to various data sources. Model-driven apps generate the interface automatically based on your Dataverse data model, providing standard navigation, forms, and views. Canvas apps suit mobile-first or highly customized experiences; model-driven apps suit complex data management scenarios with many related entities.

How do tenant isolation settings affect Power Apps sharing?

Tenant isolation, configured in the Power Platform admin center, controls whether users from external tenants can access your Power Platform resources. If enabled, B2B guest users from tenants not on your allowlist will be blocked from running shared apps — even if their guest account and licensing are properly configured. This setting must be coordinated with your external collaboration strategy.

Is Power Apps suitable for replacing legacy business applications?

For applications that are primarily data capture, workflow routing, and reporting — yes, Power Apps handles these well. For applications requiring heavy computation, real-time data processing, or complex custom UI, Power Apps may serve as the front-end layer while Azure services or custom APIs handle backend processing. The key is scoping correctly: Power Apps replaces certain categories of legacy apps effectively, but isn’t a universal replacement.

Where to Go From Here

If your organization is evaluating or expanding Microsoft Power Apps, the most productive next step isn’t building another app. It’s documenting your environment strategy, DLP policies, and licensing model. The organizations that get lasting value from Power Apps are the ones that treated governance as a prerequisite, not an afterthought. Start with a small inventory: how many apps exist today, who built them, what data they access, and who uses them. That baseline makes every subsequent decision — from architecture to licensing to external access — grounded in reality rather than assumptions.