Finish refactoring and retiring article

Author: ecfan

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 orignal 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 screnshots 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 defintion, 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)