Create a Standard logic app workflow for single-tenant Azure Logic Apps using Visual Studio Code

Article
02/22/2023
50 minutes to read

Applies to: Azure Logic Apps (Standard)

This how-to guide shows how to create an example integration workflow that runs in single-tenant Azure Logic Apps by using Visual Studio Code with the Azure Logic Apps (Standard) extension. Before you create this workflow, you'll create a Standard logic app resource, which provides the following capabilities:

Your logic app can include multiple stateful and stateless workflows.
Workflows in the same logic app and tenant run in the same process as the Azure Logic Apps runtime, so they share the same resources and provide better performance.
You can locally create, run, and test workflows using the Visual Studio Code development environment.

When you're ready, you can deploy your logic app to Azure where your workflow can run in the single-tenant Azure Logic Apps environment or in an App Service Environment v3 (Windows-based App Service plans only). You can also deploy and run your workflow anywhere that Kubernetes can run, including Azure, Azure Kubernetes Service, on premises, or even other cloud providers, due to the Azure Logic Apps containerized runtime. For more information about single-tenant Azure Logic Apps, review Single-tenant versus multi-tenant and integration service environment.

While the example workflow is cloud-based and has only two steps, you can create workflows from hundreds of operations that can connect a wide range of apps, data, services, and systems across cloud, on premises, and hybrid environments. The example workflow starts with the built-in Request trigger and follows with an Office 365 Outlook action. The trigger creates a callable endpoint for the workflow and waits for an inbound HTTPS request from any caller. When the trigger receives a request and fires, the next action runs by sending email to the specified email address along with selected outputs from the trigger.

Tip

If you don't have an Office 365 account, you can use any other available action that can send messages from your email account, for example, Outlook.com.

To create this example workflow using the Azure portal instead, follow the steps in Create integration workflows using single tenant Azure Logic Apps and the Azure portal. Both options provide the capability to develop, run, and deploy logic app workflows in the same kinds of environments. However, with Visual Studio Code, you can locally develop, test, and run workflows in your development environment.

Screenshot that shows Visual Studio Code, logic app project, and workflow.

As you progress, you'll complete these high-level tasks:

Create a project for your logic app and a blank stateful workflow.
Add a trigger and an action.
Run, test, debug, and review run history locally.
Find domain name details for firewall access.
Deploy to Azure, which includes optionally enabling Application Insights.
Manage your deployed logic app in Visual Studio Code and the Azure portal.
Enable run history for stateless workflows.
Enable or open the Application Insights after deployment.

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.
An Azure account and subscription. If you don't have a subscription, sign up for a free Azure account.
To create the same example workflow 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 a different email connector, such as Outlook.com, you can still follow the example, and the general overall steps are the same. However, your 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

For local development in Visual Studio Code, you need to set up a local data store for your logic app project and workflows to use for running in your local development environment. You can use and run the Azurite storage emulator as your local data store.

Download and install Azurite 3.12.0 or later for your Windows, macOS, or Linux operating system. You can install either from inside Visual Studio Code or by using npm.
Before you run your logic app workflow, make sure to start the emulator.

For more information, review the Azurite documentation.

Tools

Install the following tools and versions for your specific operating system: Windows, macOS, or Linux.

Visual Studio Code, which is free. Also, download and install these 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 workflow.
- .NET SDK 6.x.x, which includes the .NET Runtime 6.x.x, a prerequisite for the Azure Logic Apps (Standard) runtime.
- Azure Functions Core Tools - 4.x version
  - Windows: Use the Microsoft Installer (MSI) version, which is func-cli-X.X.XXXX-x*.msi.
  - macOS
  - Linux
  These tools include a version of the same runtime that powers the Azure Functions runtime, which the Azure Logic Apps (Standard) extension uses in Visual Studio Code.
  - 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.
  - Azure Functions v3 support in Azure Logic Apps ends on March 31, 2023. Starting mid-October 2022, new Standard logic app workflows in the Azure portal automatically use Azure Functions v4. Since January 31, 2023, existing Standard workflows in the Azure portal were automatically migrated to Azure Functions v4.
    
    Unless you deployed your Standard logic apps as NuGet-based projects, pinned your logic apps to a specific bundle version, or Microsoft determined that you had to take action before the automatic migration, this upgrade is designed to require no action from you nor have a runtime impact. However, if the exceptions apply to you, or for more information about Azure Functions v3 support, see Azure Logic Apps Standard now supports Azure Functions v4.
- Azure Logic Apps (Standard) extension for Visual Studio Code.
  
  Important
  
  Projects created with earlier preview extensions no longer work. To continue, uninstall any earlier versions, and recreate your logic app projects.
  
  To install the Azure Logic Apps (Standard) 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 standard. From the results list, select Azure Logic Apps (Standard) > Install.
    
    After the installation completes, the extension appears in the Extensions: Installed list.
    
    Tip
    
    If the extension doesn't appear in the installed list, try restarting Visual Studio Code.
  Currently, you can have both Consumption (multi-tenant) and Standard (single-tenant) extensions installed at the same time. The development experiences differ from each other in some ways, but your Azure subscription can include both Standard and Consumption logic app types. Visual Studio Code shows all the deployed logic apps in your Azure subscription, but organizes your apps under each extension, Azure Logic Apps (Consumption) and Azure Logic Apps (Standard).
To use the Inline Code Operations action that runs JavaScript, install Node.js versions 12.x.x or 14.x.x.

Tip

For Windows, download the MSI version. If you use the ZIP version instead, you have to manually make Node.js available by using a PATH environment variable for your operating system.
To locally run webhook-based triggers and actions, such as the built-in HTTP Webhook trigger, in Visual Studio Code, you need to set up forwarding for the callback URL.
To test the example workflow in this article, you need a tool that can send calls to the endpoint created by the Request trigger. If you don't have such a tool, you can download, install, and use the Postman app.
If you create your logic app resources with settings that support using Application Insights, you can optionally enable diagnostics logging and tracing for your logic app. You can do so either when you create your logic app or after deployment. You need to have an Application Insights instance, but you can create this resource either in advance, when you create your logic app, or after deployment.

Set up Visual Studio Code

To make sure that all the extensions are correctly installed, reload or restart Visual Studio Code.
Confirm that Visual Studio Code automatically finds and installs extension updates so that all your extensions get the latest updates. Otherwise, you have to manually uninstall the outdated version and install the latest version.
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.

By default, the following settings are enabled and set for the Azure Logic Apps (Standard) extension:

Azure Logic Apps Standard: Project Runtime, which is set to version ~3

Note

This version is required to use the Inline Code Operations actions.
Azure Logic Apps Standard: Experimental View Manager, which enables the latest designer in Visual Studio Code. If you experience problems on the designer, such as dragging and dropping items, turn off this setting.

To find and confirm these settings, follow these steps:

On the File menu, go to Preferences > Settings.
On the User tab, go to > Extensions > Azure Logic Apps (Standard).

For example, you can find the Azure Logic Apps Standard: Project Runtime setting here or use the search box to find other settings:

Connect to your Azure account

On the Visual Studio Code Activity Bar, select the Azure icon.
In the Azure pane, under Azure: Logic Apps (Standard), select Sign in to Azure. When the Visual Studio Code authentication page appears, sign in with your Azure account.

After you sign in, the Azure pane shows the subscriptions in your Azure account. If you also have the publicly released extension, you can find any logic apps that you created with that extension in the Logic Apps section, not the Logic Apps (Standard) 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.
  
  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, run, 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 apps and function apps can't exist in the same project.

On your computer, create an empty local folder to use for the project that you'll later create in Visual Studio Code.
In Visual Studio Code, close all open folders.
In the Azure pane, next to Azure: Logic Apps (Standard), select Create New Project (icon that shows a folder and lightning bolt).
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.
Browse to the location where you created your project folder, select that folder and continue.
From the templates list that appears, select either Stateful Workflow or Stateless Workflow. This example selects Stateful Workflow.
Provide a name for your workflow and press Enter. This example uses Fabrikam-Stateful-Workflow as the name.

Note

You might get an error named azureLogicAppsStandard.createNewProject with the error message, Unable to write to Workspace Settings because azureFunctions.suppressProject is not a registered configuration. If you do, try installing the Azure Functions extension for Visual Studio Code, either directly from the Visual Studio Marketplace or from inside Visual Studio Code.

Visual Studio Code finishes creating your project, and opens the workflow.json file for your workflow in the code editor.

Note

If you're prompted to select how to open your project, select Open in current window if you want to open your project in the current Visual Studio Code window. To open a new instance for Visual Studio Code, select Open in new window.

From the Visual Studio toolbar, open the Explorer pane, if not already open.

The Explorer pane shows your project, which now includes automatically generated project files. For example, the project has a folder that shows your workflow's name. Inside this folder, the workflow.json file contains your workflow's underlying JSON definition.

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

In Visual Studio Code, your logic app project has either of the following types:

Extension bundle-based (Node.js), which is the default type
NuGet package-based (.NET), which you can convert from the default type

Based on these types, your project includes slightly different folders and files. A NuGet-based project includes a .bin folder that contains packages and other library files. A bundle-based project doesn't include the .bin folder and other files. Some scenarios require a NuGet-based project for your app to run, for example, when you want to develop and run custom built-in operations. For more information about converting your project to use NuGet, review Enable built-connector authoring.

For the default bundle-based project, your project has a folder and file structure that is similar to the following example:

MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
  || Maps 
     ||| MapName1
     ||| ...
  || Schemas
     ||| SchemaName1
     ||| ...
| WorkflowName1
  || workflow.json
  || ...
| WorkflowName2
  || workflow.json
  || ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json

At your project's root level, you can find the following files and folders with other items:

Name	Folder or file	Description
.vscode	Folder	Contains Visual Studio Code-related settings files, such as extensions.json, launch.json, settings.json, and tasks.json files.
Artifacts	Folder	Contains integration account artifacts that you define and use in workflows that support business-to-business (B2B) scenarios. For example, the example structure includes maps and schemas for XML transform and validation operations.
*<WorkflowName>*	Folder	For each workflow, the <WorkflowName> folder includes a workflow.json file, which contains that workflow's underlying JSON definition.
workflow-designtime	Folder	Contains development environment-related settings files.
.funcignore	File	Contains information related to your installed Azure Functions Core Tools.
connections.json	File	Contains the metadata, endpoints, and keys for any managed connections and Azure functions that your workflows use. Important: To use different connections and functions for each environment, make sure that you parameterize this connections.json file and update the endpoints.
host.json	File	Contains runtime-specific configuration settings and values, for example, the default limits for the single-tenant Azure Logic Apps platform, logic apps, workflows, triggers, and actions. At your logic app project's root level, the host.json metadata file contains the configuration settings and default values that all workflows in the same logic app use while running, whether locally or in Azure. Note: When you create your logic app, Visual Studio Code creates a backup *host.snapshot..json** file in your storage container. If you delete your logic app, this backup file isn't deleted. If you create another logic app with the same name, another snapshot file is created. You can have only up to 10 snapshots for the same logic app. If you exceed this limit, you get the following error: `Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))` To resolve this error, delete the extra snapshot files from your storage container.
local.settings.json	File	Contains app settings, connection strings, and other settings that your workflows use while running locally. In other words, these settings and values apply only when you run your projects in your local development environment. During deployment to Azure, the file and settings are ignored and aren't included with your deployment. This file stores settings and values as local environment variables that are used by your local development tools as the `appSettings` values. You can call and reference these environment variables both at runtime and deployment time by using app settings and parameters. Important: The local.settings.json file can contain secrets, so make sure that you also exclude this file from your project source control.

Enable built-in connector authoring

You can create your own built-in connectors for any service you need by using the single-tenant Azure Logic Apps extensibility framework. Similar to built-in connectors such as Azure Service Bus and SQL Server, these connectors provide higher throughput, low latency, local connectivity, and run natively in the same process as the single-tenant Azure Logic Apps runtime.

The authoring capability is currently available only in Visual Studio Code, but isn't enabled by default. To create these connectors, you need to first convert your project from extension bundle-based (Node.js) to NuGet package-based (.NET).

Important

This action is a one-way operation that you can't undo.

In the Explorer pane, at your project's root, move your mouse pointer over any blank area below all the other files and folders, open the shortcut menu, and select Convert to Nuget-based Logic App project.
When the prompt appears, confirm the project conversion.
To continue, review and follow the steps in the article, Azure Logic Apps Running Anywhere - Built-in connector extensibility.

Open the workflow definition file in the designer

Expand the project folder for your workflow. Open the workflow.json file's shortcut menu, and select Open in Designer.
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.

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.
From the Select subscription list, select the Azure subscription to use for your logic app project.
From the resource groups list, select Create new resource group.
Provide a name for the resource group, and press Enter. This example uses Fabrikam-Workflows-RG.
From the locations list, select the Azure region to use when creating your resource group and resources. This example uses West Central US.

After you perform this step, Visual Studio Code opens the workflow designer.

Note

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

If the designer won't open, review the troubleshooting section, Designer fails to open.

After the designer appears, the Choose an operation prompt appears on the designer and is selected by default, which shows the Add an action pane.
Next, add a trigger and actions to your workflow.

Add a trigger and actions

After you open the designer, 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 workflow in this example uses this trigger and these actions:

The built-in Request trigger, When an 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

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.
In the Choose an operation search box, enter when a http request, and select the built-in Request trigger that's named When an HTTP request is received.

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

Tip

If the details pane doesn't appear, makes sure that the trigger is selected on the designer.
If you need to delete an item from the designer, follow these steps for deleting items from the designer.

Add the Office 365 Outlook action

On the designer, under the trigger that you added, select the plus sign (+) > Add an action.

The Choose an operation prompt appears on the designer, and the Add an action pane reopens so that you can select the next action.
On the Add an action pane, under the Choose an operation search box, select Azure so that you can 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).
In the action's details pane, select Sign in so that you can create a connection to your email account.
When Visual Studio Code prompts you for consent to access your email account, select Open.

Tip

To prevent future prompts, select Configure Trusted Domains so that you can add the authentication page as a trusted domain.
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.
When the Azure Logic Apps (Standard) extension prompts you for consent to access your email account, select Open. Follow the subsequent prompt to allow 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.
On the designer, if the Send an email action doesn't appear selected, select that action.

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

Screenshot that shows the workflow 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, Static Result, or Run After 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.

On the designer, select Save.

Important

To locally run a workflow that uses a webhook-based trigger or actions, such as the built-in HTTP Webhook trigger or action, you must enable this capability by setting up forwarding for the webhook's callback URL.

Enable locally running webhooks

When you use a webhook-based trigger or action, such as HTTP Webhook, with a logic app running in Azure, the Logic Apps runtime subscribes to the service endpoint by generating and registering a callback URL with that endpoint. The trigger or action then waits for the service endpoint to call the URL. However, when you're working in Visual Studio Code, the generated callback URL starts with http://localhost:7071/.... This URL is for your localhost server, which is private so the service endpoint can't call this URL.

To locally run webhook-based triggers and actions in Visual Studio Code, you need to set up a public URL that exposes your localhost server and securely forwards calls from the service endpoint to the webhook callback URL. You can use a forwarding service and tool such as ngrok, which opens an HTTP tunnel to your localhost port, or you can use your own equivalent tool.

Set up call forwarding using ngrok

Sign up for an ngrok account if you don't have one. Otherwise, sign in to your account.
Get your personal authentication token, which your ngrok client needs to connect and authenticate access to your account.
1. To find your authentication token page, on your account dashboard menu, expand Authentication, and select Your Authtoken.
2. From the Your Authtoken box, copy the token to a safe location.
From the ngrok download page or your account dashboard, download the ngrok version that you want, and extract the .zip file. For more information, see Step 1: Unzip to install.
On your computer, open your command prompt tool. Browse to the location where you have the ngrok.exe file.
Connect the ngrok client to your ngrok account by running the following command. For more information, see Step 2: Connect your account.

ngrok authtoken <your_auth_token>
Open the HTTP tunnel to localhost port 7071 by running the following command. For more information, see Step 3: Fire it up.

ngrok http 7071
From the output, find the following line:

http://<domain>.ngrok.io -> http://localhost:7071
Copy and save the URL that has this format: http://<domain>.ngrok.io

Set up the forwarding URL in your app settings

In Visual Studio Code, on the designer, add the HTTP + Webhook trigger or action.
When the prompt appears for the host endpoint location, enter the forwarding (redirection) URL that you previously created.

Note

Ignoring the prompt causes a warning to appear that you must provide the forwarding URL, so select Configure, and enter the URL. After you finish this step, the prompt won't reappear for subsequent webhook triggers or actions that you might add.

To make the prompt reappear, at your project's root level, open the local.settings.json file's shortcut menu, and select Configure Webhook Redirect Endpoint. The prompt now appears so you can provide the forwarding URL.

Visual Studio Code adds the forwarding URL to the local.settings.json file in your project's root folder. In the Values object, the property that's named Workflows.WebhookRedirectHostUri now appears and is set to the forwarding URL, for example:
```
{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "node",
      "FUNCTIONS_V2_COMPATIBILITY_MODE": "true",
      <...>
      "Workflows.WebhookRedirectHostUri": "http://xxxXXXXxxxXXX.ngrok.io",
      <...>
   }
}
```
Note

If your project is NuGet package-based (.NET), not extension bundle-based (Node.js), "FUNCTIONS_WORKER_RUNTIME" is set to "dotnet". However, to use Inline Code Operations, you must have "FUNCTIONS_WORKER_RUNTIME" set to "node"

The first time when you start a local debugging session or run the workflow without debugging, the Logic Apps runtime registers the workflow with the service endpoint and subscribes to that endpoint for notifying the webhook operations. The next time that your workflow runs, the runtime won't register or resubscribe because the subscription registration already exists in local storage.

When you stop the debugging session for a workflow run that uses locally run webhook-based triggers or actions, the existing subscription registrations aren't deleted. To unregister, you have to manually remove or delete the subscription registrations.

Note

After your workflow starts running, the terminal window might show errors like this example:

message='Http request failed with unhandled exception of type 'InvalidOperationException' and message: 'System.InvalidOperationException: Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.'

In this case, open the local.settings.json file in your project's root folder, and make sure that the property is set to true:

"FUNCTIONS_V2_COMPATIBILITY_MODE": "true"

Manage breakpoints for debugging

Before you run and test your logic app workflow by starting a debugging session, you can set breakpoints inside the workflow.json file for each workflow. No other setup is required.

At this time, breakpoints are supported only for actions, not triggers. Each action definition has these breakpoint locations:

Set the starting breakpoint on the line that shows the action's name. When this breakpoint hits during the debugging session, you can review the action's inputs before they're evaluated.
Set the ending breakpoint on the line that shows the action's closing curly brace (}). When this breakpoint hits during the debugging session, you can review the action's results before the action finishes running.

To add a breakpoint, follow these steps:

Open the workflow.json file for the workflow that you want to debug.
On the line where you want to set the breakpoint, in the left column, select inside that column. To remove the breakpoint, select that breakpoint.

When you start your debugging session, the Run view appears on the left side of the code window, while the Debug toolbar appears near the top.

Note

If the Run view doesn't automatically appear, press Ctrl+Shift+D.
To review the available information when a breakpoint hits, in the Run view, examine the Variables pane.
To continue workflow execution, on the Debug toolbar, select Continue (play button).

You can add and remove breakpoints at any time during the workflow run. However, if you update the workflow.json file after the run starts, breakpoints don't automatically update. To update the breakpoints, restart the logic app.

For general information, see Breakpoints - Visual Studio Code.

Run, test, 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.

To debug a stateless workflow more easily, you can enable the run history for that workflow.
On the Visual Studio Code Activity Bar, open the Run menu, and select Start Debugging (F5).

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

Note

If you get the error, "Error exists after running preLaunchTask 'generateDebugSymbols'", see the troubleshooting section, Debugging session fails to start.
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.
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&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<shared-access-signature>
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.
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.
  
  In Postman, the request pane opens so that you can send a request to the callback URL for the Request trigger.
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.
  
  The example logic app workflow sends an email that appears similar to this example:

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

The following table shows the possible final statuses that each workflow run can have and show in Visual Studio Code:

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.

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

Note

If a run failed and a step in monitoring view shows the 400 Bad Request error, this problem might result from a longer trigger name or action name that causes the underlying Uniform Resource Identifier (URI) to exceed the default character limit. For more information, see "400 Bad Request".

The following table shows the possible statuses that each workflow action can have and show in Visual Studio Code:

Action status	Description
Aborted	The action stopped or didn't finish due to external problems, for example, a system outage or lapsed Azure subscription.
Cancelled	The action was running but received a request to cancel.
Failed	The action failed.
Running	The action is currently running.
Skipped	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	The action succeeded.
Succeeded with retries	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	The action stopped due to the timeout limit specified by that action's settings.
Waiting	Applies to a webhook action that's waiting for an inbound request from a caller.

To review the inputs and outputs for each step, select the step that you want to inspect.
To further review the raw inputs and outputs for that step, select Show raw inputs or Show raw outputs.
To stop the debugging session, on the Run menu, select Stop Debugging (Shift + F5).

Return a response

To return a response 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.

On the workflow designer, under the Send an email action, select the plus sign (+) > Add an action.

The Choose an operation prompt appears on the designer, and the Add an action pane reopens so that you can select the next action.
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.

When the Response action appears on the designer, the action's details pane automatically opens.
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.
2. In the dynamic content list, under Send an email, select Body.
  
  When you're done, the Response action's Body property is now set to the Send an email action's Body output value.
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 Run, test, and debug locally.

On the Visual Studio Code Activity Bar, open the Run menu, and select Start Debugging (F5).
In Postman or your tool for creating and sending requests, send another request to trigger your workflow.
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.
To stop the debugging session, on the Run menu, select Stop Debugging (Shift + F5).

Find domain names for firewall access

Before you deploy and run your logic app workflow in the Azure portal, if your environment has strict network requirements or firewalls that limit traffic, you have to set up permissions for any trigger or action connections that exist in your workflow.

To find the fully qualified domain names (FQDNs) for these connections, follow these steps:

In your logic app project, open the connections.json file, which is created after you add the first connection-based trigger or action to your workflow, and find the managedApiConnections object.

For each connection that you created, copy and save the connectionRuntimeUrl property value somewhere safe so that you can set up your firewall with this information.

This example connections.json file contains two connections, an AS2 connection and an Office 365 connection with these connectionRuntimeUrl values:

AS2: "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/as2/11d3fec26c87435a80737460c85f42ba
Office 365: "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/office365/668073340efe481192096ac27e7d467f

{
   "managedApiConnections": {
      "as2": {
         "api": {
            "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region}/managedApis/as2"
         },
         "connection": {
            "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group}/providers/Microsoft.Web/connections/{connection-resource-name}"
         },
         "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/as2/11d3fec26c87435a80737460c85f42ba,
         "authentication": {
            "type":"ManagedServiceIdentity"
         }
      },
      "office365": {
         "api": {
            "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region}/managedApis/office365"
         },
         "connection": {
            "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group}/providers/Microsoft.Web/connections/{connection-resource-name}"
         },
         "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/office365/668073340efe481192096ac27e7d467f,
         "authentication": {
            "type":"ManagedServiceIdentity"
         }
      }
   }
}

Deploy to Azure

From Visual Studio Code, you can directly publish your project to Azure, which deploys your logic app using the Logic App (Standard) resource type. You can publish your logic app as a new resource, which automatically creates any 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 (Standard) resource, which overwrites that logic app.

Deployment for the Logic App (Standard) resource type requires a hosting plan and pricing tier, which you select during deployment. For more information, review Hosting plans and pricing tiers.

Publish to a new Logic App (Standard) resource

On the Visual Studio Code Activity Bar, select the Azure icon.
On the Azure: Logic Apps (Standard) pane toolbar, select Deploy to Logic App.
If prompted, select the Azure subscription to use for your logic app deployment.
From the list that Visual Studio Code opens, select from these options:
- Create new Logic App (Standard) in Azure (quick)
- Create new Logic App (Standard) in Azure Advanced
- A previously deployed Logic App (Standard) resource, if any exist
This example continues with Create new Logic App (Standard) in Azure Advanced.

To create your new Logic App (Standard) resource, follow these steps:

Provide a globally unique name for your new logic app, which is the name to use for the Logic App (Standard) resource. This example uses Fabrikam-Workflows-App.
Select a hosting plan for your new logic app. Either create a name for your plan, or select an existing plan (Windows-based App Service plans only). This example selects Create new App Service Plan.
Provide a name for your hosting plan, and then select a pricing tier for your selected plan.

For more information, review Hosting plans and pricing tiers.
For optimal performance, 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.
For stateful workflows, select Create new storage account or an existing storage account.

If your logic app's creation and deployment settings support using Application Insights, you can optionally enable diagnostics logging and tracing for your logic app. You can do so either when you deploy your logic app from Visual Studio Code or after deployment. You need to have an Application Insights instance, but you can create this resource either in advance, when you deploy your logic app, or after deployment.

To enable logging and tracing now, follow these steps:

Select either an existing Application Insights resource or Create new Application Insights resource.
In the Azure portal, go to your Application Insights resource.
On the resource menu, select Overview. Find and copy the Instrumentation Key value.
In Visual Studio Code, in your project's root folder, open the local.settings.json file.
In the Values object, add the APPINSIGHTS_INSTRUMENTATIONKEY property, and set the value to the instrumentation key, for example:
```
{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "node",
      "APPINSIGHTS_INSTRUMENTATIONKEY": <instrumentation-key>
   }
}
```
Tip

You can check whether the trigger and action names correctly appear in your Application Insights instance.
1. In the Azure portal, go to your Application Insights resource.
2. On the resource resource menu, under Investigate, select Application map.
3. Review the operation names that appear in the map.
Some inbound requests from built-in triggers might appear as duplicates in the Application Map. Rather than use the WorkflowName.ActionName format, these duplicates use the workflow name as the operation name and originate from the Azure Functions host.

Next, you can optionally adjust the severity level for the tracing data that your logic app collects and sends to your Application Insights instance.

Each time that a workflow-related event happens, such as when a workflow is triggered or when an action runs, the runtime emits various traces. These traces cover the workflow's lifetime and include, but aren't limited to, the following event types:

Service activity, such as start, stop, and errors.
Jobs and dispatcher activity.
Workflow activity, such as trigger, action, and run.
Storage request activity, such as success or failure.
HTTP request activity, such as inbound, outbound, success, and failure.
Any development traces, such as debug messages.

Each event type is assigned to a severity level. For example, the Trace level captures the most detailed messages, while the Information level captures general activity in your workflow, such as when your logic app, workflow, trigger, and actions start and stop. This table describes the severity levels and their trace types:

Severity level	Trace type
Critical	Logs that describe an unrecoverable failure in your logic app.
Debug	Logs that you can use for investigation during development, for example, inbound and outbound HTTP calls.
Error	Logs that indicate a failure in workflow execution, but not a general failure in your logic app.
Information	Logs that track the general activity in your logic app or workflow, for example: - When a trigger, action, or run starts and ends. - When your logic app starts or ends.
Trace	Logs that contain the most detailed messages, for example, storage requests or dispatcher activity, plus all the messages that are related to workflow execution activity.
Warning	Logs that highlight an abnormal state in your logic app but doesn't prevent its running.

To set the severity level, at your project's root level, open the host.json file, and find the logging object. This object controls the log filtering for all the workflows in your logic app and follows the ASP.NET Core layout for log type filtering.

{
   "version": "2.0",
   "logging": {
      "applicationInsights": {
         "samplingExcludedTypes": "Request",
         "samplingSettings": {
            "isEnabled": true
         }
      }
   }
}

If the logging object doesn't contain a logLevel object that includes the Host.Triggers.Workflow property, add those items. Set the property to the severity level for the trace type that you want, for example:

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

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

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

When Visual Studio Code finishes deploying your logic app to Azure, the following message appears:

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

Next, you can learn how to perform these tasks:

Add a blank workflow to your project.
Manage deployed logic apps in Visual Studio Code or by using the Azure portal.
Enable run history on stateless workflows.
Enable monitoring view in the Azure portal for a deployed logic app.

Add blank workflow to project

You can have multiple workflows in your logic app project. To add a blank workflow to your project, follow these steps:

On the Visual Studio Code Activity Bar, select the Azure icon.
In the Azure pane, next to Azure: Logic Apps (Standard), select Create Workflow (icon for Azure Logic Apps).
Select the workflow type that you want to add: Stateful or Stateless
Provide a name for your workflow.

When you're done, a new workflow folder appears in your project along with a workflow.json file for the workflow definition.

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 (Standard) 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 (Standard) extensions for Visual Studio Code.

On the left toolbar, select the Azure icon. In the Azure: Logic Apps (Standard) pane, expand your subscription, which shows all the deployed logic apps for that subscription.
Open the logic app that you want to manage. From the logic app's shortcut menu, 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. You can disable or enable a workflow by using the Azure portal.

Note

The stop logic app and delete logic app operations affect workflow instances in different ways. For more information, review Considerations for stopping logic apps and Considerations for deleting logic apps.
To view all the workflows in the logic app, expand your logic app, and then expand the Workflows node.
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 workflow designer, make your edits, and redeploy your logic app to Azure.
- In the Azure portal, open your logic app. You can then open, edit, and save your workflow.
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.

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.

Considerations for stopping logic apps

Stopping a logic app affects workflow instances in the following ways:

Azure Logic Apps cancels all in-progress and pending runs immediately.
Azure Logic Apps doesn't create or run new workflow instances.
Triggers won't fire the next time that their conditions are met. However, trigger states remember the points where the logic app was stopped. So, if you restart the logic app, the triggers fire for all unprocessed items since the last run.

To stop a trigger from firing on unprocessed items since the last run, clear the trigger state before you restart the logic app:
1. In Visual Studio Code, on the left toolbar, select the Azure icon.
2. In the Azure: Logic Apps (Standard) pane, expand your subscription, which shows all the deployed logic apps for that subscription.
3. Expand your logic app, and then expand the node that's named Workflows.
4. Open a workflow, and edit any part of that workflow's trigger.
5. Save your changes. This step resets the trigger's current state.
6. Repeat for each workflow.
7. When you're done, restart your logic app.

Considerations for deleting logic apps

Deleting a logic app affects workflow instances in the following ways:

Azure Logic Apps cancels in-progress and pending runs immediately, but doesn't run cleanup tasks on the storage used by the app.
Azure Logic Apps doesn't create or run new workflow instances.
If you delete a workflow and then recreate the same workflow, the recreated workflow won't have the same metadata as the deleted workflow. To refresh the metadata, you have to resave any workflow that called the deleted workflow. That way, the caller gets the correct information for the recreated workflow. Otherwise, calls to the recreated workflow fail with an Unauthorized error. This behavior also applies to workflows that use artifacts in integration accounts and workflows that call Azure functions.

Manage deployed logic apps in the portal

After you deploy a logic app to the Azure portal from Visual Studio Code, 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 (Standard) resource type. Currently, each resource type is organized and managed as separate categories in Azure. To find logic apps that have the Logic App (Standard) resource type, follow these steps:

In the Azure portal search box, enter logic apps. When the results list appears, under Services, select Logic apps.
On the Logic apps pane, select the logic app that you deployed from Visual Studio Code.

The Azure portal opens the individual resource page for the selected logic app.
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.
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.

The workflow 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.

Add another workflow in the portal

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

In the Azure portal, select your deployed Logic App (Standard) resource.
On the logic app menu, select Workflows. On the Workflows pane, select Add.
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 so that you can manage and perform other tasks, such as opening the designer or code view.

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

Enable run history for stateless workflows

To debug a stateless workflow more easily, you can enable the run history for that workflow, and then disable the run history when you're done. Follow these steps for Visual Studio Code, or if you're working in the Azure portal, see Create single-tenant based workflows in the Azure portal.

In your Visual Studio Code project, expand the folder that's named workflow-designtime, and open the local.settings.json file.

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

Windows

{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "node",
      "Workflows.{yourWorkflowName}.OperationOptions": "WithStatelessRunHistory"
   }
}

macOS or Linux

{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "DefaultEndpointsProtocol=https;AccountName=fabrikamstorageacct; \
          AccountKey=<access-key>;EndpointSuffix=core.windows.net",
      "FUNCTIONS_WORKER_RUNTIME": "node",
      "Workflows.{yourWorkflowName}.OperationOptions": "WithStatelessRunHistory"
   }
}

To disable the run history when you're done, either set the Workflows.{yourWorkflowName}.OperationOptionsproperty to None, or delete the property and its value.

Enable monitoring view in the Azure portal

After you deploy a Logic App (Standard) resource from Visual Studio Code to Azure, you can review any available run history and details for a workflow in that resource by using the Azure portal and the Monitor experience for that workflow. However, you first have to enable the Monitor view capability on that logic app resource.

In the Azure portal, select the deployed Logic App (Standard) resource.
On that resource's menu, under API, select CORS.
On the CORS pane, under Allowed Origins, add the wildcard character (*).
When you're done, on the CORS toolbar, select Save.

Enable or open Application Insights after deployment

During workflow execution, your logic app emits telemetry along with other events. You can use this telemetry to get better visibility into how well your workflow runs and how the Logic Apps runtime works in various ways. You can monitor your workflow by using Application Insights, which provides near real-time telemetry (live metrics). This capability can help you investigate failures and performance problems more easily when you use this data to diagnose issues, set up alerts, and build charts.

To enable Application Insights on a deployed logic app or to review Application Insights data when already enabled, follow these steps:

In the Azure portal, find your deployed logic app.
On the logic app menu, under Settings, select Application Insights.
If Application Insights isn't enabled, on the Application Insights pane, select Turn on Application Insights. After the pane updates, at the bottom, select Apply.

If Application Insights is enabled, on the Application Insights pane, select View Application Insights data.

After Application Insights opens, you can review various metrics for your logic app. For more information, review these topics:

Delete items from the designer

To delete an item in your workflow from the designer, follow any of these steps:

Select the item, open the item's shortcut menu (Shift+F10), and select Delete. To confirm, select OK.
Select the item, and press the delete key. To confirm, select OK.
Select the item so that details pane opens for that item. In the pane's upper right corner, open the ellipses (...) menu, and select Delete. To confirm, select OK.

Tip

If the ellipses menu isn't visible, expand Visual Studio Code window wide enough so that the details pane shows the ellipses (...) button in the upper right corner.

Troubleshoot errors and problems

Designer fails to open

When you try to open the designer, you get this error, "Workflow design time could not be started". If you previously tried to open the designer, and then discontinued or deleted your project, the extension bundle might not be downloading correctly. To check whether this cause is the problem, follow these steps:

In Visual Studio Code, open the Output window. From the View menu, select Output.
From the list in the Output window's title bar, select Azure Logic Apps (Standard) so that you can review output from the extension, for example:

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

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.

New triggers and actions are missing from the designer picker for previously created workflows

Single-tenant Azure Logic Apps supports built-in actions for Azure Function Operations, Liquid Operations, and XML Operations, such as XML Validation and Transform XML. However, for previously created logic apps, these actions might not appear in the designer picker for you to select if Visual Studio Code uses an outdated version of the extension bundle, Microsoft.Azure.Functions.ExtensionBundle.Workflows.

Also, the Azure Function Operations connector and actions don't appear in the designer picker unless you enabled or selected Use connectors from Azure when you created your logic app. If you didn't enable the Azure-deployed connectors at app creation time, you can enable them from your project in Visual Studio Code. Open the workflow.json shortcut menu, and select Use Connectors from Azure.

To fix the outdated bundle, follow these steps to delete the outdated bundle, which makes Visual Studio Code automatically update the extension bundle to the latest version.

Note

This solution applies only to logic apps that you create and deploy using Visual Studio Code with the Azure Logic Apps (Standard) extension, not the logic apps that you created using the Azure portal. See Supported triggers and actions are missing from the designer in the Azure portal.

Save any work that you don't want to lose, and close Visual Studio.
On your computer, browse to the following folder, which contains versioned folders for the existing bundle:

...\Users\{your-username}\.azure-functions-core-tools\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows
Delete the version folder for the earlier bundle, for example, if you have a folder for version 1.1.3, delete that folder.
Now, browse to the following folder, which contains versioned folders for required NuGet package:

...\Users\{your-username}\.nuget\packages\microsoft.azure.workflows.webjobs.extension
Delete the version folder for the earlier package.
Reopen Visual Studio Code, your project, and the workflow.json file in the designer.

The missing triggers and actions now appear in the designer.

"400 Bad Request" appears on a trigger or action

When a run fails, and you inspect the run in monitoring view, this error might appear on a trigger or action that has a longer name, which causes the underlying Uniform Resource Identifier (URI) to exceed the default character limit.

To resolve this problem and adjust for the longer URI, edit the UrlSegmentMaxCount and UrlSegmentMaxLength registry keys on your computer by following the steps below. These key's default values are described in this topic, Http.sys registry settings for Windows.

Important

Before you start, make sure that you save your work. This solution requires you to restart your computer after you're done so that the changes can take effect.

On your computer, open the Run window, and run the regedit command, which opens the registry editor.
In the User Account Control box, select Yes to permit your changes to your computer.
In the left pane, under Computer, expand the nodes along the path, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters, and then select Parameters.
In the right pane, find the UrlSegmentMaxCount and UrlSegmentMaxLength registry keys.
Increase these key values enough so that the URIs can accommodate the names that you want to use. If these keys don't exist, add them to the Parameters folder by following these steps:
1. From the Parameters shortcut menu, select New > DWORD (32-bit) Value.
2. In the edit box that appears, enter UrlSegmentMaxCount as the new key name.
3. Open the new key's shortcut menu, and select Modify.
4. In the Edit String box that appears, enter the Value data key value that you want in hexadecimal or decimal format. For example, 400 in hexadecimal is equivalent to 1024 in decimal.
5. To add the UrlSegmentMaxLength key value, repeat these steps.
After you increase or add these key values, the registry editor looks like this example:
When you're ready, restart your computer so that the changes can take effect.

Debugging session fails to start

When you try to start a debugging session, you get the error, "Error exists after running preLaunchTask 'generateDebugSymbols'". To resolve this problem, edit the tasks.json file in your project to skip symbol generation.

In your project, expand the folder that's named .vscode, and open the tasks.json file.

In the following task, delete the line, "dependsOn: "generateDebugSymbols", along with the comma that ends the preceding line, for example:

Before:

 {
   "type": "func",
   "command": "host start",
   "problemMatcher": "$func-watch",
   "isBackground": true,
   "dependsOn": "generateDebugSymbols"
 }

After:

 {
   "type": "func",
   "command": "host start",
   "problemMatcher": "$func-watch",
   "isBackground": true
 }

Next steps

We'd like to hear from you about your experiences with the Azure Logic Apps (Standard) extension!

For bugs or problems, create your issues in GitHub.
For questions, requests, comments, and other feedback, use this feedback form.

Create a Standard logic app workflow for single-tenant Azure Logic Apps using Visual Studio Code

Prerequisites

Access and connectivity

Storage requirements

Tools

Set up Visual Studio Code

Connect to your Azure account

Create a local project

Enable built-in connector authoring

Open the workflow definition file in the designer

Add a trigger and actions

Add the Request trigger

Add the Office 365 Outlook action

Enable locally running webhooks

Set up call forwarding using ngrok

Set up the forwarding URL in your app settings

Manage breakpoints for debugging

Run, test, and debug locally

Return a response

Retest your logic app

Find domain names for firewall access

Deploy to Azure

Publish to a new Logic App (Standard) resource

Add blank workflow to project

Manage deployed logic apps in Visual Studio Code

Considerations for stopping logic apps

Considerations for deleting logic apps

Manage deployed logic apps in the portal

Add another workflow in the portal

Enable run history for stateless workflows

Enable monitoring view in the Azure portal

Enable or open Application Insights after deployment

Delete items from the designer

Troubleshoot errors and problems

Designer fails to open

New triggers and actions are missing from the designer picker for previously created workflows

"400 Bad Request" appears on a trigger or action

Debugging session fails to start

Next steps

Feedback

Additional resources

Additional resources