How do I ensure that one message from Azure Service Bus is processed at a time?

Question

How do I ensure that one message from Azure Service Bus is processed at a time?

Veli-Jussi Raitila 461

How can I make it absolutely sure that a workflow using the Azure Service Bus trigger does not, in any circumstance proceed to the next message in the queue until the previous one is either completed or dead-lettered?

This is how I tried to do it in a stateful workflow:

Use the In-app trigger (peek-lock)
Set splitOn": "@triggerOutputs()?['body']
Set "Degree of parallelism" to 1
Explicitly either complete or abandon the message if an error occurs during processing. I want the maximum delivery count to be reached until dead-lettering

The problem is the "Maximum waiting runs" setting which I cannot set to 0. Due to it, at least a second message is always picked up by the trigger for the waiting state. And as soon as the run for the first message completes e.g. results in abandoning the message, the run that was waiting proceeds processing the second.

How can I avoid this? I want to be in full control of when to proceed to the next message in the queue. In this case, I do not want the second message to start processing if I've abandoned the first one. Rather, I want the first message to be tried until it succeeds - or delivery count is reached (by abandoning enough times) and hence finally dead-lettered.

I'm using Azure Logic Apps Standard.

Locked Question. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

Christos Panagiotidis 3,461 Reputation points

2026-07-29T14:37:21.7433333+00:00

You configured a Standard stateful Logic App with a Service Bus peek-lock trigger and concurrency of one, but a second message becomes a waiting run. Concurrency limits workflow runs; the connector can still fetch and lock another message, so it does not guarantee that an abandoned first message is retried before later messages. For strict ordered processing, enable Service Bus sessions, assign the same SessionId to messages that must remain ordered, and use the session-aware trigger. Otherwise use an Azure Function or worker with prefetch set to zero, one concurrent receiver, peek-lock, and explicit complete or abandon calls. In the Logic App, perform transient retries inside the same run and abandon only after those attempts are exhausted. Once a message is abandoned, Service Bus may redeliver another message first. MaxDeliveryCount will eventually move repeated failures to the dead-letter queue. Therefore, non-session queues cannot provide the exact retry-before-next-message behavior you require.

Christos Panagiotidis 3,461 Reputation points

2026-07-29T14:37:21.7433333+00:00

You configured a Standard stateful Logic App with a Service Bus peek-lock trigger and concurrency of one, but a second message becomes a waiting run. Concurrency limits workflow runs; the connector can still fetch and lock another message, so it does not guarantee that an abandoned first message is retried before later messages. For strict ordered processing, enable Service Bus sessions, assign the same SessionId to messages that must remain ordered, and use the session-aware trigger. Otherwise use an Azure Function or worker with prefetch set to zero, one concurrent receiver, peek-lock, and explicit complete or abandon calls. In the Logic App, perform transient retries inside the same run and abandon only after those attempts are exhausted. Once a message is abandoned, Service Bus may redeliver another message first. MaxDeliveryCount will eventually move repeated failures to the dead-letter queue. Therefore, non-session queues cannot provide the exact retry-before-next-message behavior you require.