Code-enforcement summary jobs sit on a Service Bus–backed work queue. How should Azure Functions consume that work?

Code-enforcement summary jobs waiting on a Service Bus–backed work queue should be consumed with an Azure Functions queue/Service Bus trigger bound to that entity. The trigger delivers messages to Function executions, manages lock cooperation with the Functions host, and scales out with queue depth—fitting municipal summary workers that should sleep when idle and surge when inspectors submit packets.

Using only a Cosmos DB change feed trigger unrelated to the summary queue fails by binding to the wrong signal: change feed is excellent for Cosmos mutations, not for draining a Service Bus work queue. Having each Function instance busy-wait in a while-true loop against the portal UI fails efficiency and reliability: it burns compute, does not use trigger scaling, and is not how Functions are meant to consume queues. Disabling triggers and requiring operators to paste message bodies into a desktop script fails automation and audit for production code-enforcement AI.

Exam caveat: bind to the correct Service Bus queue or subscription; mis-pointed connection settings look “healthy” while never receiving civic work. Configure poison message handling / max delivery count. Operational check: enqueue a test summary message, confirm the Function trigger fires and completes, verify message settles (complete) rather than endlessly abandoning, and watch Function scale behavior as queue depth rises.