Create stateful or stateless workflows in Visual Studio Code with the Azure Logic Apps (Preview) extension

Important

This capability is in public preview, is provided without a service level agreement, and is not recommended for production workloads. Certain features might not be supported or might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

To create logic app workflows that integrate across apps, data, cloud services, and systems, you can use Visual Studio Code and the Azure Logic Apps (Preview) extension to build and locally run stateful and stateless logic app workflows in your development environment.

Screenshot that shows Visual Studio Code and logic app workflow.

The logic apps that you create with the public preview extension use the new Logic App (Preview) resource type and are powered by the Azure Functions runtime in your local environment. This new resource type can include multiple workflows and is similar in some ways to the Function App resource type, which can include multiple functions.

Meanwhile, the original Logic Apps resource type still exists for you to create and use in Visual Studio Code and in the Azure portal. However, the experiences for the original resource type are separate from the new resource type. At this time, both Logic Apps and Logic App (Preview) resource types can exist at the same time in Visual Studio Code and in the Azure portal. You can view and access all the deployed logic apps in your Azure subscription, but they appear and are kept separately in their own categories and sections.

This article provides a high-level overview about this public preview, describes various aspects about the Logic App (Preview) resource type, and how to create this resource by using Visual Studio Code:

What's in this public preview?

The Azure Logic Apps (Preview) extension brings many current and additional Logic Apps capabilities to your local development experience in Visual Studio Code, for example:

  • Build logic apps for integration and automation workflows from 390+ connectors for Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) apps and services plus connectors for on-premises systems.

    • Some managed connectors such as Azure Service Bus, Azure Event Hubs, and SQL Server run similarly to built-in native triggers and actions such as the HTTP action.

    • Create and deploy logic apps that can run anywhere because the Azure Logic Apps service generates Shared Access Signature (SAS) connection strings that these logic apps can use for sending requests to the cloud connection runtime endpoint. The Logic Apps service saves these connection strings with other application settings so that you can easily store these values in Azure Key Vault when you deploy to Azure.

      Note

      By default, a Logic App (Preview) resource has its system-assigned managed identity automatically enabled to authenticate connections at runtime. This identity differs from the authentication credentials or connection string that you use when you create a connection. If you disable this identity, connections won't work at runtime.

  • Create stateless logic apps that run only in memory so that they finish more quickly, respond faster, have higher throughput, and cost less to run because the run histories and data between actions don't persist in external storage. Optionally, you can enable run history for easier debugging. For more information, see Stateful versus stateless logic apps.

  • Run and debug your logic apps locally in the Visual Studio Code development environment.

  • Publish and deploy your logic apps from Visual Studio Code directly to various hosting environments, such as Azure App Service and Docker containers.

Note

For information about current known issues, review the preview extension's Known Issues GitHub page.

Stateful versus stateless logic apps

  • Stateful

    Create stateful logic apps when you need to keep, review, or reference data from previous events. These logic apps keep the input and output for each action and their workflow states in external storage, which makes reviewing the run details and history possible after each run finishes. Stateful logic apps provide high resiliency if or when outages happen. After services and systems are restored, you can reconstruct interrupted logic app runs from the saved state and rerun the logic apps to completion. Stateful workflows can continue running for up to a year.

  • Stateless

    Create stateless logic apps when you don't need to save, review, or reference data from previous events in external storage for later review. These logic apps keep the input and output for each action and their workflow states only in memory, rather than transfer this information to external storage. As a result, stateless logic apps have shorter runs that are usually no longer than 5 minutes, faster performance with quicker response times, higher throughput, and reduced running costs because the run details and history aren't kept in external storage. However, if or when outages happen, interrupted runs aren't automatically restored, so the caller needs to manually resubmit interrupted runs. These logic apps can only run synchronously and for easier debugging, you can enable run history, which has some impact on performance.

    Stateless workflows currently support only actions for managed connectors, which are deployed in Azure, and not triggers. To start your workflow, select the built-in Request, Event Hubs, or Service Bus trigger, which run natively with the Logic Apps runtime. For more information about unsupported triggers, actions, and connectors, see Unsupported or unavailable capabilities.

For information about how nested logic apps behave differently between stateful and stateless logic apps, see Nested behavior differences between stateful and stateless logic apps.

Pricing model

When you deploy the new Logic App (Preview) resource type, you're prompted to select a hosting plan, specifically the App Service plan or Premium plan to use as the pricing model. If you select the App Service plan, you're also prompted to select a pricing tier. During public preview, running logic apps on App Service doesn't incur additional charges on top of the selected plan.

Stateful logic apps use external storage, so the Azure Storage pricing model applies to storage transactions that the Azure Logic Apps runtime performs. For example, queues are used for scheduling, while tables and blobs are used for storing workflow states.

For more information about the pricing models that apply to this new resource type, review these topics:

Unavailable or unsupported capabilities

For this public preview, these capabilities are not available or not supported:

  • Creating the new Logic App (Preview) resource is currently unavailable on macOS.

  • Not all Azure regions are supported yet. For currently available regions, check the regions list.

  • To start your workflow, use the built-in Request, HTTP, Event Hubs, or Service Bus trigger, which run natively with the Logic Apps runtime. Currently, enterprise connectors, on-premises data gateway triggers, webhook-based triggers, Sliding Window trigger, custom connectors, integration accounts, their artifacts, and their connectors aren't supported in this preview. The "call an Azure function" capability is unavailable, so for now, use the HTTP action to call the request URL for the Azure function.

    Except for the previously specified triggers, stateful workflows can use both triggers and actions for managed connectors, which are deployed in Azure. However, stateless workflows currently support only actions for managed connectors, not triggers. Although you have the option to enable connectors in Azure for your stateless workflow, the designer doesn't show any managed connector triggers for you to select.

  • You can deploy the new Logic App (Preview) resource type only to a Premium or App Service hosting plan in Azure or to a Docker container, and not integration service environments (ISEs). Consumption hosting plans aren't supported nor available for deploying this resource type.

  • In the Azure portal, you can't create new logic apps with the new Logic App (Preview) resource type. You can only create these logic apps in Visual Studio Code. However, after you deploy logic apps with this resource type from Visual Studio Code to Azure, you can add new workflows to those logic apps.

