How does Power Apps work? A canvas Power App is a set of screens and Excel-style formulas that runs in a web browser or the Power Apps mobile app. It reaches your data through connectors under someone’s sign-in. Whose sign-in it is decides who can see what. This guide follows an app from the moment someone opens it, through its connectors, to a real client build and the part AI plays.
Table of Contents
What happens when someone opens a Power App?
When someone opens a canvas app, Power Apps loads it, works out its formulas and starts requesting records from its data sources. Each request goes through a connection that uses a connector to talk to the data source. Microsoft sets out this model in its overview of connectors for canvas apps.
For a typical app built on a SharePoint list, the sequence runs in five steps.
- The user opens the app from a link, from Microsoft 365 in a browser or from the Power Apps mobile app.
- The first time, a consent dialog lists the data sources the app uses and asks the user to agree to connect to them.
- As the screens draw, Power Apps works out the values the controls show from their formulas.
- A gallery or form requests records through the connector. SharePoint returns only what that user’s account is allowed to see.
- When the user saves a record, a formula writes the change back to the data source.
Step four is also where delegation decides who does the work. When a formula translates into a query the data source understands, the data source runs it and sends back only the matching records. When the formula can’t be translated, Power Apps fetches the first 500 records by default and works on those alone, Microsoft says in its delegation overview. What that does to the accuracy of an app is covered in our Power Apps for business guide.
A running app doesn’t automatically pick up changes other people make to the data while it is open. Makers add a Refresh formula wherever fresh data matters.
What are the building blocks of a Power App?
A canvas app is made of screens. Each screen holds controls such as galleries, forms and buttons. Every control has properties whose values come from formulas. Think of a control property as a cell in an Excel worksheet whose formula recalculates automatically as the values it depends on change.
Buttons have no Excel equivalent. Selecting one runs a sequence of actions, such as moving to another screen or updating records in a data source.
What are connectors in Power Apps?
A connector is the bridge between a Power App and a service such as SharePoint, SQL Server, Outlook or Salesforce. Under the hood it is a wrapper around an API. A connection is the stored credential the connector uses, such as a person’s SharePoint sign-in.
Some connectors give the app tables of records to show and edit, some offer actions such as sending an email and some do both.
Microsoft’s custom connectors overview counts over 1,000 connectors across Logic Apps, Power Automate, Power Apps and Copilot Studio. Power Apps draws on the part of that list available to it.
Microsoft recommends a maximum of 10 connectors per app. Going past that number can slow the app’s launch and cause problems when it is saved.
Each prebuilt connector also sits in a standard or premium tier that affects the licence. For the question of whether a connector is just an API, our API connector guide has the short answer: the API is the door and the connector is what walks through it.
When do you need a custom connector?
A custom connector lets an app reach a system that has an API but no prebuilt connector, such as an in-house job system or a niche industry platform. Once you describe the API, for example with an OpenAPI definition or a Postman collection, the app uses the custom connector through a connection, the same way as a prebuilt one.
For Power Apps the service has to offer a stable HTTP REST API. A connector created in Power Apps also appears in Power Automate and Copilot Studio. A custom connector makes an app premium, which usually means a standalone Power Apps licence for each person who runs it.
Whose sign-in does a Power App use to reach your data?
Whose sign-in a Power App uses depends on the connector and on how the connection was set up. Connectors such as SharePoint sign each person in as themselves when the app uses them directly, so the data source applies that person’s own permissions. A shared connection, such as SQL Server authentication, signs everyone in with the account the app maker connected with.
Where each person signs in with Microsoft Entra ID, as with SharePoint, rights can be changed in the data source for specific users after publishing, without touching the app.
The table sets out the three main sign-in types a canvas app meets and what each one means for access.
| Sign-in type | Example connectors | Whose identity the data source sees | What controls access |
|---|---|---|---|
| Microsoft Entra ID | SharePoint, SQL Server with Entra authentication | Each app user’s own | Data source permissions, changeable after publishing |
| OAuth to another service | X, formerly Twitter (Microsoft’s example) | Each app user’s own | That service’s permissions |
| Shared connection | SQL Server authentication, shared Windows authentication through a gateway | The account the maker connected with, for everyone | That account’s rights and, for a secure implicit connection, the app’s published limits |
Microsoft tightened shared connections in January 2024. Shared connections created after that are secure implicit connections, where the app talks to a proxy and users don’t receive the connection itself. Microsoft’s listed limitations include that secure implicit connections don’t support apps published to the whole organisation and aren’t set properly when an app is imported into another environment through a connection reference. Apps published before January 2024 need the secure implicit connections setting turned on and the app republished. Their old connections also need unsharing from users who shouldn’t have them.
Even with a secure implicit connection, the data source behind a shared connection cannot tell one user from another. Microsoft’s SQL Server security guide for Power Apps says filtering and other client-side operations can’t be relied on to keep data secure. Its answer is server-side security such as row-level security in SQL Server, with each user signing in through Microsoft Entra ID. An app that hides rows with a filter has hidden them, not protected them.
Server-side security matters most where the records are personal. The Office of the Australian Information Commissioner’s notifiable data breach statistics for 2025 show health service providers lodged more notifications than any other sector, with 225 of the 1,205 notifications received that year.
What does a Power App look like in a real client build?
A Sydney mental health provider we work with keeps its client information in a Power App built on SharePoint lists. Between 10 and 50 staff use it and the lists hold thousands of client records. A Power Automate flow keeps the records current without anyone retyping them.
New client details arrive through Microsoft Forms, web form submissions and email. The flow matches each one to an existing client and updates that record, or creates a new client when nothing matches. Before the flow, staff updated client details by hand. Automating that work saves the team about 5 hours a week.
Access is set in SharePoint, with permissions by team or role. Because the SharePoint connector signs each staff member in as themselves, the list returns only the clients that person is permitted to see. The restriction holds whether someone uses the app or opens the list in SharePoint.
Our patient form follow-up case study covers a different project for the same provider. Our comparison of where the logic should live explains why updates that run unattended, like the provider’s record updates, sit in a flow and not in the app. Scoping that split is part of our Power Apps development work.
Where does AI fit in how Power Apps works?
AI changes how an app gets built. Microsoft’s Copilot in Power Apps overview says Copilot can generate an app and its data model from a plain-language description of the business need. Copilot builds that data model as Dataverse tables, which need premium Power Apps licensing rather than the rights included with Microsoft 365.
The Plans feature in Power Apps goes further. From a description it generates a wider solution that can include Dataverse tables, apps, Power Automate flows and Copilot Studio agents. Some Copilot features are previews that Microsoft says aren’t meant for production use. Availability also varies by region.
A generated canvas app follows the same connector, sign-in and delegation rules as one built by hand.
For a sense of how far AI has spread in Australian business, the Australian Bureau of Statistics’ Characteristics of Australian Business 2024-25 found 12% of employing businesses used AI.
Frequently asked questions
Can users see data in a Power App that they can’t see in SharePoint?
No, not if the app reads a SharePoint list through the person’s own SharePoint connection. The connector signs each person in with their own account. SharePoint then applies that person’s permissions to every request made through that connection. The risk runs the other way: an app that hides records with a filter still leaves them open to anyone with access to the list itself.
Why does my Power App only show 500 records?
Usually the formula behind the gallery can’t be delegated, so Power Apps works only on the records it has already retrieved. Microsoft puts the default at 500 records. A yellow delegation warning often marks the problem, but not always. Our Power Apps for business guide’s limitations of Power Apps section explains what the limit does to an app’s results.
How many connectors can one Power App use?
Microsoft recommends no more than 10 connectors in one canvas app. Past that point, the app can be slower to launch and can run into problems when it is saved. Most business apps need far fewer. An app that seems to need more is often trying to do two jobs.
Does a Power App store its own data?
A Power App’s records normally stay in the service it connects to, such as a SharePoint list, Dataverse or SQL Server. The app itself holds the screens and formulas. Working copies the app builds while it runs sit in memory unless the app is built to save them to the device. Our Power Apps for business guide covers where a Power App keeps its data.
Will AI replace Power Apps?
AI is more likely to change how a Power App gets built than to replace it. Microsoft has built Copilot into Power Apps to draft an app from a description. Someone in the business still has to decide who should see which records.
What to check before you build a Power App
Before any screen is designed, three questions decide most of how a Power App will behave: which data source holds the records, which connectors the app needs and whose sign-in each connection will use. Those three answers shape the screens, the licence and the security model.
OfficePro Consulting can work through those three questions with you. Start with a free initial conversation.
