Rediger

What are connectors in workflows for Azure Logic Apps?

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.

    In the designer, all built-in connectors appear in the connector gallery within the In app group.

  • 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 the designer, all managed connectors appear in the connector gallery within the Shared group. They're billed at either the Standard or Enterprise level.

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 Microsoft-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 a 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, you need specific permissions before you can create or manage logic app resources, workflows, and their connections. 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.

For managed connectors, connections are separate Azure resources with their own resource definitions. For built-in connectors in Standard workflows, connection configuration is stored with the logic app configuration, including the connections.json file and referenced app settings. To review connection information, follow these steps based on whether you have a Consumption or Standard workflow:

Connection security and encryption

Azure services that store connection configuration details and secrets encrypt them at rest. Storage and access controls vary between managed API connections and built-in connections in Standard workflows. 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 access and refresh tokens rather than user sign-in passwords.

Azure Logic Apps can refresh OAuth access tokens while the refresh token remains valid and the target service permits access. Refresh tokens can expire or be revoked, which might require reauthorization. Credential changes can also invalidate tokens, depending on the identity provider, client type, and authentication flow.

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 your environment uses a firewall, allow only the traffic required by your workflows and connector operations:

  • For Consumption workflows that use built-in operations, allow inbound Azure Logic Apps traffic when workflows receive external calls and outbound traffic when workflows call external endpoints. Use the LogicAppsManagement and LogicApps service tags where supported.

  • For managed or custom connector operations, use the AzureConnectors service tag where supported. Otherwise, allow the required managed connector outbound IP addresses for the applicable Azure regions.

  • For Standard workflows, follow Azure App Service networking requirements and allow the fully qualified domain names required by connector connections. For more information, see Firewall permissions for Standard workflows.

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:

Next steps

Create a Consumption logic app workflow - Azure portal

Create a Standard logic app workflow - Azure portal

  • Last updated on