Microsoft Power Apps

What Power Apps is

Microsoft Power Apps is a business application development platform with visual tools, formulas and data connections. It supports canvas and model-driven applications within Power Platform. Development can combine low-code configuration with professional extensions.

A useful application organises an interaction: what a person needs to do, what they see, what they may change and how they know they have finished. Screens are only part of the solution. Consistent data, rules, permissions and a way to handle errors and later changes are also required.

Reference documentation: What is Power Apps?.

Origins and product development

Microsoft introduced PowerApps on 30 November 2015 to make business applications and service connections more accessible. General availability followed on 1 November 2016 alongside Microsoft Flow. Its scope expanded from visual construction towards data management, processes and assisted development.

In March 2021 Microsoft introduced Power Fx, an Excel-based low-code formula language. In May 2022 it announced Power Pages for website creation; former Power Apps Portals belong in that history rather than being treated as a third current app type equivalent to canvas and model-driven apps.

Name and catalogue changes explain differences between manuals. Before reusing a solution, identify its application type, data service and documentation date. Similar names do not establish identical permissions or licensing conditions.

Reference documentation: Introducing Microsoft PowerApps, November 2015 · General availability of PowerApps and Flow, November 2016 · Introducing Microsoft Power Fx, March 2021 · Power Platform at Build 2022: Power Pages.

Canvas and model-driven applications

Canvas apps provide control over screens and component properties through Power Fx and connectors. Model-driven apps organise the experience around Dataverse tables, relationships, forms and views. Their consistency comes from shared structure, while canvas apps offer greater visual control.

Choose according to the dominant need. A short, highly specific interaction may warrant a custom screen. Processes with many related records may benefit from model-based navigation and forms. Maintenance and usability belong in the decision.

Both approaches require defined data and permissions. A visual prototype should not accidentally determine who may view or change information. Test with actual user roles before widening access.

Reference documentation: Model-driven app overview and canvas comparison.

Dataverse and data design

Dataverse stores information in tables, rows and columns, with standard and custom tables and role-based access controls. It provides shared data management for Power Platform applications. Its product development includes Dataverse for Teams, announced as generally available in November 2020.

A simple materials-request model can separate sites, materials and requests. Each needs stable identifiers. Relationships avoid repeated names and allow a material to be withdrawn without deleting historical requests that referenced it.

Define each status and who may change it. “Prepared”, “approved” and “delivered” describe different events. Reducing them to one indicator removes the application’s ability to explain outstanding work and the evidence supporting its outcome.

Reference documentation: What is Microsoft Dataverse? · Dataverse for Teams, November 2020.

Comprehensible formulas and rules

Power Fx expresses logic through formulas and draws on Excel’s familiarity. That similarity supports learning, but an application must handle interaction, state and shared data. Spreadsheet knowledge helps without removing the need to test complete behaviour.

A quantity rule should distinguish blank, zero, negative and above-limit values. A comprehensible message explains how to correct the input. Concealing an error or replacing it with a default can make an invalid request appear valid.

Separate presentation rules from process rules. Changing a status colour may improve readability, but approval permission belongs where the data is controlled. Documenting accepted and rejected input examples supports change verification and maintenance handover.

Reference documentation: Introducing Microsoft Power Fx, March 2021.

Sharing apps and protecting data sources

Sharing a canvas app does not automatically grant every permission on its data sources. Microsoft requires review of Dataverse tables and other resources, such as connected Excel files. Application and data controls must work consistently.

Test requester, reviewer and administrator roles. Checks should cover reading and modification through the screen and through other accessible routes to the resources. A visually filtered list does not establish data isolation.

Before handover, specify who adds or removes users and what happens when roles change. Access appropriate for a pilot may cease to be suitable as scope expands. A source-and-role inventory supports that review.

Reference documentation: Share a canvas app and its data sources.

Queries, delegation and incomplete results

Delegation processes a query at the data source. Where an operation cannot be delegated, Power Apps may work on only a local subset. Current documentation specifies a 500-record default and a configurable limit up to 10,000; raising that value alone does not repair query design.

The practical risk is an apparently correct but incomplete answer. A pending-request search may return zero where relevant records fall outside the retrieved subset. That result should not automatically be interpreted as absence of work.

Test beyond the configured limit and place known cases near the end of the dataset. Compare with the source and examine editor warnings. In an auxiliary OSH report, record coverage is part of data quality alongside formatting.

Reference documentation: Understand delegation in canvas apps.

Mobile and offline use

Canvas apps can work offline through Power Apps Mobile, using Dataverse-specific capabilities or limited local storage functions. Documentation excludes offline canvas-app operation in browsers. Opening the same screen on a phone does not itself provide synchronisation.

Define what is downloaded, how long it remains usable and what happens when connectivity returns. A reference current at the start of a shift may have changed. Screens should distinguish pending local data from data confirmed at the source.

Test loss of coverage, app closure, reconnection and concurrent modification. Verify that requests are neither lost nor duplicated. For preventive materials, version and date displays help identify content requiring an update before use.

Reference documentation: Develop offline-capable canvas apps.

Accessibility and responsive design

