The Logic Apps team have been crazy busy this month. In case you missed the
latest webcast (link here)
this is what’s new and updated this month – and it’s a big list!!! 17 new features
in all! Plus, one new region. And 17 new connectors. Here’s a look at all of that:
Also note that there’s a little “T” button at the top right of the
Headers section – clicking this lets you switch back to the old JSON-based way of
The Request trigger gives you the option to specify a JSON schema
for the message being received. If you do this, then you get rich UI support for the
fields in your message i.e. they appear in the dynamic content boxes, so you can select
the fields you wish to use).
To get the JSON Schema, you usually went to jsonschema.net to generate it. Now, you
don’t have to – there’s a new option called “Use sample payload to generate schema”
on the Request trigger:
When you click this, you get a window where you can paste in a sample
When you do this and click Done, a new JSON schema is generated and
added to the Request trigger:
Saves some time, although remember that if you’re working in Visual
Studio, you’ll also want to save your JSON schema as a separate file, so it can be
Note: JSONSchema.net gives you more advanced
control over your schema, but for simple schemas this is a real time saver.
This is a fairly subtle addition. Previously, if you wanted to add
a new action to your logic app, you’d use the Add Action button that appears after
the last action in a scope (e.g. last action in your logic app, or last action in
a scope, or last action in a decision branch).
What wasn’t clear was how you add a new action in between two existing
The way I always did it was to create a new action at the bottom,
and then drag it up (did you know you can drag and drop actions?!) to the appropriate
place. But apparently, some people did it from the code-behind.
Now, the team have got you covered:
This is a new action, that converts an array to html or csv. It basically
allows you to pull out certain fields from an object array, and group those into an
HTML template or a CSV stream.
It’s not yet available in the region I tested in, so I can’t see
exactly how it works, but from the video you get two new actions, under Data Operations:
The demo showed using the Create HTML Table action:
You provide an array of objects, and it will return an HTML representation
of those objects.
From the demo, it looks like it gives you an HTML table:
This is a new feature that allows you to select the resource you
want to connect to from within the designer. It currently supports ServiceBus, Document,
and Blob storage. Previously, when you used the ServiceBus/DocDb/Storage connectors,
you would have to enter a connection string for the resource you were accessing.
Now, the designer gives you a list of resources (that you can access
via RBAC and which are in the same subscription), and you can pick the resource.
For example, the image below shows the use of the Service Bus GetMessage
action, and it gives me a list of the Service Bus Namespaces I have access to – I
can then click on one to select it:
Note: If you’re doing this from Visual
Studio, you’ll have to first create the resources you want to access *before* you
create your Logic App.
Some actions will return multipart/formdata or multipart/x-www-form-urlencoded data
(or sometimes you just have an HTTP POST to a Logic App from a web form!).
Previously you’d have to go out a function or API App to parse this
data. But now you can do this from within the Logic App, using several new expressions
that parse the data and make it available easily.
The Terminate action is used to stop your Logic App at a certain
point. Previously, the Terminate action could be used to indicate that your Logic
App run had failed or been cancelled:
But now there is an option for your Terminate action to show up as a successful run.
This option is exactly as it sounds: in the CallFunction action,
there is a new context option to open the function directly:
Selecting this opens the Functions App designer in a new blade, meaning
you can edit the function, save it, and return to the Logic App.
Note that this option will not work from Visual Studio, where you
would edit your function via a Visual Studio project, but if you’re using DevTool-less
environment, then this is a great timesaver.
Previously, you could only call a function from a Logic App if it
But now you can also use Functions that that use the HTTP binding:
The function template for an HTTP Binding trigger is identical to
that of a WebHook trigger; one of the main differences between the two is that you
can access query string parameters in an HTTP trigger, as shown in the sample you
get when you create an HTTP Binding function:
Finally! Rock on!!! I’ve been waiting for this for years, it feels.
For those of you who use Logic Apps regularly, and come from the
BizTalk world, you may have noticed that there was no variable support: there was
no direct way to store a value in a Logic App, and then change it, or access it later.
There were ways around this (e.g. using metadata in an Integration
Account, or storing your variable sin Blob Storage/Azure SQL) but these weren’t ideal.
As of today, we have variable support.
Initial variable support is limited.
What we get is:
Variables are currently global, but it sounds like scoped variables
(plus additional variable support) is coming.
There’s no documentation on how to initialize/increment variables
yet, but it’s coming
This may seem like a no-brainer if you’re new to Logic Apps, but
up until today, a Do-Until loop could only contain a single action. This mean that
most developers would call a function or a child Logic App here to get past the limitation.
But now a Do-Until loop is its own scope, so you can add multiple
actions into it:
Note: although the Do-Until supports multiple
actions, when I tested it (today) there was no “Add Action” option inside the loop,
instead I had to create new actions outside the loop, and drag them in.
Again, this is an incremental change, but also super useful. Previously,
you couldn’t put a foreach inside another foreach loop. Now you can.
Although this may seem surprising if you’re a sequential programmer,
the reason this was hard to do lies with the way that Logic Apps handles loops: by
default, the Logic Apps execution engine will parallelise each iteration of a foreach
loop (up to 20 executions in parallel).
For example, if you have a loop that will run 10 times, the execution
engine will spin up 10 separate instances of the actions in that loop, and they will
all execute in parallel, and then serialise back after they’ve all finished.
You can disable this behaviour using the sequential value
on the operationOptions property
for the foreach action (see the Logic
Apps workflow action and triggers guide).
I’m not yet sure what happens with parallelisation of nested foreach
loops – do they all execute in parallel? I’d assume so, but there must a limit on
the total number of parallel executions across all loops.
Previously, you could only support arrays/collections with up to
5000 items using foreach. Now you can use arrays/collections with up to 100,000 items.
Bear in mind that your array might be a JSON object array, with each object having
a lot of data.
This is great news for operations staff. For a while now, Logic Apps
has supported the idea of storing the previous versions of a Logic App every time
you save it. And you could swap the latest version with the previous version. But
now you can see a list of all the versions, and you can promote any of them to live.
This is great news for operations/support staff if they have to quickly
roll-back a production Logic App to a previous version.
Having said that, you should be using a fully automated deployment
process that automatically tests your logic Apps, in which case you’d never need this
You can access the list of versions from the Versions tab (under
Development Tools) when you view the properties for your Logic App:
Clicking on a version gives you the option to promote it:
This is an extension to work done to help you filter/search the run
history for a Logic App.
Up till now, you could only filter on the run status i.e. Failed,
But now, you’ll also be able to filter by Date/Time. However, this
change doesn’t yet seem to have made it to the region I was using so I can’t test
it. Here’s the (low quality) image from the webcast:
This is a monitoring view change: when you’re looking at the run
history for a Logic App, if your Logic App called a child Logic App, you couldn’t
previously jump into the child Logic App definition – you had to go find the run history
for that Logic App separately.
But now, it will jump into the monitoring view for that child Logic
Again, this doesn’t seem to be enabled in my region, so I can’t test
This is an addition to the B2B support for Operations Management
Suite (OMS). Now you can view information grouped by Partner, not just by protocol.
The Canada Azure datacentres are now available for hosting Logic
Apps. And then after that comes the UK!
17 new connectors in total:
They’re also working on some cool new stuff:
This is part of the Computer Vision API,
and will run OCR over an image you provide, and then return the text for that image.
Will give the option to update the value of the variable once the
Logic App has started (now, you can only initialize and then increment a variable).
You’ll also be able decrement a variable value, and also append your
variable to an array.
This is something you can do today (e.g. using the splitOn expression),
but you can only do it from code-view. Support for executing Logic Apps in parallel
will be surfaced up into the UI.
Functions will have SWAGGER support, which means that the Logic Apps
designer will be able to display function parameters in the dynamic code viewers,
and you’ll be able to use those function parameters in other actions.
This will let you create new arrays from existing arrays by selecting
items in the array that met certain conditions.
This lets you create a string from an array, by supplying a separator
token – each item in the array is added to the string, separated by the separator
At the moment, the Logic Apps execution engine handles retries for
you, but the information isn’t surfaced up to the monitoring view. This information
will be surfaced up, so you can see when retries occur plus the results, time they
This is super cool: if you have complex nested expressions, and you’re
debugging a run and want to see what the value of each of the expressions was, then
you’re stuck – you can only currently see the final value. But this new feature will
show you the value of each expression evaluation.
Instead of having to go to aka.ms/logicappsupdate, you’ll be able
to get to the list of updates directly from the Management Portal.
A long-awaited feature, you’ll be able to select a deployed Logic
App (from Visual Studio) and import that Logic App into a Logic Apps project in Visual
Studio. This will appear in the next version of the Logic Apps Tools for Visual Studio.
I’m not sure if you’re exporting from Azure, or importing into Visual Studio… 😊.
New connectors are on their way, including:
Whew! And that’s it.
Don’t forget the Global Integration Bootcamp, coming to a location near you… https://www.globalintegrationbootcamp.com/