Ask Learn
Preview
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign inThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Logic Apps have a variety of connectors with triggers which enable to start a Logic App run based on a condition specific to each connector. The connector trigger is typically generating a trigger state query parameter which the Logic App will preserve and send to the next iteration of the trigger poll invocation. This way the file system connector can for instance save in its trigger state the watermark of the changed files it already picked up in previous iterations.
If the processing of some run fails, the first line of defense is to resubmit the run with the failures. In such Logic App run resubmission, the trigger is not called again and instead the first action in the logic app will receive the trigger output previously recorded. As the trigger is not called, the current trigger state is left unchanged and regular logic app trigger runs are undisturbed.
Now sometimes things go stray and you need to 'reset' a connector trigger to its original state so the logic app may reprocess data. While there is no built-in feature for that "nuclear option", it is possible to achieve this with the following workaround (modify the trigger definition to cause a trigger state reset):
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign in