Do not auto-enable a LogicApp when deployed

How to deploy a LogicApp in a “Disabled” state

In the LogicApp ARM template, you can specify an optional “state” value


“resources”: [
{
// Start logic app resource definition
“properties”: {
“state”: “”,
“definition”: {},
“parameters”: {}
},

Continue reading “Do not auto-enable a LogicApp when deployed”

Logic Apps: ForEach and Terminate actions

Sometimes the simplest things become hard(er)

Normally it is not a problem terminating the Logic App run by using a Terminate action. But when you are iterating over some kind of list using a “ForEach” action, you are suddenly not allowed to use a “Terminate” action anymore. And Logic Apps does not provide any other way to stop a Logic App run.

Continue reading “Logic Apps: ForEach and Terminate actions”

Unable to select Azure subscription in Visual Studio Logic Apps deployment

From time to time (or what seems like VERY often), you might not get the option for selecting your Azure subscription/resourcegroup in Visual Studio Logic Apps Designer, when you open a Logic Apps project. This happes even when you are logged into an Azure account.

Continue reading “Unable to select Azure subscription in Visual Studio Logic Apps deployment”

Differentiate between Multiple triggers in a Logic App

In some cases, you might want to use more than one trigger in a Logic App. This can for instance be when you hook up to a D365 CE environment and use the “Common Data Service” Connector in Logic Apps to subscribe to changes

Here, it might make sense to have two triggers (one for the event “When_a_record_is_created” and one for the event “When_a_record_is_updated”) since both can often be handled similarly – at least if you are inserting or updating them in a SQL-server.
This is easy to do, since you in the following actions always can refer to “@triggerbody()” no matter which trigger has fired.

But what can you do, if you also would like to include the “When_a_record_is_deleted” trigger in the same Logic App. It potentially could be handled by the same Stored Procedure (for instance), but where the data from CDS is similar whether it is a “created” or an “updated” event, CE only sends the CE record GUID when it triggers the “deleted” event. This would probably make it less obvious to use the same handling for all 3 triggers.

You can actually query the logic app, for which trigger was in fact triggered. You can use the “@trigger()?[‘name’]” in a condition to compare it with trigger-names and behave differently depending on the trigger.

It can very well be argued, if it is a good idea to pack both INSERT, UPDATE and DELETE handling into one single Logic App, but in our case we are having a LOT of Logic Apps already, and it clutters the view the more Logic Apps are added. Also, the CE tables in question are small, seldom-updated tables.