Logic App Service Bus Connector
You set up the logic app service bus connector by pairing your app workflow with a message queue or topic. The logic app service bus connector uses shared keys or managed identities to read and write messages. Most teams start by pasting a root shared key to get the workflow running fast. That broad key lets any workflow delete queues, read all topics, or drop live payloads. How the logic app service bus connector works Azure workflows need a clear path to send and pull messages from a namesp
Per-App VPN: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up the logic app service bus connector by pairing your app workflow with a message queue or topic. The logic app service bus connector uses shared keys or managed identities to read and write messages. Most teams start by pasting a root shared key to get the workflow running fast. That broad key lets any workflow delete queues, read all topics, or drop live payloads.
How the logic app service bus connector works
Azure workflows need a clear path to send and pull messages from a namespace. You build this link inside the workflow designer by picking a trigger or an action. Triggers watch a queue or topic subscription and start a run when new messages arrive. Actions push new messages out or settle open locks on items the app just read.
Under the hood, the connector needs a valid identity or secret key to log in. Teams pick between shared access signature keys and Azure managed identities for this step. A shared key lives inside an API link object in the resource group. If you use a managed identity, Azure checks role assignments on the namespace itself.
Role-based rules let you split send rights from listen rights for each workflow. You give the sender role to apps that only push events into a queue. You give the receiver role to apps that pull and process those waiting jobs. This separation keeps a broken reader app from flooding a queue with bad messages.
Choose between peek-lock and receive-and-delete modes
Message loss happens when an app crashes right after it pulls a queue item. The connector gives you two ways to read data so you can control this risk. Receive-and-delete mode wipes the message from the queue the moment the connector reads it. This mode runs fast, but any crash during the run loses that data forever.
Peek-lock mode hides the message from other readers while your workflow does its work. The connector holds a temporary lock on the item until the workflow finishes the job. When the steps succeed, the workflow sends a complete signal to remove the message. If the run fails or times out, the message goes back into the queue.
Repeated failures push the bad message into a dead-letter queue for a human to check. Engineers often log in to read those failed payloads and fix the broken workflow. Dead-letter items hold raw customer payloads, which creates a fresh risk during manual checks.
Per-App VPN: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native connector roles solve and leave open
Native roles and keys control which app or user can log in to a namespace. They do a great job of blocking outside traffic from your message queues. Once a user or app logs in, the native setup stops checking the payload content. It decides who can connect, not what individual commands or reads do in flight.
Support engineers often need to inspect queues or replay dead-letter items during an outage. If you give them receiver rights, their tools pull the full raw message body. Those bodies often carry emails, phone numbers, card numbers, or national IDs in plain text. Native queue permissions cannot mask those fields or ask for approval before a single read.
Shared API link objects also stay active until someone rotates the secret key by hand. When multiple workflows share one link object, audit logs blur which team ran which action. You need fine-grained controls that check every command and rewrite sensitive fields in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Should I use a managed identity or a shared key for the connector?
Use a managed identity whenever your workflow and namespace support it. Managed identities remove the need to store, share, or rotate secret keys by hand. You also get clean role rules that limit each app to one queue or topic.
Why do messages show up twice in my workflow runs?
Duplicate runs happen when a peek-lock timer runs out before your workflow finishes its steps. The queue thinks the app crashed and makes the message visible to other readers again. Keep your workflow steps short or renew the lock while long jobs run.
How can engineers check dead-letter messages without exposing raw customer data?
Native queue tools return the entire message body to anyone with read permissions. To protect sensitive fields, place a control point in front of engineer tools and scripts. Data masking rewrites matched fields like emails and card numbers in results before display.