Power Apps - Avoiding Mistakes in Custom Canvas Applications

#Scope

This guide covers mistakes that commonly make custom Power Apps canvas applications inaccurate, slow, inaccessible, difficult to deploy, or expensive to support. Use it during solution design, peer review, and release readiness checks.

The guidance applies to custom canvas applications that use Dataverse, SharePoint, SQL Server, Microsoft 365, Power Automate, or other supported connectors. Tenant policies, connector capabilities, licensing, and data-source behavior can differ, so validate each pattern in the target environment.

#Evidence classification

The recommendations in this guide are based primarily on Microsoft documentation and established Power Platform engineering practices. Any tenant-specific behavior should be added only after it has been reproduced and clearly labeled.

Evidence labels used in this guide:

• Microsoft documented: confirmed in current Microsoft documentation
• Implementation practice: recommended engineering practice derived from documented platform behavior
• Tenant tested: reproduced in the target Power Platform environment
• Exception approved: a documented risk or limitation accepted by the appropriate owner

#Problem 1: Building screens before defining the solution

Evidence: Implementation practice

Symptom: The application has polished screens but unclear ownership, inconsistent rules, duplicated steps, or no agreed definition of success.

Cause: Development began from a visual prototype before the team confirmed the business process, users, system of record, authorization rules, data classification, support model, and nonfunctional requirements.

Prevention: define the solution first

1. Document the primary user journeys and the minimum successful outcome for each.
2. Identify the system of record, data owner, retention requirements, and sensitivity classification.
3. Confirm expected data volume, peak concurrency, offline needs, supported devices, and network conditions.
4. Decide which logic belongs in Power Fx, Power Automate, Dataverse, a connector, or the source system.
5. Establish acceptance criteria for usability, performance, accessibility, security, and supportability.

Release rule: Do not begin a production build while ownership, authorization rules, or the system of record remains unclear.

#Problem 2: Treating the canvas app as the security boundary

Evidence: Microsoft documented, implementation practice

Symptom: Controls are hidden or galleries are filtered, but users can still access records through the underlying data source or another client.

Cause: UI visibility and filtering were mistaken for authorization. Canvas formulas control the experience; they do not replace permissions enforced by Dataverse, SharePoint, SQL Server, connectors, or the environment.

Prevention:

1. Apply least privilege in the source system and environment.
2. Use security roles, row-level security, table permissions, or source-specific access controls as appropriate.
3. Test with authorized, unauthorized, first-time, and low-permission accounts.
4. Review application sharing together with flows, connections, gateways, tables, and dependent resources.
5. Avoid displaying or logging sensitive values in notifications, diagnostic collections, or telemetry.

#Problem 3: Ignoring delegation warnings

Evidence: Microsoft documented

Symptom: Search, filtering, sorting, or totals work during development but omit records after production data grows.

Cause: A nondelegable formula is evaluated against only the limited set of records retrieved locally. Increasing the data-row limit does not make a nondelegable query correct for an unbounded data source.

Preferred pattern:

Filter(
    Orders,
    Status = "Open" && StartsWith(CustomerName, txtSearch.Text)
)

Pattern to avoid for large data sources:

ClearCollect(colOrders, Orders)

Prevention:

1. Treat delegation warnings as release blockers unless the dataset is demonstrably bounded and the exception is documented.
2. Check connector-specific delegation support for every filter, search, sort, lookup, aggregate, and operator used.
3. Test with more records than the configured app data-row limit.
4. Use indexed columns, Dataverse views, SQL views, source-side filtering, or server-side APIs when the required query cannot be delegated.
5. Retrieve only the records and columns required for the current task.

#Problem 4: Loading too much data during startup

Evidence: Microsoft documented

Symptom: The application opens slowly, appears frozen, or intermittently fails during initialization.

Cause: App.OnStart performs large ClearCollect operations, sequential connector calls, media loading, or calculations that are not required for the first screen.

Prevention:

1. Keep App.OnStart small and limited to essential initialization.
2. Use StartScreen and named formulas where appropriate.
3. Defer screen-specific data until the user needs it.
4. Use Concurrent only for independent operations; dependent operations must remain sequential.
5. Avoid cross-screen control references, which can force screens to load early.
6. Measure startup with Monitor, App Checker, and Performance insights using realistic data and devices.

#Problem 5: Using fragile screen layouts

Evidence: Microsoft documented, implementation practice

Symptom: Controls overlap, clip, or become unusable on mobile devices, alternate orientations, browser zoom, or long translated labels.

Cause: The application relies on fixed coordinates and dimensions rather than responsive containers and parent-relative sizing.

Prevention:

1. Use horizontal and vertical containers for responsive layouts.
2. Configure minimum size, maximum size, fill portions, wrapping, alignment, and overflow intentionally.
3. Base child sizing on Parent dimensions rather than hard-coded screen values.
4. Test at 200% zoom, with long labels, the on-screen keyboard, and supported device orientations.
5. Design loading, empty, validation, error, and no-permission states before release.
6. Use reusable components or component libraries for stable navigation, headers, and repeated form patterns.

