LogicApps has two different kinds of triggers
The polling triggers are easy. Whenever the LogicApp is enabled and its trigger is scheduled, it will poll the source for new messages.
The subscribing triggers, like CDS(Dataverse)- and SQL-triggers, are a little harder.
Those triggers has state and remembers where it left off, so if you disable the logic app and re-enable it, then it will trigger for all of the items it has not yet seen since the last time the trigger fired.
This can give you massive problems, if you disabled the LogicApp for the purpose of mass-updating eg. SQL rows without triggering the LogicApp.
If you want to clear the trigger state change something in the trigger and save it before enabling it again. This should reset/clear any trigger state.
Any connector that needs a marker as to where it left off will utilize this.
How to deploy a LogicApp in a “Disabled” state
In the LogicApp ARM template, you can specify an optional “state” value
// Start logic app resource definition
Continue reading “Do not auto-enable a LogicApp when deployed”
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”
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”
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.