Power Apps: Canvas vs Model-Driven, Delegation, and Performance Guide

Before you write a single formula, you need to make the right architectural choice. Getting this wrong means rebuilding from scratch. Here's the real-world breakdown Microsoft's docs summarize but don't spell out clearly enough.

Canvas apps give you a blank canvas, literally. You drag and drop controls, position them exactly where you want, and connect to data from over 900 sources: SharePoint, SQL Server, Salesforce, REST APIs, Excel files in OneDrive, you name it. The formula language (Power Fx) is Excel-like, which makes it approachable for non-developers. Canvas apps shine when you need a custom UI, a mobile-first experience, or when your data lives in a non-Dataverse source.

Model-driven apps work differently. You don't design the UI at all, the UI is generated automatically from your data model in Microsoft Dataverse. You define tables, columns, relationships, views, and forms, and Power Apps renders a consistent interface from that definition. Model-driven apps are the right choice when you have complex relational data, need built-in business process flows, want role-based security at the record level, or are building something that needs to scale to thousands of users with server-side logic.

Code apps (the third option in the "Choose an app type" screen) are React-based apps built with the Power Apps Component Framework, that's for pro developers who need full control.

Decision rule: if your data is already in Dataverse or you're building something enterprise-grade with multiple related tables and approval workflows, go model-driven. If you need a custom screen layout, are connecting to SharePoint or an external API, or are building a single-purpose tool, go canvas. Mixing both in a solution is valid and common, a model-driven app can embed canvas app components using the Canvas control.

To start: go to make.powerapps.com → Create → Start from blank, then pick your type. If you see the Plan designer (the new AI-native experience), you can describe what you want in natural language and Copilot will scaffold the tables and screens for you, this is worth trying first for new projects because it sets up Dataverse structure correctly from the start.

Once you select your type and save, you cannot convert between canvas and model-driven. Choose carefully.

The Power Apps delegation limit is one of the most misunderstood behaviors in the platform. Here's exactly what's happening and how to fix it.

When Power Apps evaluates Filter(DataSource, condition), it tries to send the condition to the server (SharePoint, Dataverse, SQL) to execute there and return only matching rows. That's delegation. When the data source can't execute that specific condition server-side, Power Apps pulls the first N records (default 500, max 2,000) to the device and filters there. You get wrong results silently.

Diagnosing which formula is non-delegable:

1. In Power Apps Studio, hover over the blue underline in the formula bar. A tooltip will identify the exact function or operator that's non-delegable.
2. Open the App checker (the shield icon in the left toolbar). It lists all delegation warnings with the screen and control name.

Common non-delegable operations and their delegable replacements:

// NON-DELEGABLE, avoid these in Filter/Search
Filter(Employees, Lower(Name) = Lower(SearchBox.Text))    // Lower() not delegable to SharePoint
Filter(Orders, Len(Notes) > 100)                          // Len() not delegable
Filter(Products, Product in MyCollection)                  // 'in' with collection not delegable

// DELEGABLE, use these instead
Filter(Employees, StartsWith(Name, SearchBox.Text))        // Delegable to SharePoint
Filter(Orders, Status = "Open")                            // Equality on indexed column, delegable
Search(Products, SearchBox.Text, "ProductName")            // Search() is delegable to SharePoint/Dataverse

For Dataverse specifically: virtually all filter operations including Filter, LookUp, CountRows, and Search are fully delegable when the column is indexed. Dataverse is the recommended data source for Power Apps precisely because of this, the delegation story is much stronger than SharePoint.

If you absolutely must use a non-delegable formula, load data into a collection first and filter the collection:

// On App.OnStart or Screen.OnVisible:
ClearCollect(colEmployees, Filter(Employees, Department = "Sales"));

// In Gallery.Items, now filtering a local collection, full dataset loaded:
Filter(colEmployees, Lower(Name) = Lower(SearchBox.Text))

This pattern works only when your filtered-to-collection result is small (under a few thousand rows). Don't try to ClearCollect an entire 100,000-row table.

After fixing, the blue banner should disappear and your gallery record counts should match the source exactly.

Microsoft Dataverse is the underlying data platform for Power Apps, and using it properly unlocks capabilities that simply don't exist with SharePoint or SQL connections. I've seen teams fight with SharePoint delegation limits for months when switching to Dataverse would have solved the problem in a day.

Dataverse stores data in tables (equivalent to database tables), which have columns, relationships, views, and built-in security roles. It supports server-side business rules, calculated columns, rollup columns, and Power Automate integration natively.

To add a Dataverse connection to a canvas app:

