Overview of connectors for canvas apps
Data is at the core of most apps, including the data you build in Power Apps. Data is stored in a data source, and you bring that data into your app by creating a connection. The connection uses a specific connector to talk to the data source. Power Apps has connectors for many popular services and on-premises data sources, including SharePoint, SQL Server, Office 365, Salesforce, and Twitter. To get started adding data to a canvas app, see Add a data connection in Power Apps.
A connector may provide tables of data or actions. Some connectors provide only tables, some provide only actions, and some provide both. Also your connector may be either a standard or custom connector.
If your connector provides tables, you add your data source and then select the table in the data source that you want to manage. Power Apps both retrieve table data into your app and updates data in your data source for you. For example, you can add a data source that contains a table named Lessons and then set the Items property of a control, such as a gallery or a form, to this value in the formula bar:
You can specify the data that your app retrieves by customizing the Items property of the control that shows your data. Continuing the previous example, you can sort or filter the data in the Lessons table by using that name as an argument for the Search and SortByColumn functions. In this graphic, the formula to which the Items property is set specifies that the data is sorted and filtered based on the text in TextSearchBox1.
For more information about how to customize your formula with tables, see these articles:
Understand data sources in Power Apps
Generate an app from Excel data
Create an app from scratch
Understand tables and records in Power Apps
To connect to data in an Excel workbook, it must be hosted in a cloud-storage service such as OneDrive. For more information, see Connect to cloud-storage from Power Apps.
If your connector provides actions, you must still select your data source as you did before. Instead of selecting a table as the next step, however, you manually connect a control to an action by editing the Items property of the control that will show your data. The formula to which you set the Items property specifies the action that retrieves data. For example, the app won't retrieve any data if you connect to Yammer and then set the Items property to the name of the data source. To populate a control with data, specify an action such as GetMessagesInGroup(5033622).messages.
If you need to handle custom data updates for action connectors, build a formula that includes the Patch function. In the formula, identify the action and the fields that you'll bind to the action.
For more information about how to customize your formula for custom updates, see these articles:
To work with dynamic schema, you can use an experimental feature called Dynamic schema. Dynamic schema refers to the possibility that the same action may return a different table with different columns. Conditions that may cause the columns in the tables to differ include the action input parameters, the user or role that's executing the action, and the group in which the user is working, among others. For example, SQL Server stored procedures may return different columns if run with different inputs, or an Azure DevOps instance may use custom fields that aren't available by default. For working with dynamic schema, the connector documentation shows The outputs of this operation are dynamic. as the return value. For more information about how to work with dynamic schema in Power Apps, see working with dynamic schema in Power Apps (experimental)
This table has links to more information about our most popular connectors. For a complete list of connectors, see All connectors.
|Microsoft Dataverse||Cloud storage **|
|Microsoft Translator||Office 365 Outlook|
|Office 365 Users||Oracle|
** Applies to Azure Blob, Box, Dropbox, Google Drive, OneDrive, and OneDrive for Business
Standard and custom connectors
Power Apps provides standard connectors for many commonly used data sources. If Power Apps has a standard connector for the type of data source that you want to use, you should use that connector. If you want to connect to other types of data sources, such as a service that you've built, see Register and use custom connectors.
All standard connectors
Standard connectors don't require special licensing. For more information, see Power Apps Plans.
You can ask questions about a specific connector in the Power Apps forums, and you can suggest connectors that you want to add or other improvements to make in Power Apps Ideas.
Security and types of authentication
As you author your app and create a connection to a data source, you may see that your choice of connector allows you to use different ways to authenticate. For instance, the SQL Server connector allows you to use Azure AD Integrated, SQL Server Authentication, and Windows Authentication. Each type of authentication has different levels of security associated with it. It's important to understand what information and rights you share with users who use your application. The primary example in this article is SQL Server, however the principles apply to all types of connections.
For detailed information about security considerations when using a relational database server (such as Microsoft SQL Server, or Oracle) as the data source for an app, see Use Microsoft SQL Server securely with Power Apps.
Azure AD Integrated
This is a secure type of connection. For example, SharePoint uses this type of authentication. SQL Server also allows for this type of authentication. When you connect, the Azure AD service identifies you separately to SharePoint on your behalf. You don't have to supply a username or password. As an author you can create and work with the data source with your credentials. When you publish your application and your application user logs in, they do so with their credentials. If the data is appropriately secured on a back-end your users can only see what they're authorized to see based on their credentials. This type of security allows you to change rights for specific application users on the back-end data source after the application has been published. For instance you can grant access, deny access, or refine what a user or set of users can see all on the back-end data source.
Open-standard authorization (OAuth)
This type of connection is also secure. For example Twitter uses this type of authentication. When you connect, you must supply your user name and password. As an author you can create and work with the data source with your credentials. When you publish your application and your application user logs in, they must also supply their credentials. Therefore this type of connection is secure as your users must use their own credentials to access the data source service.
SQL User name and password authentication
This type of connection isn't secure because it doesn't rely on end-user authentication. It should only be used in cases where you can safely assume that everyone who has access to this connection can see and use all of the data to which the connection provides access. You can't reliably lock down portions of the data accessible within the connection. For instance, if the connection allows access to a single table, you can't rely on a userID to filter and only show data for that specific user within that table. For a reliable security, use more secure connection such as Azure AD Integrated.
In SQL Server, this type of connection is called SQL Server Authentication. Many other database data sources provide a similar capability. When you publish your application, your users don't need to supply a unique user name and password. They're using the user name and password you supply when you author the application. The connection authentication to the data source is Implicitly Shared with your users. Once the application is published, the connection is also published and available to your users. Your end users can also create applications using any connection using SQL Server authentication that is shared with them. Your users can't see the user name or password, but the connection will be available to them. There are valid scenarios for this type of connection. For instance if you have a read-only database that is available to everyone in the company. Reference data scenarios (for example, a corporate calendar) can be useful for this kind of connection. More information: Use Microsoft SQL Server securely with Power Apps
Secure Implicit Connections (experimental)
Power Apps now has support for Secure implicit connections (experimental). The secure implicit shared connections are more secure than the existing implicit connections. Power Apps implicitly shared connections are ones that use a fixed credential such as a SQL Server connection string rather than the end user's specific credentials such as AAD. With this feature, connections are no longer directly shared with the users of Power Apps. Instead, a proxy connection object that only grants access to the underlying resource such as a specific SQL server table is shared. End user authors can't create new applications with either the connection or the proxy connection. This feature also limits the end user to such actions as get, put/patch, and delete that are defined in the corresponding app. The result is that end users who are also authors can't create new applications with either the connection or the proxy connection object.
While in preview, an app author must opt-in to use this feature. Eventually, this feature will be on for all apps. With the experimental preview switch turned on for a given Power Apps app, all implicit connections in the app will automatically use this feature.
Enable secure implicit connections for new app
Sign in to Power Apps and create a new app that uses an implicitly shared connection:
In Power Apps Studio, on the command bar, select Settings > Upcoming features.
Select the Experimental tab.
Set the toggle for Secure implicit connections to On
When you're done, publish the app.
To share with different users, see Sharing.
Enable secure implicit connections for an existing app
Open an existing app open for editing with implicitly shared connections that has previously been published:
- On the command bar, select Settings > Upcoming features.
- From the Experimental tab, set the toggle for Secure implicit connections to On.
- Save and publish the app.
Once the app is published follow these steps to verify that sharing works correctly:
Check if connections are shared with co-owners. If you don't want an end-user to get a connection, then uncheck the Co-owner checkbox.
To verify the feature works correctly, share the app with a different user who isn't an owner. Once you have shared the app, check the Connections list in the Dataverse tab in Power Apps for that user. Verify that the user doesn't have a connection available.
Open the Sharing panel to change the end-user's right to the connection. Choosing the X will remove the user's access to the connection.
Use apps with a new secure implicit connection
When your app is republished and shared, then end-users won't have access to the connection but will work with the hidden proxy connection. They won't be able to create a new app based on your original connection.
- All types of implicitly shared connection work such as action and tabular.
- Server and database names are hidden in network traces but visible in the consent dialog. Column names are not hidden.
- For tabular connectors, we only limit CRUD actions such as Get, Post, Put, or Delete. If you have permissions to Put then you have access to Post.
- Action based connectors limit based on the specific API being used in the application.
- Warnings are still enabled in sharing. The warning around implicitly shared connections still warns while in private preview. However, your connection with this feature is secure – despite the warning.
This type of connection isn't secure because it doesn't rely on end-user authentication. Use Windows authentication when you need to connect to a data source that is on-premises. An example of this type of connection is to an on-premises server that has a SQL Server. The connection must go through a gateway. Since it goes through a gateway, the connector has access to all of the data on that data source. As a result, any information that you can access with the Windows credentials you supply are available to the connector. And once the application is published, the connection is also published and available to your users. This behavior means that your end users can also create applications using this same connection and access the data on that machine. Connections to the data source are also Implicitly Shared with users that the app is shared with. This type of connection may be valid when your data source only lives on an on-premises server and the data on that source is freely shareable.
Data sources in solutions
Solutions are used for application lifecycle management and provide additional capabilities for managing the lifecycle of data sources. If a canvas app is in a solution, connection references and environment variables may be created to store information about the data sources. This ensures data sources can be changed or re-established when solutions are migrated to different environments.
Rename data sources in apps
To learn about renaming data sources in an app, and the difference between tabular and action-based data sources, go to Rename Power Apps action-based data sources.
Connection consent dialog
When users open an app that uses connectors for the first time, they'll see a "connection consent" dialog for the following purposes.
To inform users about the data sources accessed by the app.
To outline the actions a connector may, or may not perform in an app. For example, for apps using the Office 365 Users connector, this could be the following.
- This app will be able to:
- Read your full user profile
- Read the full profile of all users
- It won't be able to:
- Modify or delete any user-profile information
- This app will be able to:
To capture end-user consent to connect to the data sources that the app uses.
To facilitate manual end-user authentication, when needed.
For some connections, Power Platform can automatically authenticate a user to access a data source. However, if the automatic sign-in fails, this dialog prompts users to fix a connection by manually signing in. Power Platform can only attempt automatic sign-in for a connection when a data source pre-authorizes Microsoft’s Azure API connections service principal, granting it permission to perform single sign-on for a user when a connection is created. For more information on single sign-on, see What is single sign-on (SSO)?
The following image is an example of the connection consent dialog for an app connecting to a SharePoint site.
For select connectors, admins can suppress this dialog, and consent on behalf of end users to connect to a data source. The following table explains which types of connectors the consent dialog may be suppressed for an app.
If an admin suppresses the consent dialog but the platform can’t perform single-sign-on for an end-user, the dialog will be presented to the user when they launch the app.
|Connector type||Consent dialog suppressible?||Reference|
|Microsoft first-party connectors that support single sign-on (such as SharePoint, Office 365 users)||Yes||Power Apps admin cmdlet|
|Connector accessing a non-Microsoft, third-party service, such as Salesforce||No||Not applicable|
|Custom connectors using OAuth with Azure Active Directory as the identity provider. These are custom connectors built by organizations, and are only accessible by the users within the organization (for example, built by Contoso for only Contoso users)||Yes||Manage Connections|
Microsoft Power Platform is only able to suppress the consent dialog for connections to data sources where:
- There isn’t an obligation by the data source to show an explicit consent UI.
- The data source pre-authorizes Microsoft’s Azure API connections service principal to enable single-sign-on.
- An admin configures an app to suppress the consent for the preceding connections.
The pre-authorization of Microsoft’s Azure API connections service principal exists for Microsoft's first-party data sources, and may be configured by custom applications registered in an Azure AD tenant that are used by custom connectors. An admin manages consent suppression on a per-app basis (as opposed to connector basis), so suppression is managed at the most granular app experience level—this level of granularity prevents consent suppression for an organization’s "approved apps" from inadvertently suppressing consent for apps that aren't approved or reviewed.
Submit and view feedback for