Merge pull request #303067 from ecfan/retire

[Curation] Refactor and retire "Update schema" doc

Author: JamesJBarnett

articles/logic-apps/.openpublishing.redirection.logic-apps.json

@@ -1,5 +1,15 @@
 {
     "redirections": [
+        {
+            "source_path_from_root": "/articles/logic-apps/update-workflow-definition-language-schema.md",
+            "redirect_url": "/azure/logic-apps/workflow-definition-language-schema",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/logic-apps/logic-apps-workflow-definition-language.md",
+            "redirect_url": "/azure/logic-apps/workflow-definition-language-schema",
+            "redirect_document_id": true
+        },
         {
             "source_path_from_root": "/articles/connectors/connectors-create-api-informix.md",
             "redirect_url": "/azure/logic-apps/connectors/informix",
@@ -247,12 +257,12 @@
         },
         {
             "source_path_from_root": "/articles/logic-apps/update-consumption-workflow-schema.md",
-            "redirect_url": "/azure/logic-apps/update-workflow-definition-language-schema",
+            "redirect_url": "/azure/logic-apps/workflow-definition-language-schema",
             "redirect_document_id": false
         },
         {
             "source_path_from_root": "/articles/logic-apps/logic-apps-schema-2016-04-01.md",
-            "redirect_url": "/azure/logic-apps/update-workflow-definition-language-schema",
+            "redirect_url": "/azure/logic-apps/workflow-definition-language-schema",
             "redirect_document_id": false
         },
         {

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

@@ -187,21 +187,36 @@ 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**. By default, an action that you add in the designer runs only after the predecessor completes with **Succeeded** status. In an action's underlying JSON definition, the `runAfter` property specifies that the predecessor action that must first finish and the statuses permitted for that predecessor before the successor action can run.
+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 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 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.
+
+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:
+
+```json
+{
+   // Other parts in action definition
+   "runAfter": {
+      "Action A": ["Succeeded"],
+      "Action B": ["Succeeded", "Failed"]
+    }
+}
+```
+
+### "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**.
 
-![Conceptual diagram with examples that show how run statuses are evaluated.](./media/error-exception-handling/status-evaluation-for-parallel-branches.png)
+:::image type="content" source="media/error-exception-handling/status-evaluation-for-parallel-branches.png" alt-text="Conceptual diagram with examples that show how run statuses are evaluated." lightbox="media/error-exception-handling/status-evaluation-for-parallel-branches.png":::
 
 To make sure that an action can still run despite its predecessor's status, you can change an action's "run after" behavior to handle the predecessor's unsuccessful statuses. That way, the action runs when the predecessor's status is **Succeeded**, **Failed**, **Skipped**, **TimedOut**, or all these statuses.
 
 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
@@ -214,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)
 
@@ -146,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.
 
@@ -187,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.
@@ -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/logic-apps-limits-and-config.md

@@ -46,7 +46,7 @@ The following table lists the values that apply to a single workflow definition
 | `description` - Maximum length | 256 characters ||
 | `parameters` - Maximum number of parameters per workflow | - Consumption: 50 parameters <br><br>- Standard: 500 parameters ||
 | `outputs` - Maximum number of outputs | 10 outputs ||
-| `trackedProperties` - Maximum number of characters | 8,000 characters ||
+| `trackedProperties` - Maximum number of characters | 8,000 characters | Each action supports a JSON object named `trackedProperties` that you can use to specify certain action inputs or outputs to emit from your workflow and include in diagnostic telemetry. For more information, see [Monitor and collect diagnostic data for workflows](monitor-workflows-collect-diagnostic-data.md#tracked-properties). |
 
 <a name="run-duration-retention-limits"></a>
 

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

@@ -547,10 +547,15 @@ For more information plus examples for this trigger, see [Create and schedule re
 
 This trigger makes your logic app callable by creating an endpoint that can accept incoming requests. For this trigger, provide a JSON schema that describes and validates the payload or inputs that the trigger receives from the incoming request. The schema also makes trigger properties easier to reference from later actions in the workflow.
 
+> [!NOTE]
+>
+> 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).
 
 ```json
-"manual": {
+"Request": {
    "type": "Request",
    "kind": "Http",
    "inputs": {
@@ -599,7 +604,7 @@ To call this trigger, you must use the `listCallbackUrl` API, which is described
 This trigger specifies that an incoming request must use the HTTP POST method to call the trigger and includes a schema that validates input from the incoming request:
 
 ```json
-"manual": {
+"Request": {
    "type": "Request",
    "kind": "Http",
    "inputs": {

articles/logic-apps/media/update-workflow-definition-language-schema/update-schema.png

@@ -360,7 +360,15 @@ If you don't specify this custom tracking ID, Azure automatically generates this
 
 ### Tracked properties
 
-Actions have a **Tracked Properties** section where you can specify a custom property name and value by entering an expression or hardcoded value to track specific inputs or outputs, for example:
+Each action has a **Tracked Properties** section where you can specify the name and value for a custom property by entering an expression or hardcoded value to track specific inputs or outputs that you want to emit from your workflow and include in diagnostic telemetry.
+
+- Tracked properties aren't allowed on a trigger or action that has secure inputs, secure outputs, or both. They're also not allowed to reference another trigger or action that has secure inputs, secure outputs, or both.
+
+- Tracked properties can track only a single action's inputs and outputs, but you can use the `correlation` properties of events to correlate across actions in a workflow run.
+
+- 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 screenshots where you can find the **Tracked Properties** section on an action:
 
 ### [Consumption](#tab/consumption)
 
@@ -372,11 +380,24 @@ Actions have a **Tracked Properties** section where you can specify a custom pro
 
 ---
 
-Tracked properties can track only a single action's inputs and outputs, but you can use the `correlation` properties of events to correlate across actions in a workflow run.
-
-Tracked properties can only reference the parameters, inputs, and outputs for its own trigger or action.
-
-Tracked properties aren't allowed on a trigger or action that has secure inputs, secure outputs, or both. They're also not allowed to reference another trigger or action that has secure inputs, secure outputs, or both.
+In your workflow's underlying JSON definition, the JSON object is named `trackedProperties` and appears as a sibling to the action's `type` and `runAfter` properties, for example:
+
+``` json
+{
+   "Http": {
+      "inputs": {
+         "method": "GET",
+         "uri": "https://www.bing.com"
+      },
+      "runAfter": {},
+      "type": "Http",
+      "trackedProperties": {
+         "responseCode": "@action().outputs.statusCode",
+         "uri": "@action().inputs.uri"
+      }
+   }
+}
+```
 
 The following examples show where custom properties appear in your Log Analytics workspace:
 
@@ -402,7 +423,7 @@ The custom tracking ID appears in the **ClientTrackingId** column and tracked pr
 
 ---
 
-## Next steps
+## Related content
 
 * [Create monitoring and tracking queries](create-monitoring-tracking-queries.md)
 * [Monitor B2B messages with Azure Monitor Logs](monitor-b2b-messages-log-analytics.md)

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

@@ -467,8 +467,6 @@ items:
       href: create-automation-tasks-azure-resources.md
     - name: Move logic app resources
       href: move-logic-app-resources.md
-    - name: Update schema for Consumption workflows
-      href: update-workflow-definition-language-schema.md
   - name: Test
     items:
     - name: Create unit tests from Standard workflow definitions
@@ -563,7 +561,7 @@ items:
   - name: Resource Manager template reference
     href: /azure/templates/microsoft.logic/allversions
   - name: Workflow Definition Language schema
-    href: logic-apps-workflow-definition-language.md
+    href: workflow-definition-language-schema.md
     items:
       - name: Trigger and action types reference
         href: logic-apps-workflow-actions-triggers.md