Create and manage blobs in Azure Blob Storage by using Azure Logic Apps

This article shows how you can access and manage files stored as blobs in your Azure storage account from inside a logic app with the Azure Blob Storage connector. That way, you can create logic apps that automate tasks and workflows for managing your files. For example, you can build logic apps that create, get, update, and delete files in your storage account.

Suppose that you have a tool that gets updated on an Azure website. which acts as the trigger for your logic app. When this event happens, you can have your logic app update some file in your blob storage container, which is an action in your logic app.

If you're new to logic apps, review What is Azure Logic Apps and Quickstart: Create your first logic app. For connector-specific technical information, see the Azure Blob Storage connector reference.


To enable access from Azure Logic Apps to storage accounts behind firewalls, see the Access storage accounts behind firewalls section later in this topic.


  • By default, Azure Blob Storage actions can read or write files that are 50 MB or smaller. To handle files larger than 50 MB but up to 1024 MB, Azure Blob Storage actions support message chunking. The Get blob content action implicitly uses chunking.

  • Azure Blob Storage triggers don't support chunking. When requesting file content, triggers select only files that are 50 MB or smaller. To get files larger than 50 MB, follow this pattern:

    • Use an Azure Blob Storage trigger that returns file properties, such as When a blob is added or modified (properties only).

    • Follow the trigger with the Azure Blob Storage Get blob content action, which reads the complete file and implicitly uses chunking.


Add blob storage trigger

In Azure Logic Apps, every logic app must start with a trigger, which fires when a specific event happens or when a specific condition is met. Each time the trigger fires, the Logic Apps engine creates a logic app instance and starts running your app's workflow.

This example shows how you can start a logic app workflow with the When a blob is added or modified (properties only) trigger when a blob's properties gets added or updated in your storage container.

  1. In the Azure portal or Visual Studio, create a blank logic app, which opens Logic App Designer. This example uses the Azure portal.

  2. In the search box, enter "azure blob" as your filter. From the triggers list, select the trigger you want.

    This example uses this trigger: When a blob is added or modified (properties only)

    Select Azure Blob Storage trigger

  3. If you're prompted for connection details, create your blob storage connection now. Or, if your connection already exists, provide the necessary information for the trigger.

    For this example, select the container and folder you want to monitor.

    1. In the Container box, select the folder icon.

    2. In the folder list, choose the right-angle bracket ( > ), and then browse until you find and select the folder you want.

      Select storage folder to use with trigger

    3. Select the interval and frequency for how often you want the trigger to check the folder for changes.

  4. When you're done, on the designer toolbar, choose Save.

  5. Now continue adding one or more actions to your logic app for the tasks you want to perform with the trigger results.

Add blob storage action

In Azure Logic Apps, an action is a step in your workflow that follows a trigger or another action. For this example, the logic app starts with the Recurrence trigger.

  1. In the Azure portal or Visual Studio, open your logic app in Logic App Designer. This example uses the Azure portal.

  2. In the Logic App Designer, under the trigger or action, choose New step.

    Add new step to logic app workflow

    To add an action between existing steps, move your mouse over the connecting arrow. Choose the plus sign (+) that appears, and select Add an action.

  3. In the search box, enter "azure blob" as your filter. From the actions list, select the action you want.

    This example uses this action: Get blob content

    Select Azure Blob Storage action

  4. If you're prompted for connection details, create your Azure Blob Storage connection now. Or, if your connection already exists, provide the necessary information for the action.

    For this example, select the file you want.

    1. From the Blob box, select the folder icon.

      Select storage folder to use with action

    2. Find and select the file you want based on the blob's ID number. You can find this ID number in the blob's metadata that is returned by the previously described blob storage trigger.

  5. When you're done, on the designer toolbar, choose Save. To test your logic app, make sure that the selected folder contains a blob.

This example only gets the contents for a blob. To view the contents, add another action that creates a file with the blob by using another connector. For example, add a OneDrive action that creates a file based on the blob contents.

Connect to storage account

When you use a trigger or action that accesses a service for the first time, the Logic Apps Designer prompts you to create a connection to that service. You can then provide the necessary connection information directly from your logic app inside the designer.

  1. When you're prompted to created the connection, provide this information:

    Property Required Value Description
    Connection Name Yes <connection-name> The name to create for your connection
    Storage Account Yes <storage-account> Select your storage account from the list.

    For example:

    Create Azure Blob storage account connection

  2. When you're ready, select Create

  3. After you create your connection, continue with Add blob storage trigger or Add blob storage action.

Connector reference

For technical details, such as triggers, actions, and limits, as described by the connector's Open API (formerly Swagger) file, see the connector's reference page.

Access storage accounts behind firewalls

You can add network security to an Azure storage account by restricting access with a firewall and firewall rules. However, this setup creates a challenge for Azure and other Microsoft services that need access to the storage account. Local communication in the datacenter abstracts the internal IP addresses, so you can't set up firewall rules with IP restrictions. For more information, see Configure Azure Storage firewalls and virtual networks.

Here are various options for accessing storage accounts behind firewalls from Azure Logic Apps by using either the Azure Blob Storage connector or other solutions:

Access to storage accounts in other regions

Logic apps can't directly access storage accounts that have firewall rules and are in the same region. However, if you permit access for the outbound IP addresses for managed connectors in your region, your logic apps can access storage accounts in a different region except when you use the Azure Table Storage connector or Azure Queue Storage connector. To access your Table Storage or Queue Storage, you can still use the built-in HTTP trigger and actions.

Access storage accounts through a trusted virtual network

You can put the storage account in an Azure virtual network that you manage, and then add that virtual network to the trusted virtual networks list. To have your logic app access the storage account through a trusted virtual network, you need to deploy that logic app to an integration service environment (ISE), which can connect to resources in a virtual network. You can then add the subnets in that ISE to the trusted list. Azure Storage connectors, such as the Blob Storage connector, can directly access the storage container. This setup is the same experience as using the service endpoints from an ISE.

Access storage accounts as a trusted service with managed identities

To give Microsoft trusted services access to a storage account through a firewall, you can set up an exception on that storage account for those services. This solution permits Azure services that support managed identities for authentication to access storage accounts behind firewalls as trusted services. Specifically, for a logic app in global multi-tenant Azure to access these storage accounts, you first enable managed identity support on the logic app. Then, you use the HTTP action or trigger in your logic app and set their authentication type to use your logic app's managed identity. For this scenario, you can use only the HTTP action or trigger.

To set up the exception and managed identity support, follow these general steps:

  1. On your storage account, under Settings, select Firewalls and virtual networks. Under Allow access from, select the Selected networks option so that the related settings appear.

  2. Under Exceptions, select Allow trusted Microsoft services to access this storage account, and then select Save.

    Select exception that allows Microsoft trusted services

  3. In your logic app's settings, enable support for the managed identity.

  4. In your logic app's workflow, add and set up the HTTP action or trigger to access the storage account or entity.


    For outgoing HTTP action or trigger calls to Azure Storage accounts, make sure that the request header includes the x-ms-version property and the API version for the operation that you want to run on the storage account. For more information, see Authenticate access with managed identity and Versioning for Azure Storage services.

  5. On that action, select the managed identity to use for authentication.

Access storage accounts through Azure API Management

If you use a dedicated tier for API Management, you can front the Storage API by using API Management and permitting the latter's IP addresses through the firewall. Basically, add the Azure virtual network that's used by API Management to the storage account's firewall setting. You can then use either the API Management action or the HTTP action to call the Azure Storage APIs. However, if you choose this option, you have to handle the authentication process yourself. For more info, see Simple enterprise integration architecture.

Next steps