Draft updates

Author: ecfan

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

@@ -187,11 +187,13 @@ For the exponential interval retry policy, the following table shows the general
 
 ## Manage the "run after" behavior
 
-When you add actions in the workflow designer, you implicitly declare the order to use for running those actions. After an action finishes running, that action is marked with a status such as **Succeeded**, **Failed**, **Skipped**, or **TimedOut**.
+When you add actions in the workflow designer, you implicitly declare the sequence for running those actions. After an action finishes running, that action is marked with a status such as **Succeeded**, **Failed**, **Skipped**, or **TimedOut**. In other words, the predecessor action must first finish with any of the permitted statuses before the successor action can run.
 
-By default, an action that you add in the designer only *runs after* the preceding action completes with **Succeeded** status. This "run after" behavior precisely specifies the run order for actions in a workflow. Basically, the predecessor action must first finish with any of the permitted statuses before the successor action can run.
+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. 
 
-You can change the default "run after" behavior for an action by [editing the action's **Run after** setting](#change-run-after-designer). In an action's underlying JSON definition, the `runAfter` 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.
+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 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.
 
 For example, to have an action run after action A succeeds and also after action B succeeds or fails when you're working on an action's JSON definition, set up the following `runAfter` property:
 
@@ -205,11 +207,7 @@ For example, to have an action run after action A succeeds and also after action
 }
 ```
 
-> [!NOTE]
->
-> The **Run after** setting is available only on actions that follow the first action in a workflow. 
-> The first action in a workflow must always run after the trigger, so the **Run after** setting 
-> doesn't apply and isn't available for the first action.
+### "Run after" behavior for error handling
 
 When an action throws an unhandled error or exception, the action is marked **Failed**, and any successor action is marked **Skipped**. If this behavior happens for an action that has parallel branches, the Azure Logic Apps engine follows the other branches to determine their completion statuses. For example, if a branch ends with a **Skipped** action, that branch's completion status is based on that skipped action's predecessor status. After the workflow run completes, the engine determines the entire run's status by evaluating all the branch statuses. If any branch ends in failure, the entire workflow run is marked **Failed**.
 
@@ -219,11 +217,6 @@ To make sure that an action can still run despite its predecessor's status, you
 
 For example, to run the Office 365 Outlook **Send an email** action after the Excel Online **Add a row into a table** predecessor action is marked **Failed**, rather than **Succeeded**, change the "run after" behavior using either the designer or code view editor.
 
-> [!NOTE]
->
-> In the designer, the "run after" setting doesn't apply to the action that immediately 
-> follows the trigger. The trigger must successfully run before the first action can run.
-
 <a name="change-run-after-designer"></a>
 
 ### Change "run after" behavior in the designer
@@ -236,7 +229,7 @@ For example, to run the Office 365 Outlook **Send an email** action after the Ex
 
    - **Standard**
 
-     1. Under **Workflows**, select **Workflows**.
+     1. On the resource sidebar, under **Workflows**, select **Workflows**.
 
      1. From the **Workflows** page, select your workflow.
 

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

@@ -12,15 +12,7 @@ ms.date: 06/21/2024
 
 [!INCLUDE [logic-apps-sku-consumption](~/reusable-content/ce-skilling/azure/includes/logic-apps-sku-consumption.md)]
 
-To run actions only after another group of actions succeed or fail, 
-group those actions inside a *scope*. This structure is useful when 
-you want to organize actions as a logical group, 
-evaluate that group's status, and perform actions 
-that are based on the scope's status. 
-After all the actions in a scope finish running, 
-the scope also gets its own status. For example, 
-you can use scopes when you want to implement 
-[exception and error handling](../logic-apps/logic-apps-exception-handling.md#scopes). 
+To run a group of actions only after another group of actions succeed or fail, you can nest the dependent actions inside a *scope*. This structure is useful when you want to organize actions as a logical group, evaluate that group's status, and perform actions that are based on the scope's status. After all the actions in a scope finish running, the scope also gets its own status. For example, you can use scopes when you want to implement [exception and error handling](../logic-apps/logic-apps-exception-handling.md#scopes). 
 
 To check a scope's status, you can use the same criteria 
 that you use to determine a logic apps' run status, 
@@ -43,17 +35,13 @@ If all the scoped actions succeed, the logic app sends a "Scope succeeded" messa
 
 ## Prerequisites
 
-To follow the example in this article, you need these items:
+* An Azure account and subscription. If you don't have a subscription, [sign up for a free Azure account](https://azure.microsoft.com/pricing/purchase-options/azure-account?WT.mc_id=A261C142F).
 
-* An Azure subscription. If you don't have a subscription, 
-[sign up for a free Azure account](https://azure.microsoft.com/free/). 
+* An email account from any email provider supported by Azure Logic Apps.
 
-* An email account from any email provider supported by Logic Apps. 
-This example uses Outlook.com. If you use a different provider, 
-the general flow stays the same, but your UI appears different.
+  This example uses Outlook.com. If you use a different provider, the general flow stays the same, but your UI appears different.
 
-* A Bing Maps key. To get this key, see 
-<a href="/bingmaps/getting-started/bing-maps-dev-center-help/getting-a-bing-maps-key" target="_blank">Get a Bing Maps key</a>.
+* A Bing Maps key. To get this key, see [Get a Bing Maps key](//bingmaps/getting-started/bing-maps-dev-center-help/getting-a-bing-maps-key).
 
 * Basic knowledge about [logic apps](../logic-apps/logic-apps-overview.md)
 
@@ -282,19 +270,36 @@ Your finished logic app now looks like this example:
 
 ![Finished logic app with scope](./media/logic-apps-control-flow-run-steps-group-scopes/scopes-overview.png)
 
-## Test your work
+## Test your workflow
 
-On the designer toolbar, select **Run** > **Run**. If all the scoped actions succeed, 
-you get a "Scope succeeded" message. If any scoped actions don't succeed, 
-you get a "Scope failed" message. 
+On the designer toolbar, select **Run** > **Run**. If all the scoped actions succeed, you get a **Scope succeeded** message. If any scoped actions don't succeed, you get a **Scope failed** message.
 
 <a name="scopes-json"></a>
 
 ## JSON definition
 
-If you're working in code view, you can define a scope structure 
-in your logic app's JSON definition instead. For example, 
-here is the JSON definition for trigger and actions in the previous logic app:
+If you're working in code view, you can define a scope in your workflow's JSON definition instead. The following sample shows the definition for a basic scope:
+
+```json
+{
+   "actions": {
+      "Scope": {
+         "type": "Scope",
+         "actions": {
+            "Http": {
+               "inputs": {
+                   "method": "GET",
+                   "uri": "https://www.bing.com"
+               },
+               "runAfter": {},
+               "type": "Http"
+            }
+         }
+      }
+   }
+}
+
+The following example shows the JSON definition for the trigger and actions in the preceding workflow:
 
 ``` json
 "triggers": {
@@ -305,10 +310,7 @@ here is the JSON definition for trigger and actions in the previous logic app:
        "interval": 1
     }
   }
-}
-```
-
-```json
+},
 "actions": {
   "If_scope_failed": {
     "type": "If",
@@ -446,7 +448,7 @@ here is the JSON definition for trigger and actions in the previous logic app:
 },
 ```
 
-## Next steps
+## Related content
 
 * [Run steps based on a condition (condition action)](../logic-apps/logic-apps-control-flow-conditional-statement.md)
 * [Run steps based on different values (switch action)](../logic-apps/logic-apps-control-flow-switch-statement.md)

articles/logic-apps/update-workflow-definition-language-schema.md

@@ -16,16 +16,14 @@ The [latest Workflow Definition Language schema version June-01-2016](https://sc
 
 * [Scopes](#scopes) let you group or nest actions as a collection of actions.
 * [Conditions and loops](#conditions-loops) are first-class actions.
-* More precise ordering for running actions with the `runAfter` property, replacing `dependsOn`
 
 To upgrade older workflow definitions to the current schema, see [Upgrade your schema](#upgrade-your-schema).
 
 <a name="scopes"></a>
 
 ## Scopes
 
-This schema includes scopes, which let you group actions together, or nest actions inside each other. For example, a condition can contain another condition. Learn more about [scope syntax](./logic-apps-control-flow-loops.md), 
-or review this basic scope example:
+This schema includes scopes, which let you group actions together, or nest actions inside each other. For example, a condition can contain another condition. Learn more about [scope syntax](logic-apps-control-flow-run-steps-group-scopes.md), or review this basic scope example:
 
 ```json
 {
@@ -77,22 +75,6 @@ In previous schema versions, conditions and loops were parameters associated wit
 }
 ```
 
-<a name="run-after"></a>
-
-## 'runAfter' property
-
-The `runAfter` property replaces `dependsOn`, providing more precision when you specify the run order for actions based on the status of previous actions. The `dependsOn` property indicated whether "the action ran and was successful", based on whether the previous action succeeded, failed, or as skipped - not the number of times you wanted to run the action. The `runAfter` property provides flexibility as an object that specifies all the action names after which the object runs. This property also defines an array of statuses that are acceptable as triggers. For example, if you want an action to run after action A succeeds and also after action B succeeds or fails, set up this `runAfter` property:
-
-```json
-{
-   // Other parts in action definition
-   "runAfter": {
-      "A": ["Succeeded"],
-      "B": ["Succeeded", "Failed"]
-    }
-}
-```
-
 ## Other changes
 
 ### Renamed 'manual' trigger to 'request' trigger