Prerequisites

Access and connectivity

  • Access to the internet so that you can download the requirements, connect from Visual Studio Code to your Azure account, and publish from Visual Studio Code to Azure, a Docker container, or other environment.

  • An Azure account and subscription. If you don't have a subscription, sign up for a free Azure account.

  • To build the same example logic app in this article, you need an Office 365 Outlook email account that uses a Microsoft work or school account to sign in.

    If you choose to use a different email connector that's supported by Azure Logic Apps, such as Outlook.com or Gmail, you can still follow the example, and the general overall steps are the same, but your user interface and options might differ in some ways. For example, if you use the Outlook.com connector, use your personal Microsoft account instead to sign in.

Storage requirements

  1. Download and install Azure Storage Emulator 5.10.

  2. To run the emulator, you need to have a local SQL DB installation, such as the free SQL Server 2019 Express Edition. For more information, see Use the Azure Storage emulator for development and testing.

    Important

    Before you open the Logic App Designer to create your logic app workflow, make sure that you start the emulator. Otherwise, you get a message that the Workflow design time could not be started.

    Screenshot that shows the Azure Storage Emulator running.

Tools

  • Visual Studio Code 1.30.1 (January 2019) or higher, which is free. Also, download and install these additional tools for Visual Studio Code, if you don't have them already:

    • Azure Account extension, which provides a single common Azure sign-in and subscription filtering experience for all other Azure extensions in Visual Studio Code.

    • C# for Visual Studio Code extension, which enables F5 functionality to run your logic app.

    • Azure Functions Core Tools, either version 3.0.2931 or 2.7.2936, through the Microsoft Installer (MSI). These tools includes a version of the same runtime that powers the Azure Functions runtime that runs in Visual Studio Code.

      Important

      If you have an installation that's earlier than these versions, uninstall that version first, or make sure that the PATH environment variable points at the version that you download and install.

      If you want to use the Inline Code action for running JavaScript code, you need to use the Azure Functions runtime version 3x because the action doesn't support version 2x. Also, this action currently isn't supported on Linux operating systems.

    • Azure Logic Apps (Preview) extension for Visual Studio Code. This public preview extension provides the capability for you to create stateful and stateless logic apps and run them locally in Visual Studio Code.

      Currently, you can have both the original Azure Logic Apps extension and the new Azure Logic Apps (Preview) extension installed at the same time in Visual Studio Code. By selecting the Azure icon on the Visual Studio Code toolbar, you can view all the logic apps deployed in Azure, but each resource type appears in their own extension sections, Logic Apps and Azure Logic Apps (Preview).

      Important

      If you created logic apps by using the Azure Logic Apps (Private Preview) extension, these logic apps won't work with the public preview extension. However, you can migrate these logic apps by uninstalling the private preview extension, performing the required cleanup, and installing the public preview extension. You can then create your new project in Visual Studio Code, and copy your previously created logic app's workflow.definition file into your new project.

      So, before you install the public preview extension, make sure that you uninstall any earlier versions, and delete these artifacts:

      • The Microsoft.Azure.Functions.ExtensionBundle.Workflows folder, which contains previous extension bundles and is located along either path here:

        • C:\Users\{userName}\AppData\Local\Temp\Functions\ExtensionBundles

        • C:\Users\{userName}.azure-functions-core-tools\Functions\ExtensionBundles

      • The microsoft.azure.workflows.webjobs.extension folder, which is the NuGet cache for the private preview extension and is located along this path:

        C:\Users\{userName}\.nuget\packages

      To install the Azure Logic Apps (Preview) extension, follow these steps:

      1. In Visual Studio Code, on the left toolbar, select Extensions.

      2. In the extensions search box, enter azure logic apps preview. From the results list, select Azure Logic Apps (Preview) > Install.

        After the installation completes, the public preview extension appears in the Extensions: Installed list.

        Screenshot that shows Visual Studio Code's installed extensions list with the "Azure Logic Apps (Preview)" extension underlined.

  • To test the example logic app that you create in this article, you need a tool that can send calls to the Request trigger, which is the first step in example logic app. If you don't have such a tool, you can download, install, and use Postman.

  • For easier diagnostics logging and tracing capability, you can add and use an Application Insights resource. You can create this resource during logic app deployment, or in the Azure portal after you deploy your logic app.

Set up Visual Studio Code

  1. To make sure that all the extensions are correctly installed, reload or restart Visual Studio Code.

  2. Enable or check that Visual Studio Code automatically finds and installs extension updates so that your public preview extension gets the latest updates.

    To check this setting, follow these steps:

    1. On the File menu, go to Preferences > Settings.

    2. On the User tab, go to Features > Extensions.

    3. Confirm that Auto Check Updates and Auto Update are selected.

  3. Enable or check that these Azure Logic Apps (Preview) extension settings are set up in Visual Studio Code:

    • Azure Logic Apps V2: Panel Mode
    • Azure Logic Apps V2: Project Runtime
    1. On the File menu, go to Preferences > Settings.

    2. On the User tab, go to > Extensions > Azure Logic Apps (Preview).

    3. Under Azure Logic Apps V2: Panel Mode, confirm that Enable panel mode is selected. Under Azure Logic Apps V2: Project Runtime, set the version to ~3 or ~2, based on the Azure Functions Core Tools version that you installed earlier.

      Important

      If you want to use the Inline Code action for running JavaScript code, make sure that you use Project Runtime version 3 because the action doesn't support version 2. Also, this action currently isn't supported on Linux operating systems.

      Screenshot that shows Visual Studio Code settings for "Azure Logic Apps (Preview)" extension.

Connect to your Azure account

  1. On the Visual Studio Code toolbar, select the Azure icon.

    Screenshot that shows Visual Studio Code toolbar and selected Azure icon.

  2. In the Azure pane, under Azure: Logic Apps (Preview), select Sign in to Azure. When the Visual Studio Code authentication page appears, sign in with your Azure account.

    Screenshot that shows Azure pane and selected link for Azure sign in.

    After you sign in, the Azure pane shows the subscriptions in your Azure account. If you have the publicly released Logic Apps extension, you can find any original Logic Apps resources that you created using the original extension in the released extension's Logic Apps section, not the preview extension's Logic Apps (Preview) section.

    If the expected subscriptions don't appear, or you want the pane to show only specific subscriptions, follow these steps:

    1. In the subscriptions list, move your pointer next to the first subscription until the Select subscriptions button (filter icon) appears. Select the filter icon.

      Screenshot that shows Azure pane and selected filter icon.

      Or, in the Visual Studio Code status bar, select your Azure account.

    2. When another subscriptions list appears, select the subscriptions that you want, and then make sure that you select OK.

Create a local project

Before you can create your logic app, create a local project so that you can manage and deploy your logic app from Visual Studio Code. The underlying project is similar to an Azure Functions project, also known as a function app project. However, these project types are separate from each other, so logic app workflows and functions can't exist in the same project.

  1. On your computer, create an empty local folder to use for the project that you'll later create in Visual Studio Code.

  2. In Visual Studio Code, close any and all open folders.

  3. In the Azure pane, next to Azure: Logic Apps (Preview), select Create New Project (icon that shows a folder and lightning bolt).

    Screenshot that shows Azure pane toolbar with "Create New Project" selected.

  4. If Windows Defender Firewall prompts you to grant network access for Code.exe, which is Visual Studio Code, and for func.exe, which is the Azure Functions Core Tools, select Private networks, such as my home or work network > Allow access.

  5. Browse to the location where you created your project folder, select that folder and continue.

    Screenshot that shows "Select Folder" dialog box with a newly created project folder and the "Select" button selected.

  6. From the templates list that appears, select either Stateful Workflow or Stateless Workflow. This example selects Stateful Workflow.

    Screenshot that shows the workflow templates list with "Stateful Workflow" selected.

  7. Provide a name for your logic app workflow and press Enter. This example uses example-workflow as the name.

    Screenshot that shows the "Create a new Stateful Workflow (3/4)" box and "example-workflow" as the workflow name.

  8. From the next list that appears, select Open in current window.

    Screenshot that shows list with "Open in current window" selected.

    Visual Studio Code reloads, opens the Explorer pane, and shows your project, which now includes automatically generated project files. For example, the project has a folder that shows your logic app workflow's name. Inside this folder, the workflow.json file contains your logic app workflow's underlying JSON definition.

    Screenshot that shows the Explorer window with project folder, workflow folder, and "workflow.json" file.

Open the workflow definition file in Logic App Designer

  1. Check the versions that are installed on your computer by running the this command:

    ..\Users\{yourUserName}\dotnet --list-sdks

    If you have .NET Core SDK 5.x, this version might prevent you from opening the logic app's underlying workflow definition in the designer. Rather than uninstall this version, in your project's root location, create a global.json file that references the .NET Core runtime 3.x version that you have that's later than 3.1.201, for example:

    {
       "sdk": {
          "version": "3.1.8",
          "rollForward": "disable"
       }
    }
    

    Make sure that you explicitly add that global.json file to your project at the root location from inside Visual Studio Code. Otherwise, the designer won't open.

  2. If Visual Studio Code is running on Windows or Linux, make sure that the Azure Storage Emulator is running. For more information, review the Prerequisites.

  3. Expand the project folder for your workflow. Open the workflow.json file's shortcut menu, and select Open in Designer.

    Screenshot that shows Explorer pane and shortcut window for the workflow.json file with "Open in Designer" selected.

    If you get the error message that the Workflow design time could not be started, make sure that the Azure Storage Emulator is running. Otherwise, try these other troubleshooting suggestions:

    In Visual Studio Code, check the output from the preview extension.

    1. From the View menu, select Output.

    2. From the list on the Output title bar, select Azure Logic Apps so that you can view the output for the preview extension, for example:

      Screenshot that shows Visual Studio Code's Output window with "Azure Logic Apps" selected.

    3. Review the output and check whether this error message appears:

      A host error has occurred during startup operation '{operationID}'.
      System.Private.CoreLib: The file 'C:\Users\{userName}\AppData\Local\Temp\Functions\
      ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows\1.1.1\bin\
      DurableTask.AzureStorage.dll' already exists.
      Value cannot be null. (Parameter 'provider')
      Application is shutting down...
      Initialization cancellation requested by runtime.
      Stopping host...
      Host shutdown completed.
      

      This error can happen if you previously tried to open the designer, and then discontinued or deleted your project. To resolve this error, delete the ExtensionBundles folder at this location ...\Users\{your-username}\AppData\Local\Temp\Functions\ExtensionBundles, and retry opening the workflow.json file in the designer.

  4. From the Enable connectors in Azure list, select Use connectors from Azure, which applies to all managed connectors that are available and deployed in Azure, not just connectors for Azure services.

    Screenshot that shows Explorer pane with "Enable connectors in Azure" list open and "Use connectors from Azure" selected.

    Note

    Stateless workflows currently support only actions for managed connectors, which are deployed in Azure, and not triggers. Although you have the option to enable connectors in Azure for your stateless workflow, the designer doesn't show any managed connector triggers for you to select.

  5. From the resource groups list, select Create new resource group.

    Screenshot that shows Explorer pane with resource groups list and "Create new resource group" selected

  6. Provide a name for the resource group, and press Enter. This example uses example-logic-app-preview-rg.

    Screenshot that shows Explorer pane and resource group name box.

  7. From the locations list, find and select a supported Azure region to use for creating your resource group and resources. This example uses West Central US.

    Important

    Not all regions are currently supported, but updates to add more regions are underway. Selecting an unsupported region might result in problems, such as creating connections. For the currently supported regions, review the preview extension's Known Issues GitHub page.

    Screenshot that shows Explorer pane with locations list and "West Central US" selected.

    After you perform this step, Visual Studio Code opens the Logic App Designer.

    Note

    When Visual Studio Code starts the workflow design-time API, a message appears that startup might take a few seconds. You can ignore this message or select OK.

    After the Logic App Designer appears, the Choose an operation prompt appears on the designer and is selected by default, which shows the Add an action pane.

    Screenshot that shows Logic App Designer.

  8. Next, add a trigger and actions to your workflow.

