This post was originally published here

And yet another Logic App Consumption Deployment issue, and more to come! Like the previous posts, while trying to deploy an existing Logic App Consumption thru Visual Studio 2019 in our development environment, I got the following error message:

Resource Microsoft.Logic/workflows ‘LA-NAME’ failed with message ‘{
“error”: {
    “code”: “CannotDisableTriggerConcurrency”,
    “message”: “The trigger ‘When_one_or_more_messages_arrive_in_a_topic_(peek-lock)’ of current version of workflow ‘LA-NAME’ has concurrency runtime configuration specified. Trigger concurrency runtime configuration cannot be removed once specified.”

This error happened because I tried to modify the Logic App Consumption Trigger from When one or more messages arrive in a topic (peek lock) to When one or more messages arrive in a topic (auto-complete).


The cause of the problem is simple to understand based on the error message. The trigger of the currently deployed version of the Logic App has Concurrency Control settings enabled. We can validate that by:

  • Right-click on the 3 dots on the Trigger and select the Settings option.
  • On the Settings windows of the trigger, we can validate that the Concurrency Control option is enabled and defined to have a Degree of Parallelism of 5.

Saying that, and despite the cause of the problem being easy to understand, the reason why this happens is not that clear. Still, it seems for some internal reason in the Logic App Runtime, after you set up the trigger to have Concurrency Control enabled, you cannot revert that configuration. You cannot do it while trying to deploy a new version of the Logic App thru Visual Studio, nor go directly to the Azure Portal and perform the same actions.

From Azure Portal or Visual Studio (it doesn’t matter the tool you use), if you try to:

  • Update the existing trigger to disable the Concurrency Control option and try to save it. It doesn’t work.
  • Delete the current trigger and add a new one. It doesn’t work, either.

Again, this seems to be a limitation that exists at the moment in the Logic App Consumption Runtime – not sure at this point if you will have the same limitation/issue in Logic App Standard.


Fixing this issue is not that simple. We can’t fix it, but we can apply two workarounds:

  • Workaround 1: if you don’t need to keep the run history of the existing Logic App.
  • Workaround 2: if you need to keep the run history of the existing Logic App.

Workaround 1

  • Delete from the Azure Portal the existing Logic App by selecting the Logic App and then, on the top menu, click the Delete option.
  • And then redeploy the Logic App.

This will solve the deployment problem, but again you will lose the run history.

Workaround 2

If you need to keep the run history, then unfortunately, the only option you have is to provide a different name to your Logic App, something like:

  • LA-NAME-V2

Make sure you change that, at least in the LogicApp.parameters.json file, but I suggest you change that also in the LogicApp.json file.

Just make sure you disable the “old” one – LA-NAME – and create a TAG specifying that it is deprecated.

After you validate everything is working fine and you don’t need the run history of the old one anymore, delete this Logic App to avoid confusion and to be simple to manage the overall solution.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira