August 4, 2016

Logic Apps Reaches General Availability



Logic Apps reached General Availability on Azure on 27 July 2016. This represents a fantastic effort by the Logic Apps product team, with many much-needed improvements to the user interface, tooling, performance and connectivity. Here is a summary of the improvements, and some information about migrating from existing schemas.

Improved User Interface

There are some very welcome changes in the user interface. These were rolled out as a new schema - 2016-06-01 - which becomes the first official schema version for Logic Apps. The main improvements are:

  • Logic Apps template
  • Designer UI improvements
  • Logic Apps execution details

Logic Apps Template

New logic apps can now be kick started by the use of templates. The first time a logic app is opened in the designer, the following screen lets users select a logic app template.

Selecting one of the templates shows a description of the template and selecting “use this template” allows users to setup or reuse any required connection, and create the logic app workflow.

Since the editor allows new actions to be moved and inserted between logic apps, using a template to setup the basic functionality and enriching it later with extra functionality is quite simple.

This functionality was inherited from Microsoft Flow - which probably explains why, at this stage, the existing templates are aimed at more straightforward, office-type integration. It is likely that more enterprise-type workflow templates will start to be shared in the future.

Designer UI improvements

Since the last preview refresh brought a huge number of improvements in the overall UI designer, this deployment did not include many high profile changes in the designer - although a good number of reported bugs have been cleared.

But two improvements are worth mentioning as they make the designer experience better:

Parallel actions

Parallel actions, which were previously displayed as a broken arrow in the editor, are now rendered properly:

This improves the visualization of a workflow, especially in complex scenarios where the parallel action is not that obvious to spot.

Designer-to-Code view improvements

One of the big issues in previous versions of the Designer UI was that it would replace an action card code with values derived from the user interface, ignoring changes made in the code view. Although this had been improved in the 2015-04-01 schema, the latest version is much more stable, with most issues fixed. There are some items that still create code, like the CRM templates which include mandatory fields as nulls even when a user removes them from the code view, but not many, and they are progressively being fixed.

Execution Details Improvements

The visualization of logic apps execution is another great user interface improvement. Where previously users could only see a list of actions, now a visual representation of the workflow indicates each step’s execution status -  succeeded, failed, skipped, input and output details - as well as the execution duration. This makes the execution path of a given instance much clearer, making it easier to troubleshoot errors and performance issues.

The original Run details, with more information about inputs and outputs, as well as the ability to copy the json representation of each action’s input and output, can still be accessed by clicking the Run Details button on the top left.

This is another functionality that surfaced first on Microsoft Flow and then migrated to Logic Apps, which shows how well both teams are working together.

Performance Improvements

User interface was not the only area enhanced. The overall execution performance of the workflows also improved by up to 50% according to the Product team, thanks to improvements to both the execution engine and individual connectors.

Development Support Tools

The main issues in this area raised by developers were:

  • Lack of Visual Studio integration
  • Lack of connection management tools
  • Lack of on-premises data connectivity

All three were, at least partially, addressed at the GA announcement.

Visual Studio Integration

Visual Studio integration unlocks the ability for version controlling and allows tighter integration with any ALM life-cycle/methodology used by development teams.

The VS integration is based on Azure Resource Management projects, which allows resources - like Logic Apps, connections, API Apps - to be defined, parameterised and deployed directly from Visual Studio or via power shell scripts. Developers can now install an extensibility package that allows the logic apps to be edited within Visual Studio, with the same user experience as the portal. The difference between them is that while the portal deploys the changes in the logic app when the save button is clicked, the local editor updates the resource template. Steps to install the add-in to enable local editing can be found here.

It is not a fully disconnected experience, however. The VS editor will still be connected to the web, since there is a lot of functionality, in particular related to managed APIs, that connects to online systems like CRM and SQL, and integration with Azure Functions and nested workflows, which requires internet connectivity.

API Connection Management

API connections are at the core of Logic Apps, allowing developers to define connections as resources that could then be reused by Logic Apps in the same resource group. But the lack of a user interface made this function one of the most complicated to manage during the early versions of Logic Apps. Just before Logic Apps going GA, API Connections received a much needed new management tool, which can be found by browsing the list of resource tools in Azure Portal, or simply by searching for API Connections in the Portal's search tab.

Within the API Connections tool users can see existing connections, review their names, status and the associated resource groups, edit details of a given connection and create or delete connections in a given subscription.

This new tool allows users to plan their connections in advance, naming them properly, as one of the issues with the Designer UI is that the APIs are named as <connectiontype> with an optional -<sequence> when more than one connection of the same type is created, which makes it hard to identify later. Also, display names are created based on generic properties for each individual connection, usually related to the credentials used for authorization.

Once a connection is created, users can edit both display name and authorization settings by selecting a particular API connection, and navigating to All Settings > Properties.

The authorization settings will be different for each account. Some, like Office 365 and CRM Online, require an authorization token, which will be acquired by the tool once the users authenticate with a valid account and authorize Logic Apps to access the application on its behalf. Others, like FTP and SQL Server, require a series of parameters that will create a connection string behind the scenes.

Connection Gateways

Another functionality that was really sought after by developers, on-premises connectivity, can now be achieved using Connection Gateways. Using the on-premises data gateway available initially for Power BI, the service works in a similar fashion to hybrid connections, exposing specific on-premises resources to Azure Services, so they can be accessed by Logic Apps, as shown in the diagram below:

Originally a Power BI feature, Connection Gateways, can now be used by Power Apps, Logic Apps and Microsoft Flow. At this stage, on-premises data gateway only allows Microsoft SQL Server connectivity, but other data sources and communication protocols are in progress. Another restriction is that the on-premises data gateway service can only be installed using a Work or School account. Personal accounts are not supported. Also, the account must first sign-up for Power BI. Microsoft is working currently to remove the Power BI sign-up requirement, but for the time been will only support Work or School accounts - similar to what happens on Microsoft Flow.

Also it is important to note that one on-premises data gateway service can only belong to a single logic app connection gateway. The claiming of an on-premises gateway happens during the configuration of the connection gateway in Azure.

More information on how to setup the on-premises data gateway service and the Logic Apps data gateway can be found here.

Migrating from Existing Schemas

Although the official version is now 2016-06-01, the last two schemas (2015-08-01-preview and 2016-04-01-preview) will still be supported for the next six months, according to the product team. Each schema has a specific upgrade path:

2015-08-01-preview Schema

To upgrade a logic app to the latest schema keeping the same addresses for any manual (http) triggers follow the steps below:

  • On the Logic Apps main blade select …More, then Update Schema
  • Save the Logic App as a new instance, using the Save As button. Notice that although the text acknowledges that the latest version is 2016-06-01, it will actually save the logic app using the 2016-04-01 schema.

  • Once the new Logic App has been deployed, open the Logic App, navigate to Code View, and change the version number from 2016-04-01-preview to 2016-06-01.
  • Confirm that the Logic App rendered and worked as expected in the latest schema.
  • After the logic app has been successfully tested in the 2016-06-01 schema, go to the main blade, Click in …More, then select Clone.
  • In Name, type the name of the original logic app and click Create. Notice that a warning that a Logic App with the same name exists and will be overwritten is displayed.

At this stage you can now delete the temporary Logic App use to move from 2015-08-01-preview to 2016-04-01-preview.

2016-04-01-preview Schema

Strictly speaking, moving from 2016-04-01-preview to 2016-06-01 schemas is just a matter of manually changing the schema name. But to confirm the logic app is rendered successfully, we suggest following the steps below:

  • In the original logic app (2016-04-01-preview), go to the main blade and select …More, then Clone. Notice that in this case Update Schema is grayed out.
  • Save as a temporary logic app by giving the logic app a unique name (e.g. originalname-20160601).

  • Once the new logic app has been deployed, open the logic app, navigate to Code View, and change the version number from 2016-04-01-preview to 2016-06-01.
  • Confirm that the logic app rendered and worked as expected in the latest schema.
  • After the logic app has been successfully tested in the 2016-06-01 schema, go to the main blade, Click in …More, then select Clone.
  • In Name, type the name of the original logic app and click Create. Notice that a warning that a Logic App with the same name exists and will be overwritten is displayed.


In less than two years since initially launched in preview, Logic Apps has developed from an interesting but limited technology to a serious tool in the integration arsenal, fully embedded in Microsoft's integration roadmap. And there is no sign of slowing down. Features like the Enterprise Integration Pack, BizTalk integration support, improvements to existing connectors and new connectors and triggers are already either in preview or in the pipeline.

Enterprise Integration Pack is probably one of the biggest ticket items to be completed. Enterprise Integration Pack provides support to traditional formats like XML, EDIFACT, X12, positioning the technology not only as a tool for modern integration, but also a good option for hybrid integration scenarios. This, together with the ability to execute BizTalk artefacts directly from a logic app, will allow interesting scenarios where integration reaches out from on-premises to the cloud and back seamlessly.

Want to learn more about Logic Apps?

Get in touch with our integration specialists to find out if it would fit your integration scenarios