Add a trigger and actions

After you open the Logic App Designer from your workflow.json file's shortcut menu, the Choose an operation prompt appears on the designer and is selected by default. You can now start creating your workflow by adding a trigger and actions.

The logic app workflow in this example uses this trigger and these actions:

  • The built-in Request trigger, When a HTTP request is received, which receives inbound calls or requests and creates an endpoint that other services or logic apps can call.

  • The Office 365 Outlook action, Send an email.

  • The built-in Response action, which you use to send a reply and return data back to the caller.

Add the Request trigger

  1. Next to the designer, in the Add a trigger pane, under the Choose an operation search box, make sure that Built-in is selected so that you can select a trigger that runs natively.

  2. In the Choose an operation search box, enter when a http request, and select the built-in Request trigger that's named When a HTTP request is received.

    Screenshot that shows Logic App Designer and Add a trigger pane with "When a HTTP request is received" trigger selected.

    When the trigger appears on the designer, the trigger's details pane opens to show the trigger's properties, settings, and other actions.

    Screenshot that shows Logic App Designer with the "When a HTTP request is received" trigger selected and trigger details pane open.

    Tip

    If the details pane doesn't appear, makes sure that the trigger is selected on the designer.

  3. If you have to delete an item on the designer, follow these steps:

    1. On the designer, select the item, which opens the item's details pane to the right side.

    2. Expand the Visual Studio Code window widely enough so that next to the trigger or action name, the ellipses (...) button appears in the uppermost right corner.

    3. Open the ellipses (...) menu, and select Delete. To confirm the deletion, select OK.

      Screenshot that shows selected item on designer with open details pane and with selected ellipses button and "Delete" option.

Add the Office 365 Outlook action

  1. On the designer, under the trigger that you added, select New step.

    The Choose an operation prompt appears on the designer, and the Add an action pane reopens so that you can select the next action.

  2. On the Add an action pane, under the Choose an operation search box, select Azure so that you can find and select an action for a managed connector that's deployed in Azure.

    This example selects and uses the Office 365 Outlook action, Send an email (V2).

    Screenshot that shows Logic App Designer and Add an action pane with Office 365 Outlook "Send an email" action selected.

  3. In the action's details pane, select Sign in so that you can create a connection to your email account.

    Screenshot that shows Logic App Designer and Send an email (V2) pane with "Sign in" selected.

    Note

    If you get the error, Failed to create connection..., you might have chosen a currently unsupported region for your logic app. Updates to add more regions are underway. Meanwhile, for the currently supported regions, review the preview extension's Known Issues GitHub page.

  4. When Visual Studio Code prompts you for consent to access your email account, select Open.

    Screenshot that shows the Visual Studio Code prompt to permit access.

    Tip

    To prevent future prompts, select Configure Trusted Domains so that you can add the authentication page as a trusted domain.

  5. Follow the subsequent prompts to sign in, allow access, and allow returning to Visual Studio Code.

    Note

    If too much time passes before you complete the prompts, the authentication process times out and fails. In this case, return to the designer and retry signing in to create the connection.

  6. When the Azure Logic Apps preview extension prompts you for consent to access your email account, select Open. Follow the subsequent prompt to allow access.

    Screenshot that shows the preview extension prompt to permit access.

    Tip

    To prevent future prompts, select Don't ask again for this extension.

    After Visual Studio Code creates your connection, some connectors show the message that The connection will be valid for {n} days only. This time limit applies only to the duration while you author your logic app in Visual Studio Code. After deployment, this limit no longer applies because your logic app can authenticate at runtime by using its automatically enabled system-assigned managed identity. This managed identity differs from the authentication credentials or connection string that you use when you create a connection. If you disable this system-assigned managed identity, connections won't work at runtime.

  7. On the designer, if the Send an email action doesn't appear selected, select that action.

  8. On the action's details pane, on the Parameters tab, provide the required information for the action, for example:

    Screenshot that shows Logic App Designer with details for Office 365 Outlook "Send an email" action.

    Property Required Value Description
    To Yes <your-email-address> The email recipient, which can be your email address for test purposes. This example uses the fictitious email, sophiaowen@fabrikam.com.
    Subject Yes An email from your example workflow The email subject
    Body Yes Hello from your example workflow! The email body content

    Note

    If you want to make any changes in the details pane on the Settings, Run After, or Static Result tab, make sure that you select Done to commit those changes before you switch tabs or change focus to the designer. Otherwise, Visual Studio Code won't keep your changes. For more information, review the preview extension's Known Issues GitHub page.

  9. On the designer, select Save.

Next, run and debug your workflow locally in Visual Studio Code.

Run and debug locally

