DIALOGE — E: Experience¶
Experience is the layer users actually see and touch. Everything else in DIALOGE exists to serve it. A solution with a perfect data model, robust integration, powerful AI, and well-designed logic fails if the experience is confusing, slow, or inaccessible.
TL;DR
Choose the right interface type deliberately: canvas apps for design freedom and task-focused workflows, model-driven apps for data-centric enterprise applications, Power Pages for external portals. Build responsive from the start. Design for accessibility (WCAG 2.1 AA). What users see should match what is stored (WYSIWYIS).
Applies To
Audience: Solution Maker · Solution Engineer BOLT Tiers: All Maturity: Basic → Advanced Frameworks: DIALOGE
What Experience Means in DIALOGE¶
Experience is how people interact with a solution — the interface, the interaction design, and the user journey. It is the primary determinant of adoption. Users do not care about the elegance of the data model or the sophistication of the logic. They care about whether the solution helps them do their job faster, more accurately, and with less frustration.
Enterprise experience has constraints that consumer experience does not. Accessibility compliance is a legal requirement in most regulated industries, not a design preference. Device diversity is real — solutions must work on desktop, tablet, phone, and sometimes shared kiosks. Performance expectations are set by consumer apps and must be met on enterprise infrastructure. Brand and design standards apply. Internationalisation matters when organisations operate across regions and languages.
Meeting these expectations requires understanding which interface type fits the use case — and then building it with the discipline that enterprise deployment demands.
The Interface Decision — The Most Important Choice in Experience¶
Builders come to Power Platform with different backgrounds and different expectations. The interface decision must be made deliberately — the wrong interface type creates unnecessary complexity, limits future capability, or produces an experience that does not meet user expectations.
The sections that follow address each interface type from the builder's perspective — what they expect, what Power Platform provides, and the enterprise implications of each choice.
Canvas Apps — Design Freedom and Its Cost¶
Makers expect a design surface where what they build is what users see — pixel-level control over layout, branding, interaction, and navigation without writing HTML or CSS. Canvas apps deliver exactly this. They are the closest Power Platform equivalent to designing a screen in Figma and having it work.
What canvas apps provide: Canvas apps give makers a blank canvas — literally. Every element is placed, sized, and styled by the maker. Screens, galleries, forms, buttons, images, icons, and custom components are arranged freely. The result looks and behaves exactly as designed, not as a platform default.
WYSIWYG — What You See Is What You Get: The canvas app design surface is genuinely WYSIWYG. The app in the studio looks like the app users run. There is no separate rendering step, no CSS to wrestle with, and no browser inconsistency between design and runtime. What the maker designs is what the user experiences — this is the foundational promise of canvas app development and it holds.
WYSIWYIS — What You See Is What It Stores: Beyond WYSIWYG, enterprise builders should apply the WYSIWYIS principle — ensuring that what the UI displays reflects what is actually stored in the data layer. Display-only computed values, formatted strings assembled in the app, and UI-layer transformations that are not persisted to Dataverse create a gap between what users see and what integrations, reports, and agents access. Design the Experience and the Data layer together — if a value matters, it belongs in the data model, not only in a canvas formula.
When canvas apps are the right choice: - Solutions requiring custom branding, layout, or interaction patterns not available in model-driven apps - Task-focused workflows — a specific process with a defined start, steps, and end - Consumer-grade user experiences for non-technical users - Kiosk or shared-device scenarios where a purpose-built interface is required - Solutions embedding complex custom PCF components that need precise layout control
When canvas apps are not the right choice: - Data-heavy solutions where users need to navigate, filter, and manage large record sets — model-driven apps handle this more efficiently - Solutions that are primarily about managing Dataverse data across multiple related tables — model-driven apps are purpose-built for this - Solutions where the development team lacks the discipline to manage canvas app complexity — canvas apps scale in complexity faster than model-driven apps
Responsive design and form factors: Canvas apps support tablet and phone layouts — designed separately or responsively using container components. Enterprise solutions serving both desktop and mobile users should use responsive layouts rather than maintaining separate phone and tablet apps. The investment in responsive design at the start is smaller than the maintenance overhead of two separate apps.
Offline capability: Canvas apps support offline operation — collections cached locally, changes queued and synced on reconnect. For field workers, inspectors, and users in low-connectivity environments, offline capability is a critical requirement. It must be designed in from the start — retrofitting offline behaviour into an existing canvas app is significantly more complex than building it in.
Model-Driven Apps — Structured Data-Centric Experiences¶
Solution Engineers and business analysts building data-intensive enterprise applications expect a structured, metadata-driven experience — forms, views, dashboards, and business process flows that adapt to the data model without requiring pixel-level layout work. Model-driven apps deliver this, and they do it at a level of consistency and scalability that canvas apps cannot match for complex data scenarios.
What model-driven apps provide: Model-driven apps are generated from the Dataverse data model. Forms, views, and dashboards reflect the tables, columns, and relationships defined in Dataverse — automatically. Changes to the data model surface in the app without redesigning screens. Business process flows guide users through stage-gated processes. The result is a consistent, data-centric experience that scales with the data model.
When model-driven apps are the right choice: - Solutions where users need to navigate, manage, and relate records across multiple Dataverse tables - CRM, service management, case management, and operations management scenarios - Solutions where the data model is complex and the UI should reflect it faithfully - Scenarios where business process flows guide users through defined stages - Solutions where the full Dataverse capability — views, charts, dashboards, activity feeds — is the experience
The productivity surface for enterprise roles: Model-driven apps are the native experience for enterprise roles that work primarily in Dataverse — sales teams, service agents, operations managers, field coordinators. The consistency of the model-driven experience — familiar navigation, standard forms, predictable behaviour — reduces training overhead and support burden significantly compared to custom canvas apps for the same scenarios.
Customisation within model-driven apps: Model-driven apps are customised through configuration — form layouts, view columns and filters, sitemap navigation, command bar buttons, business process flow stages. For behaviour that configuration cannot address, the Client SDK (JavaScript) provides client-side extensibility. For server-side behaviour, low-code plugins and classic plugins provide the logic layer. The Experience and Logic layers are deliberately separated in model-driven apps — UI configuration lives in the app, business logic lives in Dataverse.
Power Apps Code Apps — When Canvas Needs Code¶
Pro developers expect the option to build canvas-style apps with full code control — React components, TypeScript, version-controlled source, and the ability to implement UI patterns that the low-code canvas designer cannot produce. Power Apps Code Apps deliver this within the Power Platform ecosystem.
What Code Apps provide: Code Apps are React-based canvas applications where the UI is built entirely in code — TypeScript, React components, and the Power Apps component model. They access Dataverse, connectors, and Power Platform capabilities through the same APIs as standard canvas apps, but the interface is authored in code rather than the visual designer.
When Code Apps are the right choice: - Solution Engineers with React/TypeScript skills who need full UI control - Interface requirements that exceed what the canvas designer can produce — complex animations, custom gesture handling, highly dynamic layouts - Organisations with existing React component libraries they want to reuse within Power Platform - Solutions where the development team prefers code-first development and wants version control at the component level, not just the solution level
Code Apps vs standard canvas apps: Code Apps are not a replacement for canvas apps — they are an option for scenarios where code-first development is the right approach. Standard canvas apps serve the vast majority of enterprise canvas app scenarios with less overhead. Reach for Code Apps when the canvas designer genuinely cannot meet the requirement, not because code feels more familiar.
PCF — Power Apps Component Framework¶
Solution Engineers building within canvas and model-driven apps expect to extend the native control library with custom components — React-based, TypeScript-authored, pixel-perfect UI elements that integrate natively into the Power Platform experience. PCF (Power Apps Component Framework) is this capability.
What PCF provides: PCF controls are custom UI components that behave like native Power Platform controls — they appear in the canvas app control library and in model-driven app form editors, they bind to Dataverse data, and they participate in the solution packaging and deployment model. From the user's perspective, a PCF control is indistinguishable from a native control. From the developer's perspective, it is a React component with full TypeScript control.
When PCF is the right choice: - UI requirements that no native control meets — custom visualisations, specialised input controls, complex interactive components - Reusable UI components that need to work consistently across multiple apps and solutions - Replacing third-party UI libraries with a Power Platform-native equivalent - Model-driven app form enhancements — custom field rendering, inline editing patterns, specialised display components
PCF governance: PCF controls are pro-code assets — they must be treated with the same discipline as any enterprise software component: - Version-controlled in source as TypeScript — not as compiled binary artefacts - Tested independently before integration into solutions - Included in solutions and deployed through the standard ALM pipeline - Owned by a named team — PCF controls used across multiple solutions need a clear owner responsible for updates and compatibility maintenance
PCF vs Code Apps: PCF extends the experience within existing canvas and model-driven apps — it is an enhancement to the platform's native UI capability. Code Apps replace the canvas designer entirely for a specific application. PCF is the right choice when specific controls need customisation. Code Apps are the right choice when the entire application UI needs code-first development.
Power Pages — External-Facing Portals¶
Builders creating solutions for external users — customers, partners, suppliers, citizens — expect a web portal capability that connects to enterprise data without exposing the internal Power Platform environment directly. Power Pages is this capability.
What Power Pages provides: Power Pages is a low-code web portal platform built on Dataverse. It provides authenticated and anonymous external user experiences — forms, lists, detail pages, and multi-step processes — connected directly to Dataverse data with a configurable security model that controls what external users can see and do.
When Power Pages is the right choice: - Customer self-service portals — case submission, account management, order tracking - Partner portals — deal registration, shared data access, collaborative workflows - Citizen-facing government services — application submission, status tracking, document upload - Event registration, survey collection, and public-facing data submission scenarios
Power Pages vs custom web application: Power Pages is appropriate when the portal requirements are standard — forms, lists, authenticated access to Dataverse data — and when the business benefits of low-code development (speed, no custom hosting, native Dataverse integration) outweigh the constraints. When the portal requires complex custom UI, advanced JavaScript behaviour, or integration patterns that Power Pages cannot support, a custom web application calling Dataverse Web API is the more appropriate architecture.
Security model for Power Pages: External users access Dataverse through web roles — table permissions and column permissions that define precisely what records and fields external users can read, create, update, and delete. The Power Pages security model is separate from the internal Dataverse security role model — it must be designed explicitly for external access, with the assumption that external users should see the minimum data necessary for their task.
Teams Integration — Meeting Users Where They Work¶
Enterprise builders expect solutions to be available where users already spend their time — not requiring users to open a separate application. For most enterprise organisations, that means Microsoft Teams. Power Platform meets users in Teams natively.
What Teams integration provides: - Canvas apps in Teams — canvas apps embedded as personal apps, tabs in team channels, or tabs in group chats. Users access the solution without leaving Teams. - Model-driven apps in Teams — model-driven apps embedded as tabs, providing the full data management experience within the Teams interface - Copilot Studio agents in Teams — conversational agents available as personal apps or in channels, handling queries and triggering processes without users navigating elsewhere - Power Automate adaptive cards — approval requests, notifications, and interactive cards delivered directly in Teams conversations, enabling approvals and responses without opening Power Automate - Power Pages in Teams — portal pages embedded within Teams as tabs for cross-functional collaboration scenarios
The enterprise implication: Teams integration is not just a convenience — it is an adoption strategy. Solutions that require users to visit a separate URL compete with Teams for attention and lose. Solutions that surface within Teams, where users already are, have significantly higher adoption rates and lower training overhead. For enterprise solutions targeting knowledge workers, Teams integration should be the default delivery surface, not an afterthought.
Copilot Studio Embedded Agents — Conversational UI¶
Builders designing solutions for complex, open-ended user interactions expect a conversational interface option — not just forms and screens. Copilot Studio agents embedded within solutions provide this, transforming the experience from navigation-based to intent-based.
What embedded agents provide: A Copilot Studio agent embedded in a canvas app, model-driven app, Power Pages portal, or Teams app gives users a natural language interface to the solution's capabilities. Instead of navigating to a screen, filling a form, and submitting — a user asks a question or states an intent, and the agent responds, retrieves data, or initiates a process.
When conversational UI is the right experience pattern: - Complex processes where users do not know which form or screen to navigate to - Information retrieval scenarios where users want answers, not data grids - Guided process completion — the agent walks the user through a process conversationally - Support and helpdesk scenarios where users describe problems rather than categorise them - Solutions serving non-technical users who find form-based interfaces unintuitive
The experience design principle for agents: Conversational UI is not a replacement for all form-based interaction — it is an addition for scenarios where conversation is more natural than navigation. Well-designed solutions combine both: structured forms for data entry where precision matters, conversational agents for discovery, guidance, and process initiation where flexibility matters.
For the full Copilot Studio architecture — topics, actions, knowledge sources, multi-agent orchestration, and governance — see the dedicated Copilot Studio section of this wiki.
Power BI Embedded — Analytics Within Solutions¶
Builders creating solutions for operational roles expect analytics and reporting to be available within the solution context — not requiring users to switch to a separate Power BI workspace. Power BI embedded integration addresses this.
What Power BI embedded provides: Power BI reports and dashboards can be embedded directly within canvas apps and model-driven apps — appearing as native components of the solution rather than external links. Users see live, interactive analytics in the context of their work without leaving the solution.
Row-level security in embedded reports: Power BI embedded reports inherit the user's identity — row-level security configured in the Power BI dataset ensures that users see only the data they are authorised to see. This is critical for enterprise solutions where different users have different data access — a regional manager seeing only their region's data in an embedded report uses the same security model as the Dataverse security role that controls their record access.
When to embed vs link: Embed Power BI when the analytics are core to the solution's workflow — when users need to see metrics and act on them without context-switching. Link to Power BI when the analytics are supplementary — useful but not part of the primary workflow. Embedding adds complexity to the solution; only invest in it when the user experience benefit justifies it.
GenUX — AI-Generated Interfaces¶
Builders expect the same AI-assisted generation capability for UI that tools like Lovable and Replit have established in the broader market — describing an interface and receiving a polished, production-ready result. Power Platform's GenUX capability delivers this within the Power Platform ecosystem.
GenUX produces visually styled, responsive canvas app interfaces from natural language descriptions — going beyond the functional scaffolding of describe-to-make to produce experiences that meet enterprise visual standards without requiring a UI designer in the loop for initial generation.
GenUX is covered in full in A — AI, A1: AI for Maker Productivity. From an Experience perspective, treat GenUX output as a high-quality starting point that still requires review for accessibility compliance, performance, and enterprise design standards before production deployment.
Mobile — Pre-Built and Custom¶
Builders expect solutions to work on iOS and Android. Power Platform provides two distinct paths — a pre-built Microsoft mobile app that runs existing solutions natively, and a custom mobile development path for solutions requiring a purpose-built mobile experience.
Power Apps Mobile — Pre-Built iOS and Android¶
The Power Apps mobile app is a Microsoft-published native app for iOS and Android that runs canvas apps and model-driven apps without any additional development. Builders who have built a canvas app or model-driven app for desktop get mobile delivery for free — the same solution runs in the Power Apps mobile app on any iOS or Android device.
What Power Apps mobile provides: - Native iOS and Android app — available in the App Store and Google Play, published and maintained by Microsoft - Runs canvas apps and model-driven apps natively — no mobile-specific rebuild required - Push notifications — Power Automate can send push notifications to Power Apps mobile via the Power Apps notification connector - Offline capability — canvas apps with offline configuration work in Power Apps mobile without connectivity - Biometric authentication — Face ID, Touch ID, and Android equivalents supported via Entra ID authentication
The enterprise implication: For most enterprise mobile scenarios — field workers, inspectors, managers on the move — Power Apps mobile is the correct answer. It is free, maintained by Microsoft, and requires no custom mobile development investment. The question is not "should we build a mobile app?" — it is "does our canvas or model-driven app work well on a phone form factor?"
Responsive design for mobile: Canvas apps designed for desktop do not automatically work well on phone screens. Responsive layout using containers, relative sizing, and phone-optimised navigation must be designed deliberately. Solutions targeting both desktop and mobile users should be designed responsively from the start — retrofitting mobile layouts is costly.
Custom Mobile App¶
Solution Engineers building mobile-first enterprise experiences expect the option to build native or cross-platform mobile apps — React Native, Flutter, Swift, Kotlin — while connecting to Power Platform as the back-end. This pattern is fully supported and strategically important for solutions where the mobile experience requirements exceed what Power Apps mobile can deliver.
What the custom mobile pattern provides: A custom mobile app — built in React Native, Flutter, or any mobile framework — connects to Power Platform via: - Dataverse Web API — reading and writing Dataverse data via OData REST endpoints - Custom APIs — calling Dataverse-hosted business logic - Power Automate HTTP triggers — initiating flows from the mobile app - Entra ID authentication (MSAL) — the same identity provider as internal Power Platform users, providing SSO across the enterprise
When custom mobile is the right choice: - Mobile-first experiences requiring native device capabilities — camera, GPS, biometrics, AR — beyond what Power Apps mobile exposes - Consumer-facing mobile apps where the Microsoft Power Apps branding and UX paradigm is not appropriate - Organisations with existing mobile development teams and established mobile frameworks - Solutions requiring performance characteristics or offline synchronisation patterns that canvas apps cannot achieve - Branded enterprise mobile apps published under the organisation's own App Store presence
The architectural principle: Custom mobile does not mean abandoning Power Platform. It means using Power Platform as the governed, secure, auditable back-end — Dataverse for data, Custom APIs for business logic, Power Automate for process orchestration — while delivering the front-end experience in the most appropriate mobile framework. This is the best of both worlds: enterprise governance and Power Platform capability on the back-end, full mobile development freedom on the front-end.
Custom UI Hosted Outside Power Platform¶
Solution Engineers with web development backgrounds expect to build front-ends in frameworks they already know — React, Angular, Vue, or server-rendered web applications — while connecting to an enterprise back-end. Power Platform fully supports this pattern, and for a significant class of enterprise scenarios it is the architecturally correct choice.
What the custom web UI pattern provides: Any web application can connect to Power Platform's back-end capabilities: - Dataverse Web API (OData) — reading and writing data via standard REST endpoints - Custom APIs — calling Dataverse-hosted business logic as HTTP endpoints - Power Automate HTTP triggers — initiating flows from external web applications - Entra ID (MSAL) — authenticating users via the same identity provider as internal Power Platform users, enabling SSO
When custom web UI is the right choice: - Enterprise web applications requiring UI frameworks, component libraries, or interaction patterns not achievable in Power Platform's native interfaces - Organisations with existing web development teams and established front-end frameworks - Solutions requiring SEO, custom URL structures, or web performance characteristics that Power Pages cannot provide - Public-facing web experiences where full design freedom and brand consistency are non-negotiable - Scenarios where the web application is one channel among many — the same back-end serving a web app, a mobile app, and an internal Power Platform solution simultaneously
Authentication for external web apps: External web applications authenticate to Dataverse Web API and Custom APIs using Entra ID app registrations and MSAL (Microsoft Authentication Library). Users authenticate once and access both the external web app and internal Power Platform surfaces with the same identity — the same Dataverse security roles apply regardless of the interface used to access the data.
The enterprise architecture principle: Power Platform is not just a front-end platform. Its back-end capabilities — governed data in Dataverse, business logic in Custom APIs, process orchestration in Power Automate — are fully accessible to any web or mobile front-end via standard APIs. Organisations that treat Power Platform only as a low-code UI builder miss the architectural pattern that scales most effectively for enterprise complexity.
Accessibility — Non-Negotiable for Enterprise¶
Enterprise builders expect the platform to provide accessibility compliance as a foundation, not a retrofit. The expectation is WCAG 2.1 AA at minimum — and in regulated industries, public sector, and organisations with diversity and inclusion commitments, accessibility is a legal requirement, not a design preference.
WCAG 2.1 AA — the enterprise standard: Web Content Accessibility Guidelines (WCAG) 2.1 AA defines the internationally recognised accessibility standard for digital interfaces. Enterprise solutions must meet this standard — not as a best-effort aspiration, but as a go-live requirement. Solutions that fail accessibility compliance expose the organisation to legal risk and exclude users with disabilities from full participation.
Power Platform accessibility foundations: - Canvas apps — the canvas app accessibility checker surfaces accessibility issues during development: missing accessible labels, insufficient colour contrast, missing keyboard navigation support. Run the accessibility checker before every deployment. Note that the checker identifies issues but does not automatically fix them — remediation requires deliberate design decisions. - Model-driven apps — model-driven apps have strong accessibility built in by default. Standard forms, views, and navigation meet WCAG 2.1 AA. Customisations — especially Client SDK scripts, PCF controls, and custom HTML web resources — can break accessibility. Every customisation must be tested for accessibility impact. - Power Pages — Power Pages provides accessible base templates. Custom CSS, JavaScript, and Liquid template modifications must be reviewed for accessibility impact. - PCF controls — custom PCF controls must implement ARIA attributes, keyboard navigation, and screen reader support explicitly. Accessibility in PCF controls is the developer's responsibility — the framework does not provide it automatically.
Key accessibility requirements for enterprise solutions: - Keyboard navigation — every interactive element must be reachable and operable via keyboard alone. Users who cannot use a mouse must be able to complete every task. - Screen reader compatibility — all content must be readable by screen readers (NVDA, JAWS, VoiceOver). Images, icons, and non-text elements require descriptive alt text or ARIA labels. - Colour contrast — text and interactive elements must meet minimum contrast ratios (4.5:1 for normal text, 3:1 for large text). Do not rely on colour alone to convey information. - Focus management — keyboard focus must be visible, logical, and managed correctly when UI changes dynamically — modals, panels, and dynamic content must not lose or trap focus. - Error identification — form errors must be identified in text, not only by colour or icon. Users must understand what is wrong and how to fix it.
Accessibility as a design requirement, not a post-build audit: Accessibility failures discovered during a pre-launch audit are significantly more expensive to fix than accessibility designed in from the start. Establish accessibility requirements before design begins, review accessibility throughout development, and conduct a formal accessibility audit before go-live — not as the first accessibility check.
Internationalisation and Localisation¶
Builders in global organisations expect solutions to support multiple languages, regional date and number formats, and right-to-left text without rebuilding the solution per region.
Multi-language canvas apps: Canvas apps support multiple languages through localisation — storing label text and messages in a data source keyed by language, and loading the appropriate strings based on the user's language preference. This requires deliberate design: every visible string in the app must reference the localisation data source rather than being hardcoded. Retrofitting localisation into a canvas app built with hardcoded strings is expensive.
Dataverse language packs: Dataverse supports multiple language packs — table display names, column labels, option set values, and business rule messages can all be localised. For model-driven apps, language packs provide UI localisation at the platform level — the app adapts to the user's language preference automatically for standard components.
Date, time, number, and currency formats: Power Platform respects user locale settings for date, time, number, and currency display. Builders should use Dataverse's native date/time and currency column types rather than storing these values as text — the platform handles locale-appropriate display automatically when the data is correctly typed.
Right-to-left language support: Canvas apps require explicit RTL (right-to-left) layout design for Arabic, Hebrew, and other RTL languages — the canvas designer does not automatically mirror layouts. Model-driven apps have better native RTL support through Dataverse language pack installation.
Performance and UX at Scale¶
Builders expect solutions that load fast and respond instantly — the same performance expectations users bring from consumer applications. Enterprise solutions must meet these expectations under realistic concurrent user loads, not just in single-user testing.
Canvas app performance: - App load time — the time from opening the app to the first interactive screen is the metric users notice most. Target under three seconds for the first screen. Optimise by deferring non-critical data loading, using concurrent load patterns, and minimising the number of connector calls on app start. - Delegation — canvas app queries that are not delegated to Dataverse execute locally against a maximum of 500 records by default. Every data query in a production canvas app must be verified for delegation compliance. Non-delegable queries against large tables are the most common canvas app performance failure in enterprise deployments. - Formula complexity — deeply nested Power Fx expressions evaluated on every user interaction create UI lag. Named formulas, intermediate variables, and deferred loading patterns keep the UI responsive. - Media and assets — large images, unoptimised icons, and media files embedded in canvas apps increase load times. Use appropriately sized assets and reference media from SharePoint or Azure Blob rather than embedding it in the app package.
Model-driven app performance: - Form load time — model-driven app forms load data from multiple related tables. Forms with excessive sub-grids, multiple business rules evaluating complex conditions, and heavyweight Client SDK scripts load slowly. Profile form load time before go-live and optimise the most impactful contributors. - View performance — views querying large tables without appropriate filters return excessive data and load slowly. Design views with sensible default filters; avoid views that return all records across large tables.
Power Pages performance: Power Pages serves external users who may have limited connectivity and higher performance expectations. Configure CDN (Content Delivery Network) for static assets, implement server-side caching for frequently accessed data, and minimise the number of Dataverse queries per page load.
Performance testing: Performance testing must be conducted against realistic concurrent user loads before go-live — not single-user testing in a development environment. Use load testing tools to simulate expected concurrent users and identify bottlenecks before they manifest in production.
UX Testing Before Go-Live¶
Builders expect that testing a solution means more than verifying that buttons work. Enterprise UX testing requires functional testing, usability testing, accessibility auditing, device and browser testing, and performance validation — all before users encounter the solution in production.
Functional testing: Verify that every feature works as specified — forms submit correctly, flows trigger, data is saved, errors are handled. This is necessary but not sufficient. Functional testing tells you the solution works; it does not tell you that users can use it effectively.
Usability testing: Test the solution with representative users — people who match the actual user population, not developers who built it. Observe them completing real tasks without guidance. Where they hesitate, make mistakes, or ask questions reveals design failures that no amount of developer testing will surface. Usability testing is the highest-return testing investment for adoption outcomes.
Accessibility audit: Conduct a formal accessibility audit before go-live — run the canvas app accessibility checker to completion, test keyboard navigation manually, test with a screen reader, and verify colour contrast across all screens. For regulated industries and public sector solutions, consider an independent accessibility audit by a specialist.
Device and browser testing: Test on the actual devices and browsers your users will use — not just the developer's laptop. Canvas apps must be tested on tablet and phone if mobile access is expected. Power Pages must be tested across the browser matrix relevant to your user population. Model-driven apps must be tested on supported browsers with supported configurations.
Performance validation: Validate performance under realistic load before go-live. Single-user performance in a development environment does not predict multi-user performance in production. Load test against expected concurrent user counts and validate that response times meet the agreed performance baseline.
Maturity Levels¶
| Level | Description | Suitable For |
|---|---|---|
| Basic | Single interface type. Default styling. No accessibility review. Desktop only. Tested by the developer. | Personal productivity and low-criticality internal solutions with a single user group |
| Intermediate | Interface type chosen deliberately. Responsive design for relevant form factors. Accessibility checker run and issues resolved. Basic usability testing with representative users. Performance validated under expected load. | Team and departmental enterprise solutions with defined user groups and moderate complexity |
| Advanced | Full interface strategy — multiple surfaces where appropriate (canvas, Teams, mobile, conversational agent). WCAG 2.1 AA compliance verified by audit. Formal usability testing. Performance tested under realistic concurrent load. Localisation implemented for relevant languages. Custom UI pattern implemented where required. Accessibility, performance, and UX reviewed as part of every release. | Mission-critical enterprise solutions with diverse user populations, regulated industries, or global deployment |
Safe Zone¶
Solutions used by a small internal team on desktop, with no accessibility compliance requirement, no mobile users, and no external users, can operate at Basic maturity.
Any solution that meets one or more of the following must reach Intermediate or Advanced maturity before Go-Live: - Serves users with disabilities or operates in an industry with legal accessibility requirements - Is used on mobile devices — phones or tablets - Is accessed by external users — customers, partners, citizens - Serves users in multiple languages or regions - Has more than 50 concurrent users - Is customer-facing or publicly visible - Is a mission-critical operational tool where UX failures have business impact
Common Mistakes¶
- Wrong interface type chosen — building a complex data management solution in canvas when model-driven was the right choice, or building a simple task app in model-driven when canvas would have been faster and more appropriate. The interface type decision, made incorrectly at the start, is expensive to reverse.
- No accessibility review — solutions deployed without running the accessibility checker, without keyboard navigation testing, and without screen reader verification. Discovered during a compliance audit or reported by a user with a disability after go-live.
- Desktop-only design tested on mobile too late — a solution designed for desktop that breaks on phone screens, discovered when a field worker tries to use it on site. Responsive design is significantly cheaper at design time than as a retrofit.
- Hardcoded strings in canvas apps — labels, messages, and error text hardcoded in English. Localisation requirements emerge after go-live and require rebuilding the string management architecture.
- Non-delegable queries in production — canvas app queries that work correctly in development with small datasets silently return incomplete data in production. Users make decisions based on incomplete information without knowing it.
- Performance tested by one developer, used by five hundred users — solutions that perform acceptably for a single developer in a development environment that degrade severely under concurrent production load.
- Usability tested by the builders — developers who know exactly how the solution works cannot find the usability failures that real users encounter. "It works" and "users can use it effectively" are different outcomes.
- PCF controls deployed without accessibility — custom PCF controls that provide powerful UI capability but are completely inaccessible to keyboard and screen reader users, breaking the model-driven app's otherwise strong accessibility baseline.
- Teams integration as an afterthought — solutions built for standalone access that are later requested in Teams, requiring significant rework. Teams integration planned from the start requires a fraction of the effort.
- Custom mobile built when Power Apps mobile was sufficient — significant investment in a React Native or Flutter app for a scenario that Power Apps mobile with a well-designed canvas app would have served. Custom mobile has a high development and maintenance cost; validate the requirement thoroughly before committing to it.
Readiness Checklist¶
Interface Strategy - [ ] Interface type selected deliberately — canvas, model-driven, Pages, Teams, custom, or combination — choice documented and justified - [ ] User population defined — roles, devices, connectivity, language requirements - [ ] Teams integration assessed — is this the right delivery surface for this user population? - [ ] Mobile requirements assessed — Power Apps mobile sufficient or custom mobile required? - [ ] External user requirements assessed — Power Pages sufficient or custom web app required?
Canvas Apps (if applicable) - [ ] WYSIWYG verified — app in studio matches app at runtime - [ ] WYSIWYIS applied — displayed values persist to data model, not UI-only transformations - [ ] Responsive layout implemented for all required form factors - [ ] Offline capability designed in if required — not retrofitted - [ ] Delegation compliance verified for all data queries - [ ] App load time measured and meets performance target - [ ] Media and assets optimised
Model-Driven Apps (if applicable) - [ ] Form load time profiled — heavyweight scripts and sub-grids optimised - [ ] Views designed with appropriate default filters - [ ] Business process flows wired to automation where stage transitions trigger logic
Power Apps Code Apps (if applicable) - [ ] React component architecture designed — not a canvas app with code pasted in - [ ] Source control configured at component level - [ ] Build and deployment pipeline established
PCF Controls (if applicable) - [ ] ARIA attributes implemented — screen reader support verified - [ ] Keyboard navigation implemented and tested - [ ] Version-controlled in source as TypeScript - [ ] Included in solution and deployed via pipeline
Power Pages (if applicable) - [ ] Table and column permissions designed — minimum necessary external access - [ ] CDN configured for static assets - [ ] Caching implemented for frequently accessed data - [ ] Browser and device matrix tested
Teams Integration (if applicable) - [ ] App manifest configured correctly - [ ] Tested in Teams desktop, web, and mobile clients - [ ] Adaptive cards tested for approval and notification flows
Mobile (if applicable) - [ ] Power Apps mobile — responsive design tested on target devices - [ ] Offline capability — sync and conflict resolution tested - [ ] Push notifications tested end-to-end - [ ] Custom mobile — Entra ID authentication (MSAL) configured, Dataverse Web API access tested
Custom Web UI (if applicable) - [ ] Entra ID app registration configured with correct API permissions - [ ] Dataverse Web API access tested with user-appropriate security roles - [ ] Custom APIs tested from external context - [ ] Authentication flow tested for all user types
Accessibility - [ ] Canvas app accessibility checker run to completion — all issues resolved - [ ] Keyboard navigation tested manually — every task completable without a mouse - [ ] Screen reader tested (NVDA, JAWS, or VoiceOver) - [ ] Colour contrast verified — 4.5:1 for normal text, 3:1 for large text - [ ] Focus management verified — no lost or trapped focus states - [ ] Error messages descriptive and not colour-only
Internationalisation (if applicable) - [ ] All visible strings in canvas apps reference localisation data source — no hardcoded text - [ ] Dataverse language packs installed for required languages - [ ] Date, time, number, and currency using typed Dataverse columns — not text - [ ] RTL layout implemented if required
Performance - [ ] Load time measured under single-user conditions - [ ] Load testing conducted under realistic concurrent user load - [ ] Performance meets agreed baseline before go-live
UX Testing - [ ] Usability testing conducted with representative users — not developers - [ ] Functional testing completed across all user roles - [ ] Accessibility audit completed - [ ] Device and browser matrix tested - [ ] Post-release monitoring planned — adoption metrics, error rates, support volume
Part of the DIALOGE Framework — powerplatform.wiki Last updated: March 2026 Last reviewed: March 2026