This week we’ve been preparing for a Go Live in a project that integrates Dynamics 365 Field Services with an on-premises system . Part of this process was to run a series of migration script to get data from the on-prem system into D365.
Since D365 pushes the information into logic apps, I thought that the safest way to run that migration would be to simply disable the logic apps that would triggered by the process and the event would be “lost”. But to my surprise logic apps triggers are more powerful than that and remember the last event being processed. So when I turned on my logic apps after the migration, I was “rewarded” with thousands of triggers being fired…
To be honest this is quite powerful, because in cases where you had to take the logic app offline because of downstream system issues or updates, upstream systems can continue to work as expected. But how to avoid that in cases like mine – where bulk uploads (initial load or bulk updates) are not expected to flow downstream?
Reaching out to the product group, I found that the logic apps state is maintained in the engine, so once the logic app is enabled again, it will pick up the events from where it left. According to Kevin Lam:
The trigger 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. If you want to clear the trigger state change something in the trigger and save it before enabling it which should reset/clear any trigger state.
Any connector that needs a marker as to where it left off will utilize this.
So here is the workaround to fix this issue: change one of the trigger properties and save the logic app . This will reset the trigger and will avoid to trigger unwanted events. Remember that you must do that while the logic app is still in disabled mode, otherwise it will pick up the unwanted events as soon as you turn it on.
Seems like most of the connectors that uses a push notification will use this, so be aware of this detail. That might save you lost of unwanted traffic, a fair amount of dollars (depending of volume) and potential stress on downstream systems.
For D365, applying this workaround was quite simple and safe, since it has what is now an obsolete property – the check interval:
Now that the trigger is a push notification, this property is meaningless, so you can simply change it without worrying about the effect on the logic app. Remember to save the logic app after that and your state will be reset.
Ideally, the logic app enabling operation should ask if you want to keep state or not. Unfortunately this is not a feature that is available in the portal, so we have to resort to the workaround described above. Thinking about that, I’ve created a new user voice request, asking for this feature to be implemented. If you think it is important and want to have more control about the state of a logic app when you enable it, feel free to vote for it.
Summary
In summary:
- Certain Logic Apps triggers remembers the state while in disabled mode.
- To reset the state, you need to make a change in the trigger properties and save the logic app again while the logic app is still in disabled mode.
- After that you are safe to re-enable the logic app without receiving the unwanted triggers.
Leave a Reply