Logic App Workflow (Standard)

Introduction

A workflow is a set of steps that define a specific task or process. Each workflow begins with a single trigger, followed by one or more actions. The workflow of a Logic App in the Standard pricing plan is referred to as standard workflow.

The Logic App Standard resource type allows customers to create two different types of workflows within the same Logic App: Stateful workflow and Stateless workflow.

A stateful workflow saves the inputs and outputs for each Action and their states in external storage, allowing for reviewing run details and history after each workflow execution. Stateful workflows also offer high resilience in the event of an outage.

A stateless workflow is created when users do not need to keep, review, or refer to data from previous events in external storage after each run finishes for later review. These workflows save all the inputs and outputs for each Action and their states in memory only, not in external storage.

Enable & Disable

Users can perform the following actions using Turbo360:

• Enable or Disable a Logic App Workflow to reflect its status in the Azure Subscription.

• Bulk Start / Stop operations can be performed using a single click in the Logic App Workflow (Standard) resource section.

Run trigger

• Turbo360 allows users to invoke the Logic App Workflows (Standard) by sending a message to the trigger.

• The Run trigger option allows users to modify a message and resubmit it to an endpoint, allowing their Logic App Workflows to be recovered from the error condition.

• When a user enters a specific Logic App Workflow (Standard), the Run trigger option appears at the top to invoke the trigger. By providing the trigger details and sending the message, the triggering operation can be performed.

Run history

• Run history displays a list of Logic App Workflow executions, including their start time, duration, and associated tags.

• Clicking on a run identifier opens detailed information for that specific run. Users can drill down into each trigger and action within a run to analyze the workflow execution, including the trigger inputs and outputs.

Enhanced Run history view

• The improved Run history view enhances how users analyze Logic App Workflow executions by shifting from a static list to a more interactive and visual experience. This new approach provides greater clarity into how workflows execute over time, while also enabling users to resubmit runs directly from the same view for quicker recovery.

• By organizing execution steps into a timeline, users can easily trace the path of a run, inspect individual actions, and access detailed inputs and outputs—all within a unified view. This streamlined experience supports faster troubleshooting, improved traceability, and more confident decision-making.

Optional settings

• Users can make use of the Optional Settings in the Run history tab to perform the following options.

Advanced Search

Logic App Workflow runs can be filtered using Advanced search by choosing the From date and To date along with any one of the following statuses:

• Succeeded
• Running
• Failed
• Cancelled
• Waiting
• Skipped
• Suspended
• Paused
• Timed Out
• Aborted

Search by identifier

• Search by identifier allows users to retrieve the run details for the identifier they input.

Get Retry Chain by identifier

• It is also possible to get the Retry chain by entering the run identifier.

• Apart from this optional setting, users can also get the retry chain by clicking on the tag next to the run identifier.

Resubmit failed Workflow runs

• A Logic App Workflow run can fail when an individual action encounters an error—an expected scenario in complex business orchestrations. Turbo360 provides comprehensive visibility into run history, enabling users to access detailed insights into failed executions.

• To further strengthen operational control, users can resubmit runs directly from the Run history, ensuring faster recovery and continuity.

• While resubmission is supported in the Azure portal, distinguishing resubmitted runs often lacks clarity. This is addressed through the application of tags that capture the relationship to the original parent run, providing clear traceability for runs resubmitted from either Turbo360 or the Azure portal.

Ignore runs

• A bulk of runs can be chosen to ignore and a tag gets associated with the particular runs along with the description.

• This ignore tag is visible only in Turbo360. It will not have any impact on the actual runs.

Trigger history

Users can view all the triggers in the Logic App Workflow along with details about the inputs and outputs of each trigger. If there are multiple triggers, the trigger history can be filtered by the trigger, as in Azure Portal.

The triggers can also be filtered based on the following statuses:

• Succeeded
• Running
• Failed
• Cancelled
• Waiting
• Skipped
• Suspended
• Paused
• Timed out
• Aborted

Action required

• The Action required helps users to focus on the failed Logic App Workflow runs.

• It also enables them to resubmit as well as ignore the failed runs.

Favorite runs

• Any of the Logic App Workflow runs used frequently can be marked as a favorite along with an optional description from both Run history as well as Action required tabs.

• Multiple runs can be marked as favorite at once. Users can also remove a particular run from favorites in the Favorite runs tab.

Inline task

• In the Logic App Workflow (Standard) section, users can create a really quick task to resubmit failed runs from the source logic app workflow that is being explored.

• The configuration created to run immediately can also be saved for future use in the Automated Tasks section.

Inline task to resubmit failed runs

• This feature allows users to quickly resubmit failed Workflow runs in the specified minutes (Minimum 1 and maximum 60 minutes).

The following illustration resubmits the failed Logic App Workflow runs in the last 10 minutes:

Task status can be viewed by navigating to the Automated Tasks section and switching to the Task History tab.

Automated task

• Consider an employee management scenario where the employee joining process in an organization is defined in a Logic App Workflow. When an employee joins an organization, a message with required employee details will be pushed into a Service Bus Queue by the HR application.

• A Logic App Workflow will be listening to the Service Bus Queue for messages.

• Whenever a message arrives in the Service Bus Queue, the Logic App Workflow will extract the message body of the Service Bus Message and post it to an Azure Function and store it in a Storage Table for future reference.

• The Azure Function will process the Employee details and assign them to the required departments in the organization.

Monitoring

Logic app Workflow state and runs count can be monitored using Turbo360.

State monitoring

The status of a Logic App Workflow can be monitored to track its current state and ensure it is running as expected.

1. Navigate to Logic App Workflow (Standard) -> Monitoring to configure the monitoring rules for Logic App Workflows (Standard).
2. Configure the threshold state.
3. Click Save.

Runs monitoring

The success and failure counts for a Logic App Workflow can be monitored to track execution outcomes and overall workflow health.

1. Navigate to Logic App Workflow (Standard) -> Monitoring to configure the monitoring rules for Logic App Workflows
2. Choose between Failed Runs Count and Succeeded Runs Count under Runs category and configure the threshold values.
3. Click Save to apply monitoring rules.

Monitoring recommendations

This section will discuss some of the common scenarios for Logic App Standard Workflow monitoring.

State

The image below demonstrates how to set up monitoring for alerts in case your workflow is disabled. You also have the option to enable the auto-correct feature.

Failures

Below is a visual guide on setting up monitoring for the number of failures allowed in your workflow before an alert is triggered. This threshold varies depending on the specific scenario of each workflow. While some errors are expected, alerts may be necessary for any errors in other cases.