From Form to Action: A Governed, Event-Driven AI Intake Pipeline with Azure Integration Services

A production-minded reference architecture using Azure Integration Services and Microsoft Foundry to turn document-heavy intake into governed, traceable work.

TL;DR: Calling a model is one step in AI-powered intake. Production readiness depends on everything around the model: authenticated entry, controlled model consumption, durable asynchronous processing, explicit failure handling, and one correlation ID carried from the gateway to the final event. This post walks through a permit-intake reference architecture on Azure Integration Services and a companion repository you can run offline, without an Azure subscription.

The Problem: Intake is where AI Prototypes Stall

Many teams have built an AI prototype that reads a scanned form, extracts the key fields, and returns clean, structured data. That prototype proves the model can do the job. Taking it to production raises a different set of questions:

• Who is allowed to call this, and how many times per minute?


• What happens when the model returns a 429 or the CRM is down for maintenance?


• Which team consumed those tokens?


• Can you show me everything that happened to application #00417?


• Who is notified when a record is created, and what breaks when we add another subscriber?

None of those questions is about the model, yet each one can decide whether the solution ships.

The underlying customer problem is broader than “How do we read a form?” It’s “How do we accept responsibility for a submission, process it reliably across slow or unavailable dependencies, and give applicants and operators a trustworthy status?” That framing moves the design from a single AI call to a governed system of connected services.

In this post, I use a fictional county’s building-permit intake as the running example. A resident submits a permit packet, and the county needs to validate it, extract the key fields, score it against intake policy, record it in a case system, and notify the right people, with a complete audit trail. The same shape appears in insurance first notice of loss, benefits enrollment, supplier onboarding, and claims intake. The repository keeps the domain in schemas and configuration: replace the schemas and labels, and keep the boundaries.

My thesis is simple: the hard part of production AI intake is connecting the services around the model reliably and under governance, not calling the model. The model is one component of the system. It isn’t the system.

Scope note: This is a production-minded reference architecture, not a production-ready template. The people, permit data, identifiers, and URLs in this post are synthetic, and the screenshots and trace rows show only that synthetic data. The repository favors demonstration clarity: public endpoints, simple SKUs, and simulated fallbacks.

Architecture at a Glance

Architecture diagram. A permit portal calls the Permits API in Azure API Management, which routes to a Logic App and then to a Service Bus queue with a dead-letter subqueue. An Azure Function extracts fields with Document Intelligence, gets an advisory compliance score from a Microsoft Foundry model through the API Management AI gateway, writes a record through a case-system adapter, and publishes a PermitCreated event to Event Grid, which fans out to a notification webhook and an analytics queue. Application Insights and Log Analytics join intake and processing with one correlation ID.

Figure 1. The governed, event-driven permit-intake flow. One correlation ID follows the permit from the gateway to the published event.

The design separates the acceptance path from the processing path. API Management owns the caller-facing contract and hands the work to a queue. Slow or failure-prone work happens after that hand-off. The flow reads left to right:

Portal → API Management → Logic App → Service Bus → Function → Case system → Event Grid → Subscribers
│
Document Intelligence + Foundry model (through the AI gateway)

The case-system box is deliberately not a CRM product. The repository’s crm.py is an adapter: an in-memory stub by default, or an HTTP call to whatever CRM_BASE points at. Swap in Dynamics 365 or your records system without changing the orchestration contract.

Let’s walk through the design decisions that matter most.

API Management is more than a Proxy

API Management is often introduced as a proxy. In this architecture, it’s the governance boundary, and it governs two surfaces.

Diagram of two API surfaces governed by one API Management instance: the Permits API with token validation, rate limiting, and a correlation ID, and the Azure OpenAI v1 API with content safety, token limits, token metrics, and managed identity authentication. The Function’s scoring call routes back through the gateway to a Foundry model.

Figure 2. One gateway governs both the business API and the model API.

Surface 1: The Permits API

The Entra-protected variant of the inbound policy (permits-api.policy.xml, abridged) authenticates, throttles, and stamps a correlation ID before any backend code runs:

