Merge pull request #210286 from ecfan/patch-6

Azure Logic Apps: Clarify default retry policy

Author: prmerger-automator[bot]

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

@@ -22,29 +22,28 @@ The way that any integration architecture appropriately handles downtime or issu
 
 For the most basic exception and error handling, you can use the *retry policy* when supported on a trigger or action, such as the [HTTP action](logic-apps-workflow-actions-triggers.md#http-trigger). If the trigger or action's original request times out or fails, resulting in a 408, 429, or 5xx response, the retry policy specifies that the trigger or action resend the request per policy settings.
 
-### Retry policy types
-
-By default, the retry policy is set to the **Default** type.
-
-| Retry policy | Description |
-|--------------|-------------|
-| **Default** | This policy sends up to 4 retries at *exponentially increasing* intervals, which scale by 7.5 seconds but are capped between 5 and 45 seconds. For more information, review the [Default](#default) policy type. |
-| **None** | Don't resend the request. For more information, review the [None](#none) policy type. |
-| **Exponential Interval**  | This policy waits a random interval, which is selected from an exponentially growing range before sending the next request. For more information, review the [Exponential Interval](#exponential-interval) policy type. |
-| **Fixed Interval**  | This policy waits the specified interval before sending the next request. For more information, review the [Fixed Interval](#fixed-interval) policy type. |
-|||
-
 <a name="retry-policy-limits"></a>
 
 ### Retry policy limits
 
 For more information about retry policies, settings, limits, and other options, review [Retry policy limits](logic-apps-limits-and-config.md#retry-policy-limits).
 
+### Retry policy types
+
+Connector operations that support retry policies use the **Default** policy unless you select a different retry policy.
+
+| Retry policy | Description |
+|--------------|-------------|
+| **Default** | For most operations, the **Default** retry policy is an [exponential interval policy](#exponential-interval) that sends up to 4 retries at *exponentially increasing* intervals. These intervals scale by 7.5 seconds but are capped between 5 and 45 seconds. Several operations use a different **Default** retry policy, such as a [fixed interval policy](#fixed-interval). For more information, review the [Default retry policy type](#default). |
+| **None** | Don't resend the request. For more information, review [None - No retry policy](#none). |
+| **Exponential Interval** | This policy waits a random interval, which is selected from an exponentially growing range before sending the next request. For more information, review the [exponential interval policy type](#exponential-interval). |
+| **Fixed Interval** | This policy waits the specified interval before sending the next request. For more information, review the [fixed interval policy type](#fixed-interval). |
+
 ### Change retry policy type in the designer
 
 1. In the [Azure portal](https://portal.azure.com), open your logic app workflow in the designer.
 
-1. Based on your [logic app type](logic-apps-overview.md#resource-environment-differences), open the trigger or action's **Settings**.
+1. Based on whether you're working on a Consumption or Standard workflow, open the trigger or action's **Settings**.
 
    * **Consumption**: On the action shape, open the ellipses menu (**...**), and select **Settings**.
 
@@ -99,9 +98,9 @@ For more information about retry policies, settings, limits, and other options,
 
 #### Default retry policy
 
-If you don't specify a retry policy, the action uses the default policy. The default is actually an [exponential interval policy](#exponential-interval) that sends up to four retries at exponentially increasing intervals, which scales by 7.5 seconds. The interval is capped between 5 and 45 seconds.
+Connector operations that support retry policies use the **Default** policy unless you select a different retry policy. For most operations, the **Default** retry policy is an exponential interval policy that sends up to 4 retries at *exponentially increasing* intervals. These intervals scale by 7.5 seconds but are capped between 5 and 45 seconds. Several operations use a different **Default** retry policy, such as a fixed interval policy.
 
-Though not explicitly defined in your action or trigger, the following example shows how the default policy behaves in an example HTTP action:
+In your workflow definition, the trigger or action definition doesn't explicitly define the default policy, but the following example shows how the default retry policy behaves for the HTTP action:
 
 ```json
 "HTTP": {