About connectors in Azure Logic Apps

  • Article
  • 10 minutes to read

When you build workflows using Azure Logic Apps, you can use connectors to help you quickly and easily access data, events, and resources in other apps, services, systems, protocols, and platforms - often without writing any code. A connector provides prebuilt operations that you can use as steps in your workflows. Azure Logic Apps provides hundreds of connectors that you can use. If no connector is available for the resource that you want to access, you can use the generic HTTP operation to communicate with the service, or you can create a custom connector.

This overview provides a high-level introduction to connectors and how they generally work. For information about the more popular and commonly used connectors in Azure Logic Apps, review the following documentation:

What are connectors?

Technically, a connector is a proxy or a wrapper around an API that the underlying service uses to communicate with Azure Logic Apps. This connector provides operations that you use in your workflows to perform tasks. An operation is available either as a trigger or action with properties you can configure. Some triggers and actions also require that you first create and configure a connection to the underlying service or system, for example, so that you can authenticate access to a user account. For more overview information, review Connectors overview for Azure Logic Apps, Microsoft Power Automate, and Microsoft Power Apps.

Triggers

A trigger specifies the event that starts the workflow 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 the polling pattern or push pattern, but sometimes, a trigger is available in both versions.

  • 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.

  • Push 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, you might want to build a workflow that does something when a file is uploaded to your FTP server. As the first step in your workflow, you can use the FTP trigger named When a file is added or modified, which follows the polling pattern. You can then specify a schedule to regularly check for upload events.

A trigger also passes along any inputs and other required data into your workflow where later actions can reference and use that data throughout the workflow. For example, suppose you want to use Office 365 Outlook trigger named When a new email arrives to start a workflow when you get a new email. You can configure this trigger to pass along the content from each new email, such as the sender, subject line, body, attachments, and so on. Your workflow can then process that information by using other actions.

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.

Actions

An action is an operation that follows the trigger and performs some kind of task in your workflow. You can use multiple actions in your workflow. For example, you might start the workflow with a SQL trigger that detects new customer data in a SQL database. Following the trigger, your workflow can have a SQL action that gets the customer data. Following the SQL action, your workflow can have another action, not necessarily SQL, that processes the data.

Connector categories

In Azure Logic Apps, most triggers and actions are available in either a built-in version or managed connector version. A few triggers and actions are available in both versions. The versions available depend on whether you create a Consumption logic app that runs in multi-tenant Azure Logic Apps, or a Standard logic app that runs in single-tenant Azure Logic Apps.

  • Built-in connectors run natively on the Azure Logic Apps runtime.

  • Managed connectors are deployed, hosted, and managed by Azure. These connectors provide triggers and actions for cloud services, on-premises systems, or both.

    In a Standard logic app, all managed connectors are organized as Azure connectors. However, in a Consumption logic app, managed connectors are organized as Standard or Enterprise, based on pricing level.

For more information about logic app types, review Resource types and host environment differences.

Connection configuration

In Consumption logic apps, before you can create or manage logic apps and their connections, you need specific permissions. For more information about these permissions, review Secure operations - Secure access and data in Azure Logic Apps.

Before you can use a managed connector's triggers or actions in your workflow, many connectors require that you first create a connection to the target service or system. To create a connection from within the logic app 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.

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 logic app:

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 Azure Active Directory Open Authentication (Azure AD 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 Azure AD 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.

Tip

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 apps and connections, review 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's Azure region. For more information, review Firewall configuration.

Recurrence behavior

Recurring built-in triggers, such as the Recurrence trigger, run natively on the Azure Logic Apps runtime and differ from recurring connection-based triggers, such as the Office 365 Outlook connector trigger where you need to create a connection first.

For both kinds of triggers, if a recurrence doesn't specify a specific start date and time, the first recurrence runs immediately when you save or deploy the logic app, despite your trigger's recurrence setup. To avoid this behavior, provide a start date and time for when you want the first recurrence to run.

Some managed connectors have both recurrence-based and webhook-based triggers, so if you use a recurrence-based trigger, review the Recurrence behavior overview.

Recurrence for built-in triggers

Recurring built-in triggers follow the schedule that you set, including any specified time zone. However, if a recurrence doesn't specify other advanced scheduling options, such as specific times to run future recurrences, those recurrences are based on the last trigger execution. As a result, the start times for those recurrences might drift due to factors such as latency during storage calls.

For more information, review the following documentation:

Recurrence for connection-based triggers

In recurring connection-based triggers, such as Office 365 Outlook, the schedule isn't the only driver that controls execution. The time zone only determines the initial start time. Subsequent runs depend on the recurrence schedule, the last trigger execution, and other factors that might cause run times to drift or produce unexpected behavior, for example:

  • Whether the trigger accesses a server that has more data, which the trigger immediately tries to fetch.

  • Any failures or retries that the trigger incurs.

  • Latency during storage calls.

  • Other factors that can affect when the next run time happens.

For more information, review the following documentation:

Troubleshooting recurrence issues

To make sure that your workflow runs at your specified start time and doesn't miss a recurrence, especially when the frequency is in days or longer, try the following solutions:

  • If you're using a Recurrence trigger, specify a time zone, a start date, and start time. In addition, configure specific times to run subsequent recurrences in the properties At these hours and At these minutes, which are available only for the Day and Week frequencies. However, some time windows might still cause problems when the time shifts.

  • Consider using a Sliding Window trigger instead of a Recurrence trigger to avoid missed recurrences.

Custom connectors and APIs

In Consumption logic apps that run in multi-tenant 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, review the following documentation:

In Standard logic apps that run in 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. For more information, review the following documentation:

Known issues

The following table includes known issues for Logic Apps connectors.

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

Next steps

Create custom APIs you can call from Logic Apps