To test your logic app, follow these steps to start a debugging session and find the URL for the endpoint that's created by the Request trigger. You need this URL so that you can later send a request to that endpoint.

  1. To help you more easily debug a stateless logic app workflow, you can enable the run history for that workflow.

  2. On the Visual Studio Code toolbar, open the Run menu, and select Start Debugging (F5).

    The Terminal window opens so that you can review the debugging session.

  3. Now, find the callback URL for the endpoint on the Request trigger.

    1. Reopen the Explorer pane so that you can view your project.

    2. From the workflow.json file's shortcut menu, select Overview.

      Screenshot that shows the Explorer pane and shortcut window for the workflow.json file with "Overview" selected.

    3. Find the Callback URL value, which looks similar to this URL for the example Request trigger:

      http://localhost:7071/api/<workflow-name>/triggers/manual/invoke?api-version=2020-05-01-preview&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<shared-access-signature>

      Screenshot that shows your workflow's overview page with callback URL

  4. To test the callback URL by triggering the logic app workflow, open Postman or your preferred tool for creating and sending requests.

    This example continues by using Postman. For more information, see Postman Getting Started.

    1. On the Postman toolbar, select New.

      Screenshot that shows Postman with New button selected

    2. On the Create New pane, under Building Blocks, select Request.

    3. In the Save Request window, under Request name, provide a name for the request, for example, Test workflow trigger.

    4. Under Select a collection or folder to save to, select Create Collection.

    5. Under All Collections, provide a name for the collection to create for organizing your requests, press Enter, and select Save to <collection-name>. This example uses Logic Apps requests as the collection name.

      Postman's request pane opens so that you can send a request to the callback URL for the Request trigger.

      Screenshot that shows Postman with the opened request pane

    6. Return to Visual Studio Code. from the workflow's overview page, copy the Callback URL property value.

    7. Return to Postman. On the request pane, next the method list, which currently shows GET as the default request method, paste the callback URL that you previously copied in the address box, and select Send.

      Screenshot that shows Postman and callback URL in the address box with Send button selected

      The example logic app workflow sends an email that appears similar to this example:

      Screenshot that shows Outlook email as described in the example

  5. In Visual Studio Code, return to your workflow's overview page.

    If you created a stateful workflow, after the request that you sent triggers the workflow, the overview page shows the workflow's run status and history.

    Tip

    If the run status doesn't appear, try refreshing the overview page by selecting Refresh. No run happens for a trigger that's skipped due to unmet criteria or finding no data.

    Screenshot that shows the workflow's overview page with run status and history

    Run status Description
    Aborted The run stopped or didn't finish due to external problems, for example, a system outage or lapsed Azure subscription.
    Cancelled The run was triggered and started but received a cancellation request.
    Failed At least one action in the run failed. No subsequent actions in the workflow were set up to handle the failure.
    Running The run was triggered and is in progress, but this status can also appear for a run that is throttled due to action limits or the current pricing plan.

    Tip: If you set up diagnostics logging, you can get information about any throttle events that happen.

    Succeeded The run succeeded. If any action failed, a subsequent action in the workflow handled that failure.
    Timed out The run timed out because the current duration exceeded the run duration limit, which is controlled by the Run history retention in days setting. A run's duration is calculated by using the run's start time and run duration limit at that start time.

    Note: If the run's duration also exceeds the current run history retention limit, which is also controlled by the Run history retention in days setting, the run is cleared from the runs history by a daily cleanup job. Whether the run times out or completes, the retention period is always calculated by using the run's start time and current retention limit. So, if you reduce the duration limit for an in-flight run, the run times out. However, the run either stays or is cleared from the runs history based on whether the run's duration exceeded the retention limit.

    Waiting The run hasn't started or is paused, for example, due to an earlier workflow instance that's still running.
  6. To review the statuses for each step in a specific run and the step's inputs and outputs, select the ellipses (...) button for that run, and select Show Run.

    Screenshot that shows your workflow's run history row with ellipses button and "Show Run" selected

    Visual Studio Code opens the monitoring view and shows the status for each step in the run.

    Screenshot that shows each step in the workflow run and their status

    Here are the possible statuses that each step in the workflow can have:

    Action status Icon Description
    Aborted Icon for "Aborted" action status The action stopped or didn't finish due to external problems, for example, a system outage or lapsed Azure subscription.
    Cancelled Icon for "Cancelled" action status The action was running but received a cancellation request.
    Failed Icon for "Failed" action status The action failed.
    Running Icon for "Running" action status The action is currently running.
    Skipped Icon for "Skipped" action status The action was skipped because the immediately preceding action failed. An action has a runAfter condition that requires that the preceding action finishes successfully before the current action can run.
    Succeeded Icon for "Succeeded" action status The action succeeded.
    Succeeded with retries Icon for "Succeeded with retries" action status The action succeeded but only after one or more retries. To review the retry history, in the run history details view, select that action so that you can view the inputs and outputs.
    Timed out Icon for "Timed out" action status The action stopped due to the timeout limit specified by that action's settings.
    Waiting Icon for "Waiting" action status Applies to a webhook action that's waiting for an inbound request from a caller.
  7. To review the inputs and outputs for each step, select the step that you want to inspect.

    Screenshot that shows the status for each step in the workflow plus the inputs and outputs in the expanded "Send an email" action

  8. To further review the raw inputs and outputs for that step, select Show raw inputs or Show raw outputs.

  9. To stop the debugging session, on the Run menu, select Stop Debugging (Shift + F5).

Return a response to the caller

