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.