1. In Power Apps Studio, open the Data panel (cylinder icon in the left toolbar).
2. Click Add data → Microsoft Dataverse.
3. Select your environment from the dropdown (make sure you're in the right environment, this is the most common mistake; people add the table from the wrong environment and see no data).
4. Search for and select your table. Click Connect.

Setting up a new Dataverse table for a canvas app:

1. Go to make.powerapps.com → Tables → New table.
2. Name your table. Dataverse will automatically create a primary column (Name by default).
3. Add columns: click Add column, set the data type (Text, Number, Choice, Lookup, Date, etc.).
4. For relationship columns (lookups), set the Related table. This enables server-side joins and eliminates the need for manual VLOOKUP-style formulas in your app.

One thing that catches everyone: Dataverse column names in Power Fx use the schema name (like cr4f2_employeeid) not the display name ("Employee ID"). In newer versions of Power Apps Studio, the formula bar autocompletes the display name and maps it correctly, but if you're seeing errors like Name isn't valid, 'EmployeeID' is not recognized, check the actual column schema name in the table editor under Advanced options → Schema name.

// Correct Dataverse formula referencing schema name:
Filter('Employees', cr4f2_department = "Engineering")

// Or use the display name alias (works in newer Studio versions):
Filter(Employees, Department = "Engineering")

Once your Dataverse tables are connected, you'll notice that delegation warnings largely disappear, and queries return the correct full record set regardless of size.

A slow Power Apps canvas app almost always comes down to one of three root causes: too many connector calls on app load, sequential (non-concurrent) data loading, or too many controls on a single screen. Here's how to find which one is killing your app.

Step 1, Use the Monitor tool to profile your app:

1. In Power Apps Studio, go to Advanced tools → Monitor (or press Alt+Shift+M on Windows).
2. Launch your app from the Monitor window. Every formula evaluation, connector call, and control event is logged with timestamps and duration.
3. Look for rows with Network type, these are connector calls. Sort by Duration descending. Anything over 2,000ms is a candidate for optimization.

Step 2, Fix slow startup with Concurrent():

The single biggest performance win I see in real-world apps is replacing sequential data loads with Concurrent(). If your App.OnStart looks like this:

// SLOW, runs sequentially, each waits for the previous
ClearCollect(colUsers, Users);
ClearCollect(colOrders, Orders);
ClearCollect(colProducts, Products);

Change it to:

// FAST, all three run in parallel
Concurrent(
    ClearCollect(colUsers, Users),
    ClearCollect(colOrders, Orders),
    ClearCollect(colProducts, Products)
);

On a three-source app load, this alone can cut startup time by 60–70%.

Step 3, Move data loads from App.OnStart to Screen.OnVisible:
Don't load data for Screen 3 during initial app startup. Load it when the user navigates to Screen 3. This makes the first screen appear almost instantly.

Step 4, Reduce gallery render load:
Each row in a gallery renders all its controls. A gallery with 8 labels, 3 icons, and 2 buttons per row, showing 50 rows, is rendering 650 controls simultaneously. Cut it to 3–4 visible fields per row and use a detail screen for the rest. Also enable Gallery → Properties → Delay item loading (Experimental) to defer off-screen row rendering.

After these changes, reload your app in the Monitor tool and compare the startup time. Most apps go from 8–12 seconds down to under 3 seconds with just these four steps.

Beyond delegation and performance, there's a set of configuration errors that show up repeatedly when teams first deploy Power Apps. Here are the ones I see most often, with exact fixes.

Error: "The data source 'SharePoint' returned an error. The response is not valid JSON."
This usually means your SharePoint site URL has a trailing slash or a space, or the list name has been renamed but your connection still references the old name. Fix: go to Data panel → three dots next to the SharePoint connection → Edit, re-enter the site URL without a trailing slash, and re-select the list.

Error: "Connector throttling, 429 Too Many Requests"
Power Apps connectors have call limits. SharePoint standard connector allows around 600 calls per 60 seconds per connection. If your gallery is triggering individual row lookups (anti-pattern), you'll hit this fast. Fix: load related data with ClearCollect once, then use LookUp(localCollection, ...) instead of calling the connector per row.

Error: "You don't have permission to perform this action" on Dataverse
This is a security role issue. In Dataverse, every user needs a security role assigned that grants access to the specific tables your app uses. Fix:

1. Go to Power Platform admin center (admin.powerplatform.microsoft.com) → Environments → [your env] → Settings → Users + permissions → Security roles.
2. Find the role assigned to your user (or create a custom one).
3. Under the role editor, set at minimum Read privilege on each table your app accesses. Match the scope (User, Business Unit, Organization) to what your app needs.
4. Reassign the role to affected users under Users → [user] → Manage security roles.

Error: "This app isn't working, Contact your administrator"
This generic error in the published app almost always means a connection wasn't shared when the app was shared. Fix: go to make.powerapps.com → Apps → [your app] → Share. Under Data permissions, make sure every connector has Can use checked for the shared users. Republish after saving.

App checker showing "Accessible label" warnings:
These are accessibility errors, controls missing labels for screen readers. Fix each flagged control by setting its AccessibleLabel property to a descriptive string. This also matters for Microsoft 365 compliance in enterprise environments.

After addressing these errors, do a full republish: File → Save → Publish to this version → Publish this version. Tell your users to clear browser cache or reinstall the Power Apps mobile app if they're still seeing old behavior.