To return a response back to the caller that sent a request to your logic app, you can use the built-in Response action for a workflow that starts with the Request trigger.

  1. On the Logic App Designer, under the Send an email action, select New step.

    The Choose an operation prompt appears on the designer, and the Add an action pane reopens so that you can select the next action.

  2. On the Add an action pane, under the Choose an action search box, make sure that Built-in is selected. In the search box, enter response, and select the Response action.

    Screenshot that shows Logic App Designer with the Response action selected.

    When the Response action appears on the designer, the action's details pane automatically opens.

    Screenshot that shows Logic App Designer with the "Response" action's details pane open and the "Body" property set to the "Send an email" action's "Body" property value.

  3. On the Parameters tab, provide the required information for the function that you want to call.

    This example returns the Body property value that's output from the Send an email action.

    1. Click inside the Body property box so that the dynamic content list appears and shows the available output values from the preceding trigger and actions in the workflow.

      Screenshot that shows the "Response" action's details pane with the mouse pointer inside the "Body" property so that the dynamic content list appears.

    2. In the dynamic content list, under Send an email, select Body.

      Screenshot that shows the open dynamic content list. In the list, under the "Send an email" header, the "Body" output value is selected.

      When you're done, the Response action's Body property is now set to the Send an email action's Body output value.

      Screenshot that shows the status for each step in the workflow plus the inputs and outputs in the expanded "Response" action.

  4. On the designer, select Save.

Retest your logic app

After you make updates to your logic app, you can run another test by rerunning the debugger in Visual Studio and sending another request to trigger your updated logic app, similar to the steps in Debug and test your logic app.

  1. On the Visual Studio Code toolbar, open the Run menu, and select Start Debugging (F5).

  2. In Postman or your tool for creating and sending requests, send another request to trigger your workflow.

  3. If you created a stateful workflow, on the workflow's overview page, check the status for the most recent run. To view the status, inputs, and outputs for each step in that run, select the ellipses (...) button for that run, and select Show Run.

    For example, here's the step-by-step status for a run after the sample workflow was updated with the Response action.

    Screenshot that shows the status for each step in the updated workflow plus the inputs and outputs in the expanded "Response" action.

  4. To stop the debugging session, on the Run menu, select Stop Debugging (Shift + F5).

Publish to Azure

From Visual Studio Code, you can deploy your project directly to Azure, which publishes your logic app using the new Logic App (Preview) resource type. Similar to the function app resource in Azure Functions, deployment for this new resource type requires that you select a hosting plan and pricing tier, which you can set up during deployment. For more information about hosting plans and pricing, review these topics:

You can publish your logic app as a new resource, which automatically creates any additional necessary resources, such as an Azure Storage account, similar to function app requirements. Or, you can publish your logic app to a previously deployed Logic App (Preview) resource, which overwrites that logic app.

Publish as a new Logic App (Preview) resource

  1. On the Visual Studio Code toolbar, select the Azure icon.

  2. On the Azure: Logic Apps (Preview) pane toolbar, select Deploy to Logic App.

    Screenshot that shows the "Azure: Logic Apps (Preview)" pane and pane's toolbar with "Deploy to Logic App" selected.

  3. From the list that Visual Studio Code opens, select from these options:

    • Create new Logic App (Preview) in Azure (quick)
    • Create new Logic App (Preview) in Azure Advanced
    • A previously deployed Logic App (Preview) resource, if any exist

    This example continues with Create new Logic App (Preview) in Azure Advanced.

    Screenshot that shows the "Azure: Logic Apps (Preview)" pane with a list with "Create new Logic App (Preview) in Azure" selected.

  4. To create your new Logic App (Preview) resource, follow these steps:

    1. Provide a globally unique name for your new logic app, which is the name to use for the Logic App (Preview) resource. This example uses example-logic-app-preview.

      Screenshot that shows the "Azure: Logic Apps (Preview)" pane and a prompt to provide a name for the new logic app to create.

    2. Select a hosting plan for your new logic app, either App Service Plan or Premium. This example selects App Service Plan.

      Screenshot that shows the "Azure: Logic Apps (Preview)" pane and a prompt to select "App Service Plan" or "Premium".

    3. Create a new App Service plan or select an existing plan. This example selects Create new App Service Plan.

      Screenshot that shows the "Azure: Logic Apps (Preview)" pane and a prompt to "Create new App Service Plan" or select an existing App Service plan.

    4. Provide a name for your App Service plan, and then select a pricing tier for the plan. This example selects the F1 Free plan.

      Screenshot that shows the "Azure: Logic Apps (Preview)" pane and a prompt to select a pricing tier.

    5. For optimal performance, find and select the same resource group as your project for the deployment.

      Note

      Although you can create or use a different resource group, doing so might affect performance. If you create or choose a different resource group, but cancel after the confirmation prompt appears, your deployment is also canceled.

    6. For stateful workflows, select Create new storage account or an existing storage account.

      Screenshot that shows the "Azure: Logic Apps (Preview)" pane and a prompt to create or select a storage account.

    7. For easier diagnostics logging and tracing capability, you can select an existing Application Insights resource. Otherwise, you can select Create new Application Insights resource, or set up Application Insights in the Azure portal after you deploy your app.

      Before you deploy, make sure that you add the logLevel object to the logging object in the host.json file that exists at your project's root level, and set the Host.Triggers.Workflow to Information, for example:

      "logLevel": {
         "Host.Triggers.Workflow": "Information"
      },
      

      Here's how the host.json file might look:

      {
         "version": "2.0",
         "logging": {
            "applicationInsights": {
               "samplingExcludedTypes": "Request",
               "samplingSettings": {
                  "isEnabled": true
               }
            },
            "logLevel": {
               "Host.Triggers.Workflow": "Information"
            }
         }
      }
      

    When you're done, Visual Studio Code starts creating and deploying the resources necessary for publishing your logic app.

  5. To review and monitor the deployment process, on the View menu, select Output. From the Output window toolbar list, select Azure Logic Apps.

    Screenshot that shows the Output window with the "Azure Logic Apps" selected in the toolbar list along with the deployment progress and statuses.

    When Visual Studio Code finishes deploying your logic app workflow to Azure, this message appears:

    Screenshot that shows a message that deployment to Azure successfully completed.

    Congratulations, your logic app is now live in Azure and enabled by default.

Next, you can learn how to perform these tasks:

Find and manage deployed logic apps in Visual Studio Code