#Problem 6: Creating inaccessible interactions

Evidence: Microsoft documented

Symptom: Keyboard or screen-reader users cannot identify controls, determine status, follow focus, or complete a workflow.

Cause: Controls have missing or meaningless AccessibleLabel values, status is communicated only through color, tab order is inconsistent, contrast is insufficient, or custom behavior was not manually tested.

Prevention:

1. Run Accessibility Checker throughout development and resolve errors before release.
2. Provide concise, meaningful accessible labels for interactive and informative controls.
3. Maintain a logical reading order, predictable tab order, and visible focus.
4. Pair color with text or another non-color indicator.
5. Test contrast, keyboard-only use, screen-reader announcements, zoom, long text, and error messages.
6. Provide captions or alternatives for audio and video and avoid unexpected motion.

Important: Accessibility Checker assists with review but does not replace manual testing with assistive technology.

#Problem 7: Allowing write failures to look successful

Evidence: Microsoft documented

Symptom: The app navigates to a confirmation screen or displays a success notification even though Patch, SubmitForm, or a connector action failed.

Cause: The write operation is not wrapped in formula-level error handling, or navigation is executed regardless of the result.

Preferred pattern:

IfError(
    Patch(Orders, Defaults(Orders), frmOrder.Updates),
    Notify(
        "The order could not be saved. Try again or contact support.",
        NotificationType.Error
    ),
    Notify("Order saved.", NotificationType.Success)
)

Prevention:

1. Keep formula-level error management enabled.
2. Use IfError around writes and dependent actions.
3. Use App.OnError for consistent reporting and sanitized telemetry; it cannot undo an operation that already failed.
4. Disable the submit command while a write is in progress to prevent duplicate submission.
5. Design idempotent operations or duplicate-detection rules for retried requests.
6. Preserve entered values and provide a clear recovery path after failure.

#Problem 8: Hard-coding environment-specific configuration

Evidence: Microsoft documented

Symptom: A solution import succeeds, but the application points to the wrong site, table, connection, mailbox, or endpoint.

Cause: URLs, identifiers, email addresses, list names, or other environment-specific values were embedded directly in formulas or flows.

Prevention:

1. Build the application inside a solution from the start.
2. Use environment variables for environment-specific configuration.
3. Use connection references for solution-aware connections.
4. Maintain separate development, test, and production environments.
5. Deploy into a clean test environment using production-like configuration before production release.
6. Rehearse rollback or forward-fix procedures before deployment.

#Problem 9: Optimizing by intuition instead of evidence

Evidence: Microsoft documented

Symptom: The team adds collections, caching, or complex formulas, but the application remains slow or becomes stale and harder to maintain.

Cause: Changes were made without identifying the actual bottleneck. Common causes include large payloads, per-row connector calls, cross-screen references, too many controls, heavy media, repeated calculations, or nondelegable queries.

Prevention:

1. Use Monitor, App Checker, and Performance insights with production-scale data.
2. Remove unused screens, controls, variables, collections, connections, and media.
3. Compress media and simplify control-heavy galleries.
4. Batch or delegate data access and avoid connector calls inside repeated gallery operations.
5. Define cache scope, refresh triggers, conflict handling, and visible last-updated state.
6. Reduce work, data, and dependencies before adding caching.

#Release gate checklist

• User journeys, ownership, data classification, nonfunctional requirements, and acceptance criteria are approved.
• Delegation warnings are resolved or accepted with bounded-data evidence.
• Source-system permissions enforce least privilege independently of the UI.
• Responsive layouts and loading, empty, validation, error, focus, and recovery states are tested.
• Startup is lean; writes handle errors; no unintended cross-screen references remain.
• Monitor, App Checker, and Performance insights have been reviewed with production-scale data.
• Accessibility Checker errors are resolved and keyboard, screen-reader, zoom, contrast, and labels are manually tested.
• DLP, sharing, connections, gateways, sensitive data handling, licensing, and telemetry are reviewed.
• Environment variables and connection references are configured and deployment and rollback are rehearsed.
• Product owner, technical owner, support route, monitoring, runbook, known limitations, and next review date are documented.

#Review triggers

Repeat design and release review when any of the following changes:

• Data source or schema
• Connector or gateway
• Authentication or security role
• DLP policy
• User population or data classification
• Supported device or host
• Expected data volume or concurrency
• Critical business rule
• Premium licensing dependency
• Deployment topology

#Takeaways for future builds

• Delegation is a data-correctness requirement, not only a performance recommendation.
• UI visibility is not authorization; enforce security in the source and platform.
• Keep startup small and load data when the user needs it.
• Responsive and accessible behavior must be designed, not added at the end.
• A write is not successful until the formula handles and confirms the result.
• Use solutions, environment variables, and connection references before the first production deployment.
• Measure performance with realistic data and tools before applying caching or other shortcuts.