Fix blocking issues

Author: ecfan

articles/logic-apps/error-exception-handling.md

@@ -191,7 +191,7 @@ When you add actions in the workflow designer, you implicitly declare the sequen
 
 By default, an action that you add in the designer runs only if the preceding action completes with **Succeeded** status. This *run after* behavior precisely specifies the run order for actions in a workflow. 
 
-In the designer, you can change the default "run after" behavior for an action by [editing the action's **Run after** setting](#change-run-after-designer). This setting is available only on subsequent actions that follow the first action in a workflow. The first action in a workflow always runs after the trigger sucessfully runs. So, the **Run after** setting isn't available and doesn't apply to the first action.
+In the designer, you can change the default "run after" behavior for an action by [editing the action's **Run after** setting](#change-run-after-designer). This setting is available only on subsequent actions that follow the first action in a workflow. The first action in a workflow always runs after the trigger successfully runs. So, the **Run after** setting isn't available and doesn't apply to the first action.
 
 In an action's underlying JSON definition, the **Run after** setting is the same as the `runAfter` property. This property specifies one or more predecessor actions that must first finish with the specific permitted statuses before the successor action can run. The `runAfter` property is a JSON object that provides flexibility by letting you specify all the predecessor actions that must finish before the successor action runs. This object also defines an array of acceptable statuses.
 

articles/logic-apps/logic-apps-control-flow-run-steps-group-scopes.md

@@ -134,13 +134,13 @@ so save your work often.
 
    1. In the **Subject** field, enter this text:
 
-     `Time to leave: Traffic more than 10 minutes`
+      `Time to leave: Traffic more than 10 minutes`
 
    1. In the **Body** field, enter this text with a trailing space: 
 
-     `Travel time:`
+      `Travel time:`
 
-     While your cursor appears in the **Body** field,
+      While your cursor appears in the **Body** field,
       the dynamic content list stays open so that you can
       select any parameters that are available at this point.
 
@@ -175,9 +175,9 @@ so save your work often.
    <!-- markdownlint-disable MD038 -->
    1. After the expression resolves, add this text with a leading space: ` minutes`
   
-       Your **Body** field now looks like this example:
+      Your **Body** field now looks like this example:
 
-       ![Finished "Body" field](./media/logic-apps-control-flow-run-steps-group-scopes/send-email-4.png)
+      ![Finished "Body" field](./media/logic-apps-control-flow-run-steps-group-scopes/send-email-4.png)
    <!-- markdownlint-enable MD038 -->
 
 1. Save your logic app.

articles/logic-apps/logic-apps-workflow-actions-triggers.md

@@ -549,7 +549,7 @@ This trigger makes your logic app callable by creating an endpoint that can acce
 
 > [!NOTE]
 >
-> The orignal name for the **Request** trigger was **manual**, which might still appear in some places. This 
+> The original name for the **Request** trigger was **manual**, which might still appear in some places. This 
 > name changed to create more consistency around the kind of workflow pattern that you use the trigger to build.
 
 To call this trigger, you must use the `listCallbackUrl` API, which is described in the [Workflow Service REST API](/rest/api/logic/workflows). To learn how to use this trigger as an HTTP endpoint, see [Call, trigger, or nest workflows with HTTP endpoints](../logic-apps/logic-apps-http-endpoint.md).

articles/logic-apps/monitor-workflows-collect-diagnostic-data.md

@@ -368,7 +368,7 @@ Each action has a **Tracked Properties** section where you can specify the name
 
 - Tracked properties can only reference the parameters, inputs, and outputs for its own trigger or action.
 
-Based on whether you have a Consumption or Standard logic app workflow, the following screnshots where you can find the **Tracked Properties** section on an action:
+Based on whether you have a Consumption or Standard logic app workflow, the following screenshots where you can find the **Tracked Properties** section on an action:
 
 ### [Consumption](#tab/consumption)