<inbound>
<base />
<validate-azure-ad-token tenant-id=”{{tenant-id}}” failed-validation-httpcode=”401″>
<audiences><audience>api://ais-demo-permits</audience></audiences>
</validate-azure-ad-token>
<rate-limit-by-key calls=”60″ renewal-period=”60″
counter-key=”@(context.Subscription?.Key ?? context.Request.IpAddress)” />
<set-variable name=”correlationId”
value=”@(context.Request.Headers.GetValueOrDefault(“X-Correlation-Id”, Guid.NewGuid().ToString()))” />
<set-header name=”X-Correlation-Id” exists-action=”override”>
<value>@((string)context.Variables[“correlationId”])</value>
</set-header>
<set-backend-service backend-id=”permit-intake-logicapp” />
</inbound>

Three lines of intent are worth calling out:

• validate-azure-ad-token rejects missing, invalid, or expired Microsoft Entra tokens with a 401 at the edge, so unauthenticated requests are rejected before they reach the backend. It knows the Entra issuers and signing keys for your tenant, so there’s no OpenID configuration URL to maintain.


• rate-limit-by-key gives each consumer its own budget and returns 429 with Retry-After when it’s exceeded.


• The correlation ID is created here (or accepted from a trusted caller) and echoed back on the 202 Accepted response. That single value is how you’ll find this permit later.

The deployed demo authenticates callers with API Management subscription keys and applies the same rate limit and correlation ID. To adopt the Entra variant, register an app for the api://ais-demo-permits audience, register a backend for the Logic App trigger, and then swap the policy.

Surface 2: The Model API (The AI Gateway)

The Function doesn’t call the model endpoint directly. It calls the Azure OpenAI v1 API through API Management, where a second policy applies (abridged):

<inbound>
<base />
<llm-content-safety backend-id=”content-safety-backend” shield-prompt=”true”>
<categories output-type=”EightSeverityLevels”>
<category name=”Hate” threshold=”4″ />
<category name=”SelfHarm” threshold=”4″ />
<category name=”Sexual” threshold=”4″ />
<category name=”Violence” threshold=”4″ />
</categories>
</llm-content-safety>
<llm-token-limit counter-key=”@(context.Subscription?.Id ?? “anonymous”)”
tokens-per-minute=”20000″ token-quota=”2000000″ token-quota-period=”Monthly”
estimate-prompt-tokens=”false” />
<llm-emit-token-metric namespace=”ais-demo-ai-gateway”>
<dimension name=”Subscription” value=”@(context.Subscription?.Name ?? “unknown”)” />
<dimension name=”Department” value=”@(context.Request.Headers.GetValueOrDefault(“x-dept”, “unknown”))” />
</llm-emit-token-metric>
<set-header name=”api-key” exists-action=”delete” />
<authentication-managed-identity resource=”https://cognitiveservices.azure.com” />
<set-backend-service backend-id=”foundry-models-backend” />
</inbound>

In order, that policy:

• llm-content-safety sends the prompt to Azure AI Content Safety, with Prompt Shields for injection attempts, and returns 403 for prompts that exceed the configured thresholds, before they reach the model.


• llm-token-limit gives each consumer a tokens-per-minute budget (429) and a monthly token quota (403).


• llm-emit-token-metric publishes token usage to Application Insights with a department dimension for showback or chargeback.


• Managed identity authenticates the gateway to the model. The caller’s API Management subscription key is stripped, and local (key) auth is disabled on the Foundry resource, so the Function doesn’t hold a model key, which helps reduce the risk of key leakage.

The backend also has a circuit breaker that trips after three 429 or 5xx responses within a minute, pauses calls for a minute (or for the Retry-After period the model returns), and then resumes. The repository includes sample KQL for token monitoring and chargeback views.

The key point: conventional APIs and AI endpoints share one governed boundary. Your security team reviews one set of policies, and your platform team gets one place to see who is calling what.

Discovery: Azure API Center

API Management governs runtime traffic; Azure API Center is where people find the APIs. The repository links API Center to API Management, so the Permits APIs and the model API are cataloged with their definitions, lifecycle stage, and environment. Before a team builds another intake API or model proxy, they search the catalog and still call API Management at runtime. API Center isn’t on the request path.

Why the Flow is Asynchronous

The Permits API returns 202 Accepted with a correlation ID. It doesn’t wait for extraction, scoring, or the case system. That’s deliberate: document analysis, model calls, record writes, and notifications all have different latency and failure behavior, and holding the caller’s request open couples the caller to each of them.

Governance boundary: 202 means the platform durably accepted responsibility for the permit. It doesn’t mean extraction succeeded, a model approved anything, or a record was committed.

