Identify the core components of Microsoft Power Platform

Skill 2.2: Describe connectors

Connectors are the Power Platform components that allow Power Apps and Power Automate to interact with outside applications, services, and data files and utilize their data. Hundreds of public connectors are available to Power Platform users, and for those applications and services that are not supported, it is possible for developers to create custom connectors.

A connector is a proxy wrapper that Power Platform tools use to access an application programming interface (API) provided by an application or service. Many applications and cloud services have the necessary APIs, and the Power Platform connectors function as proxies, or intermediaries between the outside APIs and the internal Power Platform tools. The connector, in its role as a proxy, authenticates to the outside application or service and then provides Power Apps and Power Automate with access to its data.

Describe triggers, including trigger types and where triggers are used

Triggers are components in Power Automate that cause a flow to begin running. Some triggers can be schedule based, so that the flow launches at a specific date and time; others can be event based, so that the flow launches when a user performs a specific task, or even manual, in which a user launches a flow by clicking or tapping a button. However, there are also triggers associated with data connectors, so that changes involving a data source cause a flow to launch.

For example, the connector for SharePoint includes triggers that can launch a flow when an item is created, when an item is created or modified, or when a file is created in a folder, as shown in Figure 2-14.

FIGURE 2-14 The Build an automated flow dialog box from the Power Automate portal

When a developer creates an automated flow—that is, a flow that is launched by an outside event—two types of triggers are available:

• Polling triggers—Connect to the outside data source at scheduled intervals to check for new data, launching the flow using that new data as input when it becomes available

• Push triggers—Listen at a server endpoint for notifications that a specific event has occurred on an outside application or service, launching the flow when the notification arrives

When developers create instant flows or scheduled flows, they still use triggers, but these triggers function autonomously. An instant flow uses a trigger that is tied to a button or other control in an app that requires user interaction to launch the flow. Scheduled flows use a trigger that the developer configures to activate at a specific date and time, using the interface shown in Figure 2-15.

FIGURE 2-15 The Build a scheduled flow dialog box from the Power Automate portal

Describe actions

Actions are specific modifications made to the data provided by an outside application or service. In Power Automate, actions are usually the result of a trigger, but developers can use them in Power Apps as well. For example, when a developer creates a manual trigger in a Power Automate flow, the next step is to select an action that will be the result of the trigger, as shown in Figure 2-16. Apps and flows can include multiple actions using different connectors to perform a sequence of tasks.

FIGURE 2-16 The Choose an action dialog box in the Power Automate portal

Actions can cause an application or service to perform a task, such as send an email, or modify the source data in some way. For example, Figure 2-17 contains the interface for an action that deletes a row from a specific Excel spreadsheet.

FIGURE 2-17 The Delete a row action for Excel in the Power Automate portal

The developer uses the interface to specify the location of the Excel file, identify the worksheet in the file on which the action will be performed, and specify the row to be deleted. Other actions for the Excel connector make it possible to get data from a worksheet or update a worksheet with new data supplied by the app or flow. The actions for the many other connectors depend on the capabilities of the application or service.

Describe licensing options for connectors, including standard or premium tier

As mentioned earlier, Power Platform provides connectors for over 200 applications and services, and Microsoft is regularly adding new ones. There are two classes of connectors, standard and premium, access to which is based on the Power Apps or Power Automate license in use.

Standard connectors are available to all licensees of Power Apps and Power Automate, regardless of the plan or product through which the user obtained the license. The standard connectors include those for many of the Microsoft 365 and Office 365 applications and services, as well as for popular social media services, a sampling of which is shown in Figure 2-18.

FIGURE 2-18 Sampling of standard connectors in Power Automate

The connectors designated as premium are available to licensed users of the standalone versions of Power Apps (both the per user and the per user, per app plans) and Power Automate (both the per user and per flow plans), as well as to Dynamics 365 users. The premium connectors feature those for many commercial Microsoft and third-party services, including SQL Server and Dynamics 365. A sampling of the premium connectors is shown in Figure 2-19.

FIGURE 2-19 Sampling of premium connectors in Power Automate

Power Apps standalone licenses include Power Automate capabilities, as long as the Power Automate flows exist in the context of a Power Apps application. These contextual flows are permitted to use whatever standard and premium connectors are provided with the Power Apps license. Standalone flows that are not part of a Power Apps application are not supported by the Power Apps license; a standalone Power Automate license is required.

Licensed Microsoft 365 and Office 365 users have access to the standard connectors in Power Apps and Power Automate, but they do not have access to premium connectors. To gain access to the premium connectors, they need a standalone Power Apps and/or Power Automate license as well.

Identify use cases for custom connectors

As mentioned earlier, a connector is a wrapper that surrounds a REST API supplied by the application or service that will be the data source. Power Platform provides connectors for a great many applications or services, but certainly not for every one. For developers who require access to data sources for which there are no public connectors available, it is possible for them to create their own custom connectors.

When a developer creates a custom connector, it is part of the current working environment and is usable only by the apps and flows operating in that same environment. It is also necessary for consumers running apps or flows that use custom connectors to have their own credentials for authentication to the data source, if the data source requires them. Unlike with public connectors, there is no way for consumers of a shared app or flow using custom connectors to inherit credentials supplied by the developer.

Depending on the application or service for which the developer will create a custom connector, there might or might not be an existing API with which the connector can communicate. A third-party application or service might already have an API in place. If not, the developer might have to discuss with the third party the possibility of their creating one. For an internally developed application or service without an API, the developer might have to create one using a tool such as Azure Functions, Azure Web Apps, or Azure API Apps.

There are several ways in which a custom connector can communicate with the API. When a developer runs the Custom Connector Wizard, the following options are provided:

• Create from blank

• Create from Azure service

• Import an OpenAPI file

• Import an OpenAPI from URL

• Import a Postman collection

OpenAPI (formerly known as Swagger) and Postman are definition file formats that provide the communication information the custom connector needs. When creating a custom connector from scratch (using the Create from blank option), the developer is led by the wizard through four stages:

1. General—Prompts for an icon and color for the connector tile and the host name for the API, as shown in Figure 2-20

   

   FIGURE 2-20 The General tab of the Custom Connector Wizard

2. Security—Prompts for the authentication method the connector should use to access the API: Basic authentication (as shown in Figure 2-21), API Key, or OAuth 2.0

   

   FIGURE 2-21 The Security tab of the Custom Connector Wizard

3. Definition—Provides the interface for creating the connector’s actions, triggers, and policies, as shown in Figure 2-22

   

   FIGURE 2-22 The Definition tab of the Custom Connector Wizard

4. Test—Provides a platform for testing specific operations in the custom connector, as shown in Figure 2-23

   

   FIGURE 2-23 The Test tab of the Custom Connector Wizard

After developers have created custom connectors, they can share them with users inside their organization. Sharing an app or flow that uses a custom connector makes it accessible to the recipients of the share. Developers can also share their custom connectors with other users by selecting Invite other user from the Custom connectors page to display the interface shown in Figure 2-24.

FIGURE 2-24 The Share tab of a custom connector

To share a custom connector with users outside of the organization, developers must submit it for certification by Microsoft, which validates the connector’s functionality and content. The connector then undergoes a testing phase in a preview area, and when testing is complete, it is deployed for public access. Connectors that are certified and published by Microsoft must be released as open source software.