In Visual Studio Code, you can view all the deployed logic apps in your Azure subscription, whether they are the original Logic Apps or the Logic App (Preview) resource type, and select tasks that help you manage those logic apps. However, to access both resource types, you need both the Azure Logic Apps and the Azure Logic Apps (Preview) extensions for Visual Studio Code.

  1. On the left toolbar, select the Azure icon. In the Azure: Logic Apps (Preview) pane, expand your subscription, which shows all the deployed logic apps for that subscription.

  2. Find and select the logic app that you want to manage. Open the logic app's shortcut menu, and select the task that you want to perform.

    For example, you can select tasks such as stopping, starting, restarting, or deleting your deployed logic app.

    Screenshot that shows Visual Studio Code with the opened "Azure Logic Apps (Preview)" extension pane and the deployed workflow.

  3. To view all the workflows in the logic app, expand your logic app, and then expand the Workflows node.

  4. To view a specific workflow, open the workflow's shortcut menu, and select Open in Designer, which opens the workflow in read-only mode.

    To edit the workflow, you have these options:

    • In Visual Studio Code, open your project's workflow.json file in the Logic App Designer, make your edits, and redeploy your logic app to Azure.

    • In the Azure portal, find and open your logic app. Find, edit, and save the workflow.

  5. To open the deployed logic app in the Azure portal, open the logic app's shortcut menu, and select Open in Portal.

    The Azure portal opens in your browser, signs you in to the portal automatically if you're signed in to Visual Studio Code, and shows your logic app.

    Screenshot that shows the Azure portal page for your logic app in Visual Studio Code.

    You can also sign in separately to the Azure portal, use the portal search box to find your logic app, and then select your logic app from the results list.

    Screenshot that shows the Azure portal and the search bar with search results for deployed logic app, which appears selected.

Find and manage deployed logic apps in the portal

In the Azure portal, you can view all the deployed logic apps that are in your Azure subscription, whether they are the original Logic Apps resource type or the Logic App (Preview) resource type. Currently, each resource type is organized and managed as separate categories in Azure.

Note

For public preview, you can only view deployed Logic App (Preview) resources in the Azure portal, not create new Logic App (Preview) resources. You can create these logic apps only in Visual Studio Code. However, you can add workflows to deployed logic apps with this resource type.

To find logic apps that have the Logic App (Preview) resource type, follow these steps:

  1. In the Azure portal search box, enter logic app preview. When the results list appears, under Services, select Logic App (Preview).

    Screenshot that shows the Azure portal search box with the "logic app preview" search text.

  2. On the Logic App (Preview) pane, find and select the logic app that you deployed from Visual Studio Code.

    Screenshot that shows the Azure portal and the Logic App (Preview) resources deployed in Azure.

    The Azure portal opens the individual resource page for the selected logic app.

    Screenshot that shows your logic app workflow's resource page in the Azure portal.

  3. To view the workflows in this logic app, on the logic app's menu, select Workflows.

    The Workflows pane shows all the workflows in the current logic app. This example shows the workflow that you created in Visual Studio Code.

    Screenshot that shows a "Logic App (Preview)" resource page with the "Workflows" pane open and the deployed workflow

  4. To view a workflow, on the Workflows pane, select that workflow.

    The workflow pane opens and shows more information and tasks that you can perform on that workflow.

    For example, to view the steps in the workflow, select Designer.

    Screenshot that shows the selected workflow's "Overview" pane, while the workflow menu shows the selected "Designer" command.

    The Logic App Designer opens and shows the workflow that you built in Visual Studio Code. You can now make changes to this workflow in the Azure portal.

    Screenshot that shows the Logic App Designer and workflow deployed from Visual Studio Code.

Add a workflow to deployed logic apps

Through the Azure portal, you can add blank workflows to a Logic App (Preview) resource that you deployed from Visual Studio Code and build those workflows in the Azure portal.

  1. In the Azure portal, find and select your deployed Logic App (Preview) resource.

  2. On the logic app's menu, select Workflows. On the Workflows pane, select Add.

    Screenshot that shows the selected logic app's "Workflows" pane and toolbar with "Add" command selected.

  3. In the New workflow pane, provide name for the workflow. Select either Stateful or Stateless > Create.

    After Azure deploys your new workflow, which appears on the Workflows pane, select that workflow to perform management and other tasks, such as opening the Logic App Designer or code view.

    Screenshot that shows the selected workflow with management and review options.

    For example, opening the designer for a new workflow shows a blank canvas. You can now build this workflow in the Azure portal.

    Screenshot that shows the Logic App Designer and a blank workflow.

Run history for stateless logic app workflows

To more easily debug a stateless logic app workflow, you can enable the run history for that workflow in either Visual Studio Code or in the Azure portal, and then disable the run history when you're done.

For a stateless logic app workflow in Visual Studio Code

If you are working on and running the stateless logic app workflow locally in Visual Studio Code, follow these steps:

  1. In your project, find and expand the workflow-designtime folder. Find and open the local.settings.json file.

  2. Add the Workflows.{yourWorkflowName}.operationOptions property and set the value to WithStatelessRunHistory, for example:

    {
       "IsEncrypted": false,
       "Values": {
          "AzureWebJobsStorage": "UseDevelopmentStorage=true",
          "FUNCTIONS_WORKER_RUNTIME": "dotnet",
          "Workflows.{yourWorkflowName}.OperationOptions": "WithStatelessRunHistory"
       }
    }
    
  3. To disable the run history when you're done, either delete the Workflows.{yourWorkflowName}.OperationOptions property and its value, or set the property to None.

For a stateless logic app workflow in the Azure portal

