Built-in connectors provide ways for you to control your workflow's schedule and structure, run your own code, manage or manipulate data, and complete other tasks in your workflows. Different from managed connectors, some built-in connectors aren't tied to a specific service, system, or protocol. For example, you can start almost any workflow on a schedule by using the Recurrence trigger. Or, you can have your workflow wait until called by using the Request trigger. All built-in connectors run natively on the Azure Logic Apps runtime. Some don't require that you create a connection before you use them.
For a smaller number of services, systems, and protocols, Azure Logic Apps provides a built-in version alongside the managed version. The number and range of built-in connectors vary based 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. In most cases, the built-in version provides better performance, capabilities, pricing, and so on. In a few cases, some built-in connectors are available only in one logic app workflow type and not the other.
For example, a Standard workflow can use both managed connectors and built-in connectors for Azure Blob Storage, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, FTP, IBM DB2, IBM MQ, SFTP, and SQL Server. A Consumption workflow doesn't have the built-in versions. A Consumption workflow can use built-in connectors for Azure API Management, and Azure App Service, while a Standard workflow doesn't have these built-in connectors.
This article provides a general overview about built-in connectors in Consumption workflows versus Standard workflows.
Built-in connectors in Consumption versus Standard
The following table lists the current and expanding galleries of built-in operations collections available for Consumption versus Standard workflows. For Standard workflows, an asterisk (*) marks built-in connectors based on the service provider model, which is described in more detail later.
Consumption
Standard
Azure API Management Azure App Service Azure Functions Azure Logic Apps Batch Operations Control Data Operations Date Time Flat File HTTP Inline Code Integration Account Liquid Operations Request Schedule Variables XML Operations
AS2 (v2) Azure AI Search* Azure API Management Azure Automation* Azure Blob Storage* Azure Cosmos DB* Azure Event Grid Publisher* Azure Event Hubs* Azure File Storage* Azure Functions Azure Key Vault* Azure OpenAI* Azure Queue Storage* Azure Service Bus* Azure Table Storage* Batch Operations Control Data Mapper Operations Data Operations Date Time EDIFACT File System* Flat File FTP* HTTP IBM 3270* IBM CICS* IBM DB2* IBM Host File* IBM IMS* IBM MQ* Inline Code Integration Account JDBC* Liquid Operations Request RosettaNet SAP* Schedule SFTP* SMTP* SQL Server* SWIFT Variables Workflow Operations X12 XML Operations
Service provider-based built-in connectors
In Standard workflows, a built-in connector that has the following attributes is informally known as a service provider:
Provides access from a Standard workflow to a service, such as Azure Blob Storage, Azure Service Bus, Azure Event Hubs, SFTP, and SQL Server.
Some built-in connectors support only a single way to authenticate a connection to the underlying service. Other built-in connectors can offer a choice, such as using a connection string, Microsoft Entra ID, or a managed identity.
Runs in the same process as the redesigned Azure Logic Apps runtime.
In contrast, a built-in connector that's not a service provider has the following attributes:
Isn't based on the Azure Functions extensibility model.
Is directly implemented as a job within the Azure Logic Apps runtime, such as Schedule, HTTP, Request, and XML operations.
Custom built-in connectors
For Standard workflows, you can create your own built-in connector with the same built-in connector extensibility model that's used by service provider-based built-in connectors, such as Azure Blob Storage, Azure Event Hubs, Azure Service Bus, SQL Server, and more. This interface implementation is based on the Azure Functions extensibility model and provides the capability for you to create custom built-in connectors that anyone can use in Standard workflows.
For Consumption workflows, you can't create your own built-in connectors, but you create your own managed connectors.
For more information, review the following documentation:
When an HTTP request is received: Wait for a request from another workflow, app, or service. This trigger makes your workflow callable without having to be checked or polled on a schedule.
Response: Respond to a request received by the When an HTTP request is received trigger in the same workflow.
Connect to an SMTP server so that you can send email.
Built-in connectors for specific services and systems
You can use the following built-in connectors to access specific services and systems. In Standard workflows, some of these built-in connectors are also informally known as service providers, which can differ from their managed connector counterparts in some ways.
Consume and publish events through an event hub. For example, get output from your workflow with Event Hubs, and then send that output to a real-time analytics provider.
Connect to your SQL Server on premises or an Azure SQL Database in the cloud so that you can manage records, run stored procedures, or perform queries.
Run code from workflows
Azure Logic Apps provides the following built-in actions for running your own code in your workflow:
Group actions into cases, which are assigned unique values except for the default case. Run only that case whose assigned value matches the result from an expression, object, or token. If no matches exist, run the default case.
Compose XML with schema: Create XML from JSON using a schema for a Standard workflow.
Parse XML with schema: Parse XML using a schema for a Standard workflow.
Transform XML: Convert XML using a map.
Validate XML: Validate inbound or outbound XML using a schema.
Business-to-business (B2B) built-in operations
Azure Logic Apps supports business-to-business (B2B) communication scenarios through various B2B built-in operations. Based on whether you have a Consumption or Standard workflow and the B2B operations that you want to use, you might have to create and link an integration account to your logic app resource. You then use this integration account to define your B2B artifacts, such as trading partners, agreements, maps, schemas, certificates, and so on.
Consumption workflows
Before you can use any B2B operations in a workflow, you must create and link an integration account to your logic app resource. After you create your integration account, you must then define your B2B artifacts, such as trading partners, agreements, maps, schemas, certificates, and so on. You can then use the B2B operations to encode and decode messages, transform content, and more.
Standard workflows
Some B2B operations require that you create and link an integration account to your logic app resource. Linking lets you share artifacts across multiple Standard workflows and their child workflows. Based on the B2B operation that you want to use, complete one of the following steps before you use the operation:
For operations that require maps or schemas, you can either: