Create an example Standard workflow in single-tenant Azure Logic Apps with the Azure portal

Applies to: Azure Logic Apps (Standard)

This how-to guide shows how to create an example automated workflow that waits for an inbound web request and then sends a message to an email account. More specifically, you'll create a Standard logic app resource, which can include multiple stateful and stateless workflows that run in single-tenant Azure Logic Apps.

While this 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 Request built-in trigger, which is followed by 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.

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

• Create a Standard logic app resource and add a blank stateful workflow.
• Add a trigger and action.
• Trigger a workflow run.
• View the workflow's run and trigger history.
• Enable or open the Application Insights after deployment.
• Enable run history for stateless workflows.

In single-tenant Azure Logic Apps, workflows in the same logic app resource and tenant run in the same process as the runtime, so they share the same resources and provide better performance. For more information about single-tenant Azure Logic Apps, see Single-tenant versus multitenant and integration service environment.

Prerequisites

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

• An Azure Storage account. If you don't have one, you can either create a storage account in advance or during logic app creation.

  Note

  The Standard logic app resource type is powered by Azure Functions and has storage requirements similar to function apps. Stateful workflows perform storage transactions, such as using queues for scheduling and storing workflow states in tables and blobs. These transactions incur storage charges. For more information about how stateful workflows store data in external storage, review Stateful and stateless workflows.

• To create the same example workflow in this guide, you need an Office 365 Outlook email account that uses a Microsoft work or school account to sign in.

  If you don't have an Office 365 account, you can use any other available email connector that can send messages from your email account, for example, Outlook.com. If you use a different email connector, 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.

• To test the example workflow in this guide, 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 Postman.

• If you create your logic app resource and enable 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.

• To deploy your Standard logic app resource to an App Service Environment v3 (ASEv3) - Windows plan only, you have to create this environment resource first. You can then select this environment as the deployment location when you create your logic app resource. For more information, review Resources types and environments and Create an App Service Environment.

• Starting mid-October 2022, new Standard logic app workflows in the Azure portal automatically use Azure Functions v4. Throughout November 2022, existing Standard workflows in the Azure portal are automatically migrating to Azure Functions v4. Unless you deployed your Standard logic apps as NuGet-based projects or pinned your logic apps to a specific bundle version, 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 v4 support, see Azure Logic Apps Standard now supports Azure Functions v4.

Create a Standard logic app resource

1. In the Azure portal, sign in with your Azure account.

2. In the Azure portal search box, enter logic apps, and select Logic apps.

   

3. On the Logic apps page, select Add.

4. On the Create Logic App page, on the Basics tab, provide the following basic information about your logic app:

   Property	Required	Value	Description
   Subscription	Yes	<Azure-subscription-name>	Your Azure subscription name.
   Resource Group	Yes	<Azure-resource-group-name>	The Azure resource group where you create your logic app and related resources. This name must be unique across regions and can contain only letters, numbers, hyphens (-), underscores (_), parentheses (()), and periods (.). This example creates a resource group named Fabrikam-Workflows-RG.
   Logic App name	Yes	<logic-app-name>	Your logic app resource name, which must be unique across regions and can contain only letters, numbers, hyphens (-), underscores (_), parentheses (()), and periods (.). Note: Your logic app's name automatically gets the suffix, .chinacloudsites.cn, because the Standard logic app resource is powered by the single-tenant Azure Logic Apps runtime, which uses the Azure Functions extensibility model and is hosted as an extension on the Azure Functions runtime. Azure Functions uses the same app naming convention. This example creates a logic app named Fabrikam-Workflows.

5. Before you continue making selections, go to the Plan section. For Plan type, select Standard so that you view only the settings that apply to the Standard plan-based logic app type.

   The Plan type property specifies the hosting plan and billing model to use for your logic app. For more information, review Hosting plans and pricing tiers.

   Plan type	Description
   Standard	This logic app type is the default selection. Workflows run in single-tenant Azure Logic Apps and use the Standard billing model.
   Consumption	This logic app type and workflow runs in global, multitenant Azure Logic Apps and uses the Consumption billing model.

   Property	Required	Value	Description
   Windows Plan	Yes	<plan-name>	The plan name to use. Either select an existing plan name or provide a name for a new plan. This example uses the name My-App-Service-Plan. Note: Only the Windows-based App Service plan is supported. Don't use a Linux-based App Service plan.
   Pricing plan	Yes	<pricing-tier>	The pricing tier to use for your logic app and workflows. Your selection affects the pricing, compute, memory, and storage that your logic app and workflows use. For more information, review Hosting plans and pricing tiers.

6. Now continue making the following selections:

   Property	Required	Value	Description
   Publish	Yes	Workflow	This option appears and applies only when Plan type is set to the Standard logic app type. By default, this option is set to Workflow and creates an empty logic app resource where you add your first workflow.
   Region	Yes	<Azure-region>	The Azure datacenter region to use for storing your app's information. This example deploys the sample logic app to the China North region in Azure. - If you want to deploy your app to an existing App Service Environment v3 resource, you can select that environment from the Region list.

   Note

   If you select an Azure region that supports availability zone redundancy, the Zone redundancy section is enabled. This section offers the choice to enable availability zone redundancy for your logic app. However, currently supported Azure regions don't include China North, so you can ignore this section for this example. For more information, see Protect logic apps from region failures with zone redundancy and availability zones.

   When you're done, your settings look similar to the following example:

   

7. On the Hosting tab, provide the following information about the storage solution and hosting plan to use for your logic app.

   Property	Required	Value	Description
   Storage type	Yes	- Azure Storage - SQL and Azure Storage	The storage type that you want to use for workflow-related artifacts and data. - To deploy only to Azure, select Azure Storage. - To use SQL as primary storage and Azure Storage as secondary storage, select SQL and Azure Storage, and review Set up SQL database storage for Standard logic apps in single-tenant Azure Logic Apps. Note: If you're deploying to an Azure region, you still need an Azure storage account, which is used to complete the one-time hosting of the logic app's configuration on the Azure Logic Apps platform. The workflow's state, run history, and other runtime artifacts are stored in your SQL database. For deployments to a custom location that's hosted on an Azure Arc cluster, you only need SQL as your storage provider.
   Storage account	Yes	<Azure-storage-account-name>	The Azure Storage account to use for storage transactions. This resource name must be unique across regions and have 3-24 characters with only numbers and lowercase letters. Either select an existing account or create a new account. This example creates a storage account named mystorageacct.

8. On the Networking tab, you can leave the default options for this example.

   For your specific, real-world scenarios, make sure to review and select the appropriate options. You can also change this configuration after you deploy your logic app resource. For more information, see Secure traffic between Standard logic apps and Azure virtual networks using private endpoints.

   Enable public access	Behavior
   On	Your logic app has a public endpoint with an inbound address that's open to the internet and can't access an Azure virtual network.
   Off	Your logic app has no public endpoint, but has a private endpoint instead for communication within an Azure virtual network, and is isolated to that virtual network. The private endpoint can communicate with endpoints in the virtual network, but only from clients within that network. This configuration also means that logic app traffic can be governed by network security groups or affected by virtual network routes.

   To enable your logic app to access endpoints in a virtual network, make sure to select the appropriate option:

   Enable network injection	Behavior
   On	Your logic app workflows can privately and securely communicate with endpoints in the virtual network.
   Off	Your logic app workflows can't communicate with endpoints in the virtual network.

9. If your creation and deployment settings support using Application Insights, you can optionally enable diagnostics logging and tracing for your logic app workflows.

   1. On the Monitoring tab, under Application Insights, set Enable Application Insights to Yes if not already selected.

   2. For the Application Insights setting, either select an existing Application Insights instance, or if you want to create a new instance, select Create new and provide the name that you want to use.

10. After Azure validates your logic app's settings, on the Review + create tab, select Create, for example:

    

    Note

    If you get a validation error during this step, open and review the error details. For example, if your selected region reaches a quota for resources that you're trying to create, you might have to try a different region.

    After Azure finishes deployment, your logic app resource is automatically live but doesn't do anything yet because the resource is empty, and you haven't added any workflows yet.

11. On the deployment completion page, select Go to resource so that you can add a blank workflow.

    

Add a blank workflow

After you create your empty logic app resource, you have to add your first workflow.

1. After Azure opens the resource, on your logic app resource menu, select Workflows. On the Workflows toolbar, select Add.

   

2. After the New workflow pane opens, provide a name for your workflow, and select the state type, either Stateful or Stateless. When you're done, select Create.

   This example adds a blank stateful workflow named Stateful-Workflow. By default, the workflow is enabled but doesn't do anything until you add a trigger and actions.

   

3. From the workflow list, select the blank stateful workflow.

4. On the workflow menu, under Developer, select Designer.

   The designer surface shows a prompt to select a trigger operation. By default, the prompt is already selected so that a pane with available triggers already appears open.

So now you'll add a trigger that starts your workflow.

Add a trigger

This example workflow starts with the built-in Request trigger named When a HTTP request is received. This trigger creates an endpoint that other services or logic app workflows can call and waits for those inbound calls or requests to arrive. Built-in operations run natively and directly within the Azure Logic Apps runtime.

1. On the workflow designer, make sure that your blank workflow is open and that the Add a trigger prompt is selected on the designer surface.

2. By using request as the search term, follow these steps to add the built-in Request trigger named When a HTTP request is received to your workflow.

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

   

3. Save your workflow. On the designer toolbar, select Save.

   When you save a workflow for the first time, and that workflow starts with a Request trigger, Azure Logic Apps automatically generates a URL for an endpoint that's created by the Request trigger. Later, when you test your workflow, you send a request to this URL, which fires the trigger and starts the workflow run.

Add an action

This example workflow continues with the Office 365 Outlook managed connector action named Send an email. Managed connector operations run in Azure versus natively and directly on the Azure Logic Apps runtime.

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

   The Add an action pane opens so that you can select the next action.

2. By using office send an email as the search term, follow these steps to add the Office 365 Outlook action that's named Send an email (V2) to your workflow.

3. In the action's information pane, on the Create Connection tab, select Sign in so that you can create a connection to your email account.

   

4. When you're prompted for access to your email account, sign in with your account credentials.

   Note

   If you get the error message, "Failed with error: 'The browser is closed.'. Please sign in again", check whether your browser blocks third-party cookies. If these cookies are blocked, try adding https://portal.azure.cn to the list of sites that can use cookies. If you're using incognito mode, make sure that third-party cookies aren't blocked while working in that mode.

   If necessary, reload the page, open your workflow, add the email action again, and try creating the connection.

   After Azure creates the connection, the Send an email action appears on the designer and is selected by default. If the action isn't selected, select the action so that its information pane is also open.

5. In the action information pane, on the Parameters tab, provide the required information for the action, for example:

   

   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

   When making any changes in the information pane on the Settings, Static Result, or Run After tabs, make sure that you select Done to commit those changes before you switch tabs or change focus to the designer. Otherwise, the designer won't keep your changes.

6. Save your workflow. On the designer toolbar, select Save.

7. 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, review Find domain names for firewall access.

   Otherwise, to test your workflow, manually trigger a run.

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 information 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 your browser window wide enough so that the information pane shows the ellipses (...) button in the upper right corner.

Find domain names for firewall access

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

To find the inbound and outbound IP addresses used by your logic app and workflows, follow these steps:

1. On your logic app menu, under Settings, select Networking (preview).

2. On the networking page, find and review the Inbound Traffic and Outbound Traffic sections.

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

1. On your logic app menu, under Workflows, select Connections. On the API Connections tab, select the connection's resource name, for example:

   

2. Expand your browser wide enough so that when JSON View appears in the browser's upper right corner, select JSON View.

   

3. Copy and save the connectionRuntimeUrl property value somewhere safe so that you can set up your firewall with this information.

   

4. For each connection, repeat the relevant steps.

Trigger the workflow

In this example, the workflow runs when the Request trigger receives an inbound request, which is sent to the URL for the endpoint that's created by the trigger. When you saved the workflow for the first time, Azure Logic Apps automatically generated this URL. So, before you can send this request to trigger the workflow, you need to find this URL.

1. On the workflow designer, select the Request trigger that's named When a HTTP request is received.

2. After the information pane opens, on the Parameters tab, find the HTTP POST URL property. To copy the generated URL, select the Copy Url (copy file icon), and save the URL somewhere else for now. The URL follows this format:

   https://<*logic-app-name*>.chinacloudsites.cn:443/api/<*workflow-name*>/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<*shared-access-signature*>

   

   For this example, the URL looks like this:

   https://fabrikam-workflows.chinacloudsites.cn:443/api/Fabrikam-Stateful-Workflow/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=xxxxxXXXXxxxxxXXXXxxxXXXXxxxxXXXX

   Tip

   You can also find the endpoint URL on your logic app's Overview pane in the Workflow URL property.

   1. On the resource menu, select Overview.
   2. On the Overview pane, find the Workflow URL property.
   3. To copy the endpoint URL, move your pointer over the end of the endpoint URL text, and select Copy to clipboard (copy file icon).

3. To test the URL by sending a request, 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 the Postman app, the request pane opens so that you can send a request to the endpoint URL for the Request trigger.

      

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

      

      When the trigger fires, the example workflow runs and sends an email that appears similar to this example:

      

Best practices and recommendations

For optimal designer responsiveness and performance, review and follow these guidelines:

• Use no more than 50 actions per workflow. Exceeding this number of actions raises the possibility for slower designer performance.

• Consider splitting business logic into multiple workflows where necessary.

• Have no more than 10-15 workflows per logic app resource.

Review workflow run history

After a stateful workflow finishes running, you can view the workflow's run history, including the status for the overall run, for the trigger, and for each action along with their inputs and outputs. In the Azure portal, workflow run history and trigger history appear at the workflow level, not at the logic app resource level. For more information, see Review workflow run history and Review trigger history.

For this example workflow, the workflow run history looks similar to the following sample:

Review trigger history

For a stateful workflow, you can review the trigger history for each run, including the trigger status along with inputs and outputs, separately from the workflow run history. In the Azure portal, trigger history and run history appear at the workflow level, not the logic app level. For more information, see Review trigger history.

Resubmit workflow run with same inputs

For an existing stateful workflow run, you can rerun the entire workflow with the same inputs that were previously used for that run. For more information, see Rerun a workflow with same inputs.

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 the Azure portal, or if you're working in Visual Studio Code, see Create stateful and stateless workflows in Visual Studio Code.

1. In the Azure portal, open your Standard logic app 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

   

6. To finish this task, select OK. On the Configuration pane toolbar, select Save.

7. To disable the run history when you're done, either set the property named Workflows.{your-workflow-name}.OperationOptions to None, or delete the property and its value.

Enable or open Application Insights after deployment

During workflow run, 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.

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 workflow. You can do so either when you create your logic app resource in the Azure portal 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.

Enable Application Insights on a deployed logic app

1. In the Azure portal, find your deployed logic app.

2. On the logic app menu, under Settings, select Application Insights.

3. On the Application Insights pane, select Turn on Application Insights.

4. After the pane updates, at the bottom, select Apply > Yes.

5. On the Application Insights pane, select View Application Insights data.

   After the Application Insights dashboard opens, you can review metrics or logs for your logic app workflow. For example, to chart or query for data, on the Application Insights resource menu, under Monitoring, select Metrics or Logs.

Open Application Insights

1. In the Azure portal, find your deployed logic app.

2. On the logic app menu, under Settings, select Application Insights.

3. On the Application Insights pane, select View Application Insights data.

   After the Application Insights dashboard opens, you can review metrics or logs for your logic app workflow. For example, to chart or query for data, on the Application Insights resource menu, under Monitoring, select Metrics or Logs.

View connections

When you create connections in a workflow using connectors managed by Azure or service provider based, built-in connectors, these connections are actually separate Azure resources with their own resource definitions.

Stop or start logic app resources

Follow the steps in Disable or enable logic apps.

Troubleshoot problems and errors

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 for you to select if your logic app uses an outdated version of the extension bundle, Microsoft.Azure.Functions.ExtensionBundle.Workflows.

To fix this problem, follow these steps to delete the outdated version so that the extension bundle can automatically update to the latest version.

1. In the Azure portal, stop your logic app.

   1. On your logic app menu, select Overview.

   2. On the Overview pane's toolbar, select Stop.

2. On your logic app menu, under Development Tools, select Advanced Tools.

3. On the Advanced Tools pane, select Go, which opens the Kudu environment for your logic app.

4. On the Kudu toolbar, open the Debug console menu, and select CMD.

   A console window opens so that you can browse to the bundle folder using the command prompt. Or, you can browse the directory structure that appears above the console window.

5. Browse to the following folder, which contains versioned folders for the existing bundle:

   ...\home\data\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows

6. Delete the version folder for the existing bundle. In the console window, you can run this command where you replace {bundle-version} with the existing version:

   rm -rf {bundle-version}

   For example: rm -rf 1.1.3

   Tip

   If you get an error such as "permission denied" or "file in use", refresh the page in your browser, and try the previous steps again until the folder is deleted.

7. In the Azure portal, return to your logic app's Overview page, and select Restart.

   The portal automatically gets and uses the latest bundle.

Next steps

• Monitor workflow run status, review trigger and workflow run history, and set up alerts in Azure Logic Apps