Schema updates for Azure Logic Apps - June 1, 2016

Article
08/23/2022
4 minutes to read

Applies to: Azure Logic Apps (Consumption)

The updated schema and API version for Azure Logic Apps includes key improvements that make logic apps more reliable and easier to use:

Scopes let you group or nest actions as a collection of actions.
Conditions and loops are now first-class actions.
More precise ordering for running actions with the runAfter property, replacing dependsOn

To upgrade your logic apps from the August 1, 2015 preview schema to the June 1, 2016 schema, check out the upgrade section.

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, or review this basic scope example:

{
   "actions": {
      "Scope": {
         "type": "Scope",
         "actions": {                
            "Http": {
               "inputs": {
                   "method": "GET",
                   "uri": "https://www.bing.com"
               },
               "runAfter": {},
               "type": "Http"
            }
         }
      }
   }
}

Conditions and loops changes

In previous schema versions, conditions and loops were parameters associated with a single action. This schema lifts this limitation, so conditions and loops are now available as action types. Learn more about loops and scopes, conditions, or review this basic example that shows a condition action:

{
   "Condition - If trigger is some trigger": {
      "type": "If",
      "expression": "@equals(triggerBody(), '<trigger-name>')",
      "runAfter": {},
      "actions": {
         "Http_2": {
            "inputs": {
                "method": "GET",
                "uri": "https://www.bing.com"
            },
            "runAfter": {},
            "type": "Http"
         }
      },
      "else": 
      {
         "Condition - If trigger is another trigger": {}
      }  
   }
}

'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:

{
   // Other parts in action definition
   "runAfter": {
      "A": ["Succeeded"],
      "B": ["Succeeded", "Failed"]
    }
}

Upgrade your schema

To upgrade to the most recent schema, you need only take a few steps. The upgrade process includes running the upgrade script, saving as a new logic app, and if you want, possibly overwriting the previous logic app.

In the Azure portal, open your logic app.
Go to Overview. On the logic app toolbar, choose Update Schema.

The upgraded definition is returned, which you can copy and paste into a resource definition if necessary.

Important

Make sure you choose Save As so all the connection references remain valid in the upgraded logic app.
In the upgrade blade toolbar, choose Save As.
Enter the logic name and status. To deploy your upgraded logic app, choose Create.
Confirm that your upgraded logic app works as expected.

Note

If you are using a manual or request trigger, the callback URL changes in your new logic app. Test the new URL to make sure the end-to-end experience works. To preserve previous URLs, you can clone over your existing logic app.
Optional To overwrite your previous logic app with the new schema version, on the toolbar, choose Clone, next to Update Schema. This step is necessary only if you want to keep the same resource ID or request trigger URL of your logic app.

Upgrade tool notes

Mapping conditions

In the upgraded definition, the tool makes the best effort at grouping true and false branch actions together as a scope. Specifically, the designer pattern of @equals(actions('a').status, 'Skipped') appears as an else action. However, if the tool detects unrecognizable patterns, the tool might create separate conditions for both the true and the false branch. You can remap actions after upgrading, if necessary.

'foreach' loop with condition

In the new schema, you can use the filter action to replicate the pattern that uses a For each loop with one condition per item. However, the change automatically happens when you upgrade. The condition becomes a filter action that appears prior to the For each loop, returning only an array of items that match the condition, and passing that array to For each action. For an example, see Loops and scopes.

Resource tags

After you upgrade, resource tags are removed, so you must reset them for the upgraded workflow.

Other changes

Renamed 'manual' trigger to 'request' trigger

The manual trigger type was deprecated and renamed to request with type http. This change creates more consistency for the kind of pattern that the trigger is used to build.

New 'filter' action

To filter a large array down to a smaller set of items, the new filter type accepts an array and a condition, evaluates the condition for each item, and returns an array with items meeting the condition.

Restrictions for 'foreach' and 'until' actions

The foreach and until loop are restricted to a single action.

New 'trackedProperties' for actions

Actions can now have an additional property called trackedProperties, which is sibling to the runAfter and type properties. This object specifies certain action inputs or outputs that you want to include in the Azure Diagnostic telemetry, emitted as part of a workflow. For example:

{
   "Http": {
      "inputs": {
         "method": "GET",
         "uri": "https://www.bing.com"
      },
      "runAfter": {},
      "type": "Http",
      "trackedProperties": {
         "responseCode": "@action().outputs.statusCode",
         "uri": "@action().inputs.uri"
      }
   }
}