What are connectors in Azure Logic Apps

  • Article

When you build a workflow using Azure Logic Apps, you can use a connector to work with data, events, and resources in other apps, services, systems, and platforms - without writing code. A connector provides one or more prebuilt operations, which you use as steps in your workflow.

In a connector, each operation is either a trigger condition that starts a workflow or a subsequent action that performs a specific task, along with properties that you can configure. While many connectors have both triggers and actions, some connectors offer only triggers, while others provide only actions.

In Azure Logic Apps, connectors are available in either a built-in version, managed version, or both. Many connectors usually require that you first create and configure a connection to the underlying service or system, usually so that you can authenticate access to a user account. If no connector is available for the service or system that you want to access, you can send a request using the generic HTTP operation, or you can create a custom connector.

This overview provides a high-level introduction to connectors and how they generally work. For more connector information, see the following documentation:

Built-in connectors versus managed connectors

In Azure Logic Apps, connectors are either built in or managed. Some connectors have both versions. The available versions depend on whether you create a Consumption logic app workflow that runs in multitenant Azure Logic Apps or a Standard logic app workflow that runs in single-tenant Azure Logic Apps. For more information about logic app resource types, see Resource types and host environment differences.

  • Built-in connectors are designed to run directly and natively inside Azure Logic Apps.

  • Managed connectors are deployed, hosted, and managed in Azure by Microsoft. Managed connectors mostly provide a proxy or a wrapper around an API that the underlying service or system uses to communicate with Azure Logic Apps.

    • In a Consumption workflow, managed connectors appear in the designer under the Standard or Enterprise labels, based on their pricing level.

    • In a Standard workflow, all managed connectors appear in the designer under the Azure label.

For more information, see the following documentation:

Triggers

A trigger specifies the condition to meet before the workflow can start and is always the first step in any workflow. Each trigger also follows a specific firing pattern that controls how the trigger monitors and responds to events. Usually, a trigger follows either a polling pattern or a push pattern. Sometimes, both trigger versions are available.

  • Polling triggers regularly check a specific service or system on a specified schedule to check for new data or a specific event. If new data is available, or the specific event happens, these triggers create and run a new instance of your workflow. This new instance can then use the data that's passed as input.

    Note

    For connectors that are Azure-managed, hosted, and run in Azure, polling triggers use only the Interval and Frequency values to calculate the next recurrence. They don't use the advanced scheduling options, such as At these hours and At these days. These options work only with built-in polling triggers that directly run with the Azure Logic Apps runtime, such as the Recurrence, Sliding Window, and HTTP triggers.

  • Push or webhook triggers listen for new data or for an event to happen, without polling. When new data is available, or when the event happens, these triggers create and run a new instance of your workflow. This new instance can then use the data that's passed as input.

For example, suppose you want to build a workflow that runs when a file is uploaded to your FTP server. As the first step in your workflow, you can add the FTP trigger named When a file is added or modified, which follows a polling pattern. You then specify the schedule to regularly check for upload events.

When the trigger fires, the trigger usually passes along event outputs for subsequent actions to reference and use. For the FTP example, the trigger automatically outputs information such as the file name and path. You can also set up the trigger to include the file content. So, to process this data, you must add actions to your workflow.

Actions

An action specifies a task to perform and always appears as a subsequent step in the workflow. You can use multiple actions in your workflow. For example, you might start the workflow with a SQL Server trigger that checks for new customer data in an SQL database. Following the trigger, your workflow can have a SQL Server action that gets the customer data. Following this SQL Server action, your workflow can use a different action that processes the data, for example, a Data Operations action that creates a CSV table.

Connection permissions

In a Consumption logic app workflow, before you can create or manage logic app resources, workflows, and their connections, you need specific permissions. For more information about these permissions, see Secure operations - Secure access and data in Azure Logic Apps.

Connection creation, configuration, and authentication

Before you can use a connector's operations in your workflow, many connectors require that you first create a connection to the target service or system. To create a connection from inside the workflow designer, you have to authenticate your identity with account credentials and sometimes other connection information.

For example, before your workflow can access and work with your Office 365 Outlook email account, you must authorize a connection to that account. For some built-in connectors and managed connectors, you can set up and use a managed identity for authentication, rather than provide your credentials.

Note

When we use Office 365 Outlook connector to sign in Office 365 Outlook application in Azure China 21Vianet. It is mandatory to sign in with China Office 365 account which operated by 21Vianet. This account is similar to the format of <your-account>@<your-organization>.partner.onmschina.cn. The administrator of your organization can manage the users with the Administrator site.

Although you create connections within a workflow, these connections are actually separate Azure resources with their own resource definitions. To review these connection resource definitions, follow these steps based on whether you have a Consumption or Standard workflow:

Connection security and encryption

Connection configuration details, such as server address, username, and password, credentials, and secrets are encrypted and stored in the secured Azure environment. This information can be used only in logic app resources and by clients who have permissions for the connection resource, which is enforced using linked access checks. Connections that use Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), such as Office 365, Salesforce, and GitHub, require that you sign in, but Azure Logic Apps stores only access and refresh tokens as secrets, not sign-in credentials.

Established connections can access the target service or system for as long as that service or system allows. For services that use Microsoft Entra ID OAuth connections, such as Office 365 and Dynamics, Azure Logic Apps refreshes access tokens indefinitely. Other services might have limits on how long Logic Apps can use a token without refreshing. Some actions, such as changing your password, invalidate all access tokens.

Note

If your organization doesn't permit you to access specific resources through connectors in Azure Logic Apps, you can block the capability to create such connections using Azure Policy.

For more information about securing logic app workflows and connections, see Secure access and data in Azure Logic Apps.

Firewall access for connections

If you use a firewall that limits traffic, and your logic app workflows need to communicate through that firewall, you have to set up your firewall to allow access for both the inbound and outbound IP addresses used by the Azure Logic Apps platform or runtime in the Azure region where your logic app workflows exist.

If your workflows also use managed connectors, such as the Office 365 Outlook connector or SQL connector, or use custom connectors, your firewall also needs to allow access for all the managed connector outbound IP addresses in your logic app resource's Azure region. For more information, see Firewall configuration.

Custom connectors and APIs

In Consumption workflows for multitenant Azure Logic Apps, you can call Swagger-based or SOAP-based APIs that aren't available as out-of-the-box connectors. You can also run custom code by creating custom API Apps. For more information, see the following documentation:

In Standard workflows for single-tenant Azure Logic Apps, you can create natively running service provider-based custom built-in connectors that are available to any Standard logic app workflow. For more information, see the following documentation:

Known issues

The following table includes known issues for connectors in Azure Logic Apps:

Error message Description Resolution
Error: BadGateway. Client request id: '{GUID}' This error results from updating the tags on a logic app resource where one or more connections don't support Microsoft Entra ID OAuth authentication, such as SFTP ad SQL, breaking those connections. To prevent this behavior, avoid updating those tags.

Next steps

Create a Consumption logic app workflow - Azure portal

Create a Standard logic app workflow - Azure portal