Microsoft provides responsive-design guidance and an accessibility checker for canvas apps. Guidance addresses labels, contrast, reading and navigation. These resources support review, but using them does not automatically certify the complete experience.

Defra’s accessibility guidance identifies known Power Apps issues and points to checks for individual controls. It reinforces the need to test the actual application rather than assume accessibility from the platform alone.

For an OSH support app, test magnification, keyboard navigation, error messages and small-screen buttons. Avoid communicating status solely through colour. Users should be able to correct an entry without losing their whole request and confirm what has been saved.

Reference documentation: Build responsive canvas apps · Create accessible canvas apps · Defra: Power Apps accessibility guidance.

Assisted creation and generative pages

Generative pages let makers describe a model-driven app page in natural language and select reference data. The system generates React code and supports refinement. Some connections, including selected connectors and custom APIs, are documented as preview features.

Generation may accelerate an initial interface, but the result needs review like any development. Check fields, write operations, permissions and empty-data behaviour. An attractive screenshot does not establish that the logic meets its purpose.

For a pilot, request a bounded screen and define acceptance examples before generation. Compare the proposal with those examples, record adjustments and verify using different roles. Review data saved at the source as well as screen output.

Reference documentation: Generate a page using natural language.

Testing, publication and maintenance

Power Apps provides checking, event-monitoring and testing resources. Test Studio defines tests through expressions or recorded interactions. Power Platform application lifecycle management covers solution development, testing, deployment and operation.

A complete test starts with a need and ends with a persisted result. For a request, verify single creation, access for the appropriate reviewer and prevention of unauthorised modification. Include connection failures and outdated data.

Handover should preserve an identifiable version, an owner and a change procedure. Test corrections before affecting live use. Documenting sources, fields and dependencies lets another person maintain the app without reconstructing its original decisions.

Reference documentation: Testing and monitoring in Power Apps · Power Apps Test Studio · Application lifecycle management in Power Platform.

Licensing and announced development changes

The catalogue distinguishes development and testing from licensing for running business applications. Connectors, Dataverse and administration capabilities must be checked for actual users. One account’s ability to build an app does not establish organisation-wide usage rights.

Microsoft schedules unmanaged developer environments to stop being created on 15 November 2026, suspend on 15 December and delete on 15 January 2027. These dates remain future to this review.

Budget for users, data, administration and maintenance. Before building, check whether a form or existing capability meets the need. A custom app adds value where it improves a specific interaction and the team can sustain it beyond the pilot.

Reference documentation: Power Apps licensing and pricing · Announced changes to developer environments.

Applications in occupational safety and health

In OSH, a bounded application can collect material requests, organize proposed session topics or provide access to an approved catalog. Its value lies in structuring an interaction and reducing incomplete information. Sabentis proposes these examples as auxiliary support; checking whether the corporate system already handles the process prevents duplicate records or a second version of safety information.

Worked example and checks

An application could let employees request campaign materials by specifying site, language and quantity. The team would receive structured records and confirm requirements before preparing materials, without turning the application into a risk assessment system or claiming specialist safety functionality.

1. Define three datasets: current materials, authorized sites and requests, with stable identifiers.
2. Design a screen for selecting the material, language and quantity, displaying the resource version.
3. Separate requester and reviewer permissions; test them with accounts for each role.
4. Validate quantities, required fields and selection of withdrawn materials, displaying understandable messages.
5. Check that a saved request appears once in the source and that its status matches the application.

The trial should include connection loss, double-clicking and catalog changes while a form remains open. A success message should appear only after saving completes. The expected outcome is a traceable request that can be reviewed, without promising availability, dispatch or approval that the process has not confirmed. Retain test records separately from real requests and explain how users can recognize an unsaved item.

Limitations and conditions of use

Building a screen is only part of the work. Validate permissions, rules, data and failure behavior; connector availability, capacity and features depend on configuration and licensing, and the application needs maintenance as processes change.

Hiding a button or filtering a screen does not by itself enforce data access. Connections and permissions must be checked at the relevant source. A prototype may also fail as volumes grow or columns and relationships change. Licensing, connectors and capacity should be verified for actual users, not only the account building the application.

Choosing and complementing the tool

Choose Power Apps where there is a defined process, compatible sources and administrators within the Microsoft ecosystem. Power BI can complement aggregate analysis of requests; Excel can help prepare an initial catalog, without turning scattered copies into parallel sources. For an occasional lookup, consider the cost of maintaining a complete application.

Handover should identify a functional owner, technical owner, field dictionary and change procedure. Separating development, testing and actual use allows changes to be checked before affecting people who rely on the process. A finished appearance does not demonstrate that these aspects are resolved. Include recovery and support arrangements so a missing connection does not leave requests silently unprocessed.

Frequently asked questions

Are canvas and model-driven apps equivalent?

No. The former prioritizes layout control; the latter organizes the experience around data and relationships in Dataverse.

Does sharing an app grant access to all its data?

Not necessarily. Permissions for the sources and resources it uses must be configured.

Does low code mean no maintenance is required?

No. Changes to processes, permissions, connections or data may require adjustments and further checks.