If you already deployed your project to the Azure portal, follow these steps:

  1. In the Azure portal, find and open your Logic App (Preview) resource.

  2. On the logic app's menu, under Settings, select Configuration.

  3. On the Application Settings tab, select New application setting.

  4. On the Add/Edit application setting pane, in the Name box, enter this operation option name:

    Workflows.{yourWorkflowName}.OperationOptions

  5. In the Value box, enter the following value: WithStatelessRunHistory

    For example:

    Screenshot that shows the Azure portal and Logic App (Preview) resource with the "Configuration" > "New application setting" < "Add/Edit application setting" pane open and the "Workflows.{yourWorkflowName}.OperationOptions" option set to "WithStatelessRunHistory".

  6. When you're done, select OK. On the Configuration pane, select Save.

To enable monitoring on your deployed Logic App (Preview) resource, continue to the next section.

Enable monitoring for deployed Logic App (Preview) resources

To enable monitoring on a deployed Logic App (Preview) resource, follow these steps:

  1. In the Azure portal, find and select the deployed Logic App (Preview) resource.

  2. On that resource's menu, under API, select CORS.

  3. On the CORS pane, under Allowed Origins, add the wildcard character (*).

  4. When you're done, on the CORS toolbar, select Save.

    Screenshot that shows the Azure portal with a deployed Logic Apps (Preview) resource. On the resource menu, "CORS" is selected with a new entry for "Allowed Origins" set to the wildcard "*" character.

Deploy to Docker container

By using the .NET Core command-line interface (CLI) tool, you can build your project, and then publish your build. You can then build and use a Docker container as the destination for deploying your logic app workflow. For more information, review these topics:

  1. To build your project, open a command-line prompt, and run this command:

    dotnet build -c release

    For more information, see the dotnet build reference page.

  2. Publish your build by running this command:

    dotnet publish -c release

    For more information, see the dotnet publish reference page.

  3. Build a Docker container by using a Docker file for a .NET workflow and running this command:

    docker build --tag local/workflowcontainer .

    For example, here is a sample Docker file that deploys a stateful logic app and specifies the connection string for the Azure Storage account that was used to publish the logic app to the Azure portal. To find and copy the storage account's connection string in the Azure portal, review Manage storage account keys.

    Screenshot that shows the Azure portal with storage account access keys and connection string copied.

    The connection string looks similar to this sample:

    DefaultEndpointsProtocol=https;AccountName=fabrikamstorageaccount;AccountKey={access-key};EndpointSuffix=core.windows.net

    Here's the format for the Docker file:

    FROM mcr.microsoft.com/azure-functions/dotnet:3.0.14492-appservice
    
    ENV AzureWebJobsStorage <storage-account-connection-string>
    ENV AZURE_FUNCTIONS_ENVIRONMENT Development
    ENV AzureWebJobsScriptRoot=/home/site/wwwroot
    ENV AzureFunctionsJobHost__Logging__Console__IsEnabled=true
    ENV FUNCTIONS_V2_COMPATIBILITY_MODE=true
    
    COPY ./bin/Release/netcoreapp3.1/publish/ /home/site/wwwroot
    

    For more information, see docker build.

  4. Save the string somewhere safe so that you can later add the string to the local.settings.json files in the project that you use for creating your logic app in Visual Studio Code.

  5. Run the container locally by using this command:

    docker run -e WEBSITE_HOSTNAME=localhost -p 8080:80 local/workflowcontainer

    For more information, see docker run.

  6. To get the callback URL for the Request trigger, send this request:

    POST /runtime/webhooks/workflow/api/management/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2019-10-01-edge-preview&code={master-key}

    The <master-key> value is defined in the Azure storage account that you set for AzureWebJobsStorage in the file, azure-webjobs-secrets/{deployment-name}/host.json, where you can find the value in this section:

    {
      <...>
      "masterKey": {
         "name": "master",
         "value": "<master-key>",
         "encrypted": false
      },
      <...>
    }
    

Nested behavior differences between stateful and stateless logic apps

You can make a logic app workflow callable from other logic app workflows that exist in the same Logic App (Preview) resource by using the Request trigger, HTTP Webhook trigger, or managed connector triggers that have the ApiConnectionWehook type and can receive HTTPS requests.

Here are the behavior patterns that nested logic app workflows can follow after a parent workflow calls a child workflow:

  • Asynchronous polling pattern

    The parent doesn't wait for a response to their initial call, but continually checks the child's run history until the child finishes running. By default, stateful workflows follow this pattern, which is ideal for long-running child workflows that might exceed request timeout limits.

  • Synchronous pattern ("fire and forget")

    The child acknowledges the call by immediately returning a 202 ACCEPTED response, and the parent continues to the next action without waiting for the results from the child. Instead, the parent receives the results when the child finishes running. Child stateful workflows that don't include a Response action always follow the synchronous pattern. For child stateful workflows, the run history is available for you to review.

    To enable this behavior, in the workflow's JSON definition, set the operationOptions property to DisableAsyncPattern. For more information, see Trigger and action types - Operation options.

  • Trigger and wait

    For a child stateless workflow, the parent waits for a response that returns the results from the child. This pattern works similar to using the built-in HTTP trigger or action to call a child workflow. Child stateless workflows that don't include a Response action immediately return a 202 ACCEPTED response, but the parent waits for the child to finish before continuing to the next action. These behaviors apply only to child stateless workflows.

This table specifies the child workflow's behavior based on whether the parent and child are stateful, stateless, or are mixed workflow types:

Parent workflow Child workflow Child behavior
Stateful Stateful Asynchronous or synchronous with "operationOptions": "DisableAsyncPattern" setting
Stateful Stateless Trigger and wait
Stateless Stateful Synchronous
Stateless Stateless Trigger and wait

Limits

Although many existing limits for Azure Logic Apps are the same for this resource type, here are the differences in this public preview extension:

  • Managed connectors: 50 requests per minute per connection

  • For the Inline Code action for JavaScript action, these limits have changed:

    • The limit on code characters increases from 1,024 characters to 100,000 characters.

    • The limit on time to run the code increases from five seconds to 15 seconds.

Next steps

We'd like to hear from you about your experiences with this public preview extension!