The repository enforces that literally. On the direct route (POST /permits), API Management writes to Service Bus and checks the answer before it says yes:

<send-request mode=”new” response-variable-name=”sbresponse” timeout=”20″ ignore-error=”true”>
<!– POST to https://{namespace}.servicebus.windows.net/permits-in/messages with managed identity –>
</send-request>
<choose>
<when condition=”@(context.Variables.GetValueOrDefault<IResponse>(“sbresponse”) == null
|| context.Variables.GetValueOrDefault<IResponse>(“sbresponse”).StatusCode != 201)”>
<return-response>
<set-status code=”503″ reason=”Service Unavailable” /> <!– plus Retry-After –>
</return-response>
</when>
</choose>
<!– only now: return 202 Accepted with X-Correlation-Id –>

If Service Bus doesn’t confirm the write (an error status, a timeout, or no connection), the caller gets 503 with Retry-After, not a 202 for work that wasn’t queued.

Logic Apps: Validate, Enrich, Route

The Logic App workflow checks the payload, attaches the correlation ID, and hands the message to Service Bus with its own managed identity. If required fields are missing, it returns 400 immediately. Here’s the send step:

“Send_to_Service_Bus”: {
“type”: “Http”,
“inputs”: {
“method”: “POST”,
“uri”: “https://@{parameters(‘serviceBusNamespace’)}.servicebus.windows.net/@{parameters(‘permitsQueue’)}/messages”,
“headers”: { “BrokerProperties”: “@{string(outputs(‘Broker_properties’))}” },
“body”: “@outputs(‘Enrich_message’)”,
“authentication”: { “type”: “ManagedServiceIdentity”, “audience”: “https://servicebus.azure.net” }
}
}

A preceding Broker_properties step sets MessageId to the parcel number and CorrelationId to the request’s correlation ID. Bicep loads this same workflow JSON when it deploys the Logic App, so each deployment applies the workflow definition from the repository.

Business analysts can read the run history in the Azure portal. If the county adds a new permit type or a routing rule, that change happens in the workflow, not in Python.

Design choice: The template deploys both routes. POST /permits-orchestrated goes through this Logic App. POST /permits uses a direct-enqueue policy that writes straight to Service Bus with the API Management managed identity; it’s the portal’s default and the route the trace below uses. Use the direct route when you don’t need low-code enrichment. Keep the Logic App when business users own the routing rules.

Service Bus: The Durable Hand-off

The permits-in queue is configured in Bicep with:

• maxDeliveryCount: 5, a message is delivered up to five times (the first attempt plus four retries) before it’s moved to the dead-letter subqueue.


• requiresDuplicateDetection: true with a 10-minute window, resubmitting the same messageId (the parcel number) doesn’t create a second message. See duplicate detection.


• deadLetteringOnMessageExpiration: true, expired messages are kept for inspection instead of being dropped.

Functions: One Orchestrator, Many Hosts

A Service Bus–triggered Function (Python 3.14 on Flex Consumption) reads the correlation ID from the message properties and runs a framework-agnostic orchestrator. A message without a permit type raises an error, so Service Bus retries it and then moves it to the dead-letter queue.

The orchestrator does four things in order: extract → score → record → publish.

def process_permit(permit: dict, correlation_id: str) -> ProcessResult:
extracted = document_intelligence.extract_fields(permit) # Document Intelligence
compliance = ai_gateway.score_compliance(extracted) # model via the API Management AI gateway
status = “IntakeReview” if compliance.score >= settings.compliance_threshold else “NeedsAttention”
permit_id = crm.create_permit_record(extracted, compliance, correlation_id, status)
event_grid.publish_permit_created(PermitEvent(permitId=permit_id,
complianceScore=compliance.score, correlationId=correlation_id))
…

Notice what the model doesn’t do: it doesn’t approve or deny anything. The score (0–100, against a rubric for completeness, consistency, and policy fit) only decides which human review state the permit lands in, IntakeReview or NeedsAttention, and that state is written to the case record. The call uses the Responses API on gpt-5.4-mini with structured output: the response must match a JSON schema (score, missing, flags), so downstream code receives a consistent, schema-validated shape. There’s no dated api-version to maintain:

client = OpenAI(
base_url=f”{apim_base}/openai/v1/”,
api_key=subscription_key,
default_headers={“api-key”: subscription_key, “x-dept”: “permitting”},
)
review = client.responses.parse(
model=”gpt-5.4-mini”, instructions=RUBRIC, input=fields_json,
text_format=Review, reasoning={“effort”: “low”}, store=False,
).output_parsed

The caller authenticates to API Management, not to the model: the api-key header carries the caller’s API Management subscription key (the template renames this API’s subscription-key header to api-key). The OpenAI client requires api_key and also sends it as a bearer token, but the gateway replaces that header with its own managed-identity token before calling the model. For production, swap the subscription key for a Microsoft Entra token (api_key=token_provider) and validate it at the gateway.

The same process_permit function is hosted by the Function, by a FastAPI service for the portal, and by the Python SDK walkthrough. That keeps the demo, the tests, and the deployed worker running the same code.

Event Grid: Fan-out without Coupling

After the CRM write, the Function publishes a PermitCreated CloudEvent. Two subscribers react independently: an analytics/audit queue and, when you supply a webhook URL, a resident notification webhook. Each subscription makes up to 30 delivery attempts over 24 hours. Adding a third subscriber, such as a GIS update or an inspector scheduling system, is a new subscription. It’s not a change to the permit flow.

Commands and Events are Different Things

Service Bus carries a command: “process this permit.” Event Grid carries a fact: “this permit was created,” published only after the record write succeeds. Keeping them separate makes retries, ownership, and subscriber behavior easier to reason about, a poison message can be retried and dead-lettered without a PermitCreated event going out for work that didn’t finish. Four rules follow:

• Message identity: a stable message ID (the parcel number) and the correlation ID as a message property. In the repository.


• Idempotency: a redelivered message must confirm earlier work, not create a duplicate record. Production work.


• Dead-letter ownership: someone watches the queue, reads the reason codes, and is authorized to replay. Operational.


• Status: callers need a status resource (accepted, processing, needs review, completed, failed) that doesn’t expose document contents. Production works the repository returns only the correlation ID.

How Failures are Handled and What Still Needs Work

A production-minded design makes failure behavior explicit before the happy path is trusted. The table separates what the repository does today from what still belongs on the production path:

Key Takeaways

1. Put the model behind the same gateway as your APIs. Content safety, token limits, usage metrics, and managed identity help turn model access into something you can govern and attribute.


2. Accept fast, process durably and mean it. Return 202 only after the queue confirms the message. That helps shield residents from downstream outages and gives operators a dead-letter queue to inspect instead of a lost request.


3. Keep AI advisory. Let the model route work to people. Don’t let it make the decision.


4. Create one correlation ID at the edge and carry it through each hop. It’s one of the simplest audit trails you can build.


5. Decouple what happens next. Event Grid lets new consumers subscribe without touching the intake flow.

What to do Next

1. Agree on the acceptance contract: exactly when 202 is returned and how callers check status.


2. Run the simulated portal and Python walkthroughs with one synthetic correlation ID.


3. Test the failure paths: queue unavailable, poison message, model unavailable, case system unavailable, and a trace gap.


4. Add idempotent record writes and an outbox for event publication.


5. Evaluate the advisory model separately from deterministic rules and human approval.


6. Complete an architecture, privacy, security, and Well-Architected review for your subscription before using real data.

Try It

• Repository: github.com/honestypugh2/ais-demo. Start with uv run ais-demo, no Azure subscription required.


• Adapt it: Change the schemas in src/ais_demo/schemas/permit.py, update USE_CASE_PROFILE and the samples in data/, and keep the topology.


• Go deeper: AI gateway capabilities in API Management · Service Bus dead-letter queues · Event-driven architecture style · Investigate transactions in Application Insights


• Related reading: Grounding Copilot Studio Agents with Azure AI Search and Foundry IQ

Models will change. The work around them is what moves intake from form to action: a governed front door, durable hand-offs, advisory scoring, and one correlation ID from submission to the final event. Clone the repository, run it offline, and adapt the schemas to your own intake process. Comments and questions are welcome below.

The sample code in this post and the companion repository is provided “as is” under the MIT license for demonstration purposes. It uses synthetic data only and isn’t intended for production use without additional security, reliability, and compliance review. Nothing in this post is legal, compliance, security, or deployment assurance, and it doesn’t represent a customer implementation. The county and applicant in this example are fictional. Check product availability, quotas, model access, and regional capabilities for your own subscription.