Concurrency support for Service Bus built-in connector in Logic Apps Standard

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

Concurrency Support for Service Bus (Logic Apps Standard)


If you are interested to learn about other Service Bus enhancements, refer to these articles: Session support for Service Bus


Concurrency support in Logic Apps refers to the capability of running multiple runs concurrently for a workflow. Logic Apps provide built-in features to support concurrency, allowing you to design workflows that can execute multiple runs simultaneously. By default, Logic Apps would always try to run things in parallel to the maximum extent.


While this is great for most scenarios, in many cases, users want to have control on the concurrency. Concurrency control is important for several reasons, primarily related to managing resources, avoiding performance bottlenecks, not overwhelming backend systems and ensuring the efficient execution of workflows.


Concurrency control is available for triggers and actions. In this blog post, we’ll talk about how you can use concurrency control with Service Bus built-in connector in Logic Apps Standard. This feature is only available in code-view at the moment but the designer support is planned. [Until this feature is available in designer, if you make changes to code view we recommend to stay in the code view as you may loose these changes if you switch to designer view]


Key concepts

Before we go into the specifics, here are the three properties that are important for concurrency control

  • Concurrency control and Degree of Parallelism.  The concurrency control property is used to enable concurrency control. The degree of parallelism by default is set to 20 and can be set to any value from 1 to 100
  • Maximum batch size (Maximum message count) .  The Maximum batch size property is used to specify the number of messages to be processed in a single batch. The trigger reads the batch of messages as specified in this property
  • Split On . The split on property is used to enable the split on feature. When enabled, the items read by the trigger are split resulting in a separate run for each item. For example, if you have a batch size of 50 and split on enabled, then 50 runs would start and each run will process one item from that batch. If split on is disabled, only 1 run will process the 50 items.


Enabling concurrency control for Service Bus built-in or InApp connector

To enable concurrency control for Service Bus built-in connector (aka In App connector), you need to follow these steps. Please note that in future, these capabilities will be available in designer but for now you need to configure them through code view


Update workflow settings through code view

  • Create a new workflow and use Service Bus trigger or open your existing workflow with Service Bus trigger
  • Open the workflow in code view. Add the runtimeConfiguration section to the workflow definition. In the runtime configuration, add the concurrency and set the runs to the desired concurrency. Here is an example workflow:




  • The the split on settings are enabled by default and can be disabled if you do not want to split the batch and process all messages read in the batch in a single run.

Update host.json through code view

  • Until the feature becomes available through designer, you also need to update batch setting in host.json file.  To open host.json file, open your Standard Logic Apps, and select under Development Tools : Advanced Tools > Go > Debug console > CMD. In the file system open, site\wwwroot. You can update host.json using the command line or Edit button.
  • Update these two properties in host.json
  1. Currently this feature is behind a flag. To opt into this capability, you need to set the flag to true. In the host.json, set Runtime.ServiceProviders.FunctionTriggers.ConcurrencySupported to true
  2. Maximum messages batch size – The maxMessagesBatchSize property specifies the number of messages that are being read from the service bus queue or topic. The higher the number, the more messages will be read and processed in parallel. We recommend you choose this number based on the limits of your downstream systems. If you have used managed Service Bus connector in Logic Apps (consumption or ISE) before, you may find this field similar to Maximum message count property in the existing connector.

Note: As you configure batch size, we recommend to keep the number of concurrent runs larger than the overall batch size so that the messages read do not go in the waiting state and are always picked as soon as they are read. It is also possible in some cases for the trigger to reach upto twice the batch size.


Here is an example of host.json with concurrency enabled:




You are now ready to use the Service Bus trigger with concurrency enabled. In the next section, we'll attempt to answer questions regarding some advanced use cases or related configurations.



  •  What are other configurations available or important for the connector

The Service Bus connector leverages function bindings. You can refer to these settings and defaults for more information.


  • How does split on limits work with concurrency limits

When concurrency is enabled, split on limit is reduced to 100 items. This is true for all triggers including Service Bus trigger




Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.