Azure Document Intelligence in Foundry Tools Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for AI + Machine Learning

1. Introduction

What this service is

Azure Document Intelligence in Foundry Tools refers to using Azure Document Intelligence (an Azure AI service for extracting text and structured data from documents) from within the Azure AI Foundry developer experience and tooling (often described as “Foundry tools”), such as projects, workflows, and app-building utilities.

One-paragraph simple explanation

If you have PDFs, scans, invoices, receipts, contracts, or forms and you want to turn them into usable data (fields, tables, key-value pairs), Azure Document Intelligence in Foundry Tools is a practical way to build and operate that extraction workflow in Azure—so your apps can reliably read documents and feed the results into downstream systems.

One-paragraph technical explanation

Azure Document Intelligence provides prebuilt document models (like invoice/receipt/ID) and custom extraction models for your organization’s document types. You send documents to the service via API (REST/SDK), and it returns structured outputs with text, detected layout elements, and extracted fields with confidence. When used “in Foundry Tools,” you typically integrate those calls into an end-to-end AI application workflow (for example, orchestrating extraction + validation + enrichment) managed in the Azure AI Foundry environment.

What problem it solves

Organizations often store critical information in unstructured documents. Manual data entry is slow, inconsistent, and expensive. Azure Document Intelligence in Foundry Tools solves this by: – Automating extraction of structured data from documents at scale – Reducing human effort while improving consistency and traceability – Enabling new AI + Machine Learning workflows such as retrieval, compliance checks, and downstream analytics

Naming note (important): Azure Document Intelligence is the current name for what many teams previously knew as Azure Form Recognizer. If you find older blogs or SDK references, treat them as legacy and verify in official docs before implementing.

2. What is Azure Document Intelligence in Foundry Tools?

Official purpose

The purpose of Azure Document Intelligence in Foundry Tools is to let teams build document-processing and data-extraction solutions using Azure Document Intelligence as the extraction engine, while using Azure AI Foundry tools to organize, orchestrate, and operationalize the workflow as part of broader AI + Machine Learning solutions.

Core capabilities

Extract text (OCR), tables, key-value pairs, and layout structure
Use prebuilt models for common document types (for example invoices and receipts)
Build custom models for organization-specific documents
Integrate extraction results into downstream systems (databases, ERPs, data lakes, search indexes, LLM pipelines)

Major components

Azure Document Intelligence resource (billable AI service endpoint in your Azure subscription)
Models:
Prebuilt models (document-type specific)
Custom models (trained or composed for your formats)
Layout/OCR capabilities for structure and text
Client access:
REST API
SDKs (for example Python, .NET, Java, JavaScript—verify the latest in official docs)
Foundry tools layer (Azure AI Foundry):
Project/workspace organization for AI apps
Tooling to connect to resources and orchestrate tasks (capabilities vary—verify in official docs for your tenant/region)

Service type

Managed AI service (PaaS) for document processing and information extraction.

Scope and availability model

Resource scope: provisioned inside an Azure subscription and resource group
Regional: you choose an Azure region when creating the Document Intelligence resource. Data processing and feature availability can vary by region—verify region support in official documentation.
Foundry scope: Azure AI Foundry typically organizes work in projects tied to your Azure environment. The Foundry tools themselves are not usually billed like a separate compute service, but they can connect to billable resources (Document Intelligence, storage, logging, etc.).

How it fits into the Azure ecosystem

Azure Document Intelligence is part of the broader Azure AI services portfolio and commonly integrates with: – Azure Storage (Blob Storage) for document ingestion and archiving – Azure Functions / Logic Apps for automation and event-driven workflows – Azure Key Vault for secrets management – Azure Monitor / Log Analytics for logging and metrics – Azure AI Foundry for building AI workflows and applications – Azure OpenAI for summarization, validation, or routing after extraction (when appropriate)

3. Why use Azure Document Intelligence in Foundry Tools?

Business reasons

Reduce manual data entry and document handling costs
Improve turnaround time for document-heavy processes (AP, onboarding, claims)
Increase consistency and auditability in extracted data
Accelerate automation initiatives without building OCR/extraction from scratch

Technical reasons

Prebuilt models handle common business documents with minimal setup
Custom models support specialized formats and organization-specific fields
Strong integration patterns across Azure (identity, networking, monitoring)
Production-grade APIs for scalable ingestion and processing

Operational reasons

Centralized resource management, diagnostics, and quota governance
Repeatable workflows (dev/test/prod) when combined with Foundry tools and standard Azure practices
Easier collaboration across data scientists, app developers, and platform teams

Security/compliance reasons

Enterprise controls via Azure (RBAC, Key Vault, private networking options)
Logging and auditing with Azure Monitor
Region selection for data residency (subject to service behavior—verify in official docs)

Scalability/performance reasons

Designed for high-throughput document processing patterns
Supports asynchronous processing patterns (implementation dependent—verify API patterns in docs)
Can be placed behind private endpoints for internal-only access (where supported)

When teams should choose it

Choose Azure Document Intelligence in Foundry Tools when: – You need repeatable extraction from PDFs/scans and want structured results – You want to build an AI + Machine Learning pipeline that starts with documents – You need enterprise governance: identity, network controls, monitoring, and cost tracking

When they should not choose it

Avoid or reconsider when: – You only need basic OCR for a few images and a simpler OCR tool suffices – You need fully offline/on-prem processing with no cloud calls (unless using hybrid patterns) – Your documents are extremely specialized and require heavy bespoke computer vision research (you may need a custom ML approach, possibly with Azure Machine Learning)

4. Where is Azure Document Intelligence in Foundry Tools used?

Industries

Finance and accounting (invoices, receipts, statements)
Insurance (claims forms, evidence documents)
Healthcare (intake forms; ensure strong compliance review)
Government (applications, permits)
Legal (contracts, exhibits—often paired with search and summarization)
Logistics and manufacturing (bills of lading, packing lists)
HR (onboarding documents)

Team types

App development teams integrating extraction into business apps
Data engineering teams building ingestion pipelines
Platform/security teams implementing governance and private networking
AI + Machine Learning teams combining extraction with classification/summarization

Workloads

Document ingestion pipelines (batch and event-driven)
Back-office automation (AP automation, onboarding)
Content intelligence for search and analytics
AI agent workflows that need reliable structured data from documents

Architectures

Event-driven: Blob upload → Event Grid → Function → Document Intelligence → Database
Batch: scheduled jobs processing a backlog of documents
Interactive: user uploads document in a web app and gets extracted fields back

Real-world deployment contexts

Multi-environment deployments (dev/test/prod) with separate resources
Multi-region strategies for latency or residency
Centralized extraction service used by multiple internal apps via API

Production vs dev/test usage

Dev/test: small sample sets, lower throughput, relaxed SLA, careful with PII
Production: private endpoints (where applicable), Key Vault, monitoring, retries, queue-based decoupling, cost controls, and documented runbooks

5. Top Use Cases and Scenarios

Below are realistic scenarios where Azure Document Intelligence in Foundry Tools is a strong fit.

1) Accounts Payable invoice extraction

Problem: Invoices arrive in many formats; manual entry is slow and error-prone.
Why this fits: Prebuilt invoice extraction + structured fields and tables.
Example: A finance team processes thousands of vendor invoices daily and automatically posts extracted totals and line items to an ERP after validation.

2) Receipt capture for expense reporting

Problem: Employees submit receipts as photos; inconsistent quality and formats.
Why this fits: Prebuilt receipt model + OCR and normalized fields.
Example: A mobile app uploads receipt images; extracted merchant/date/total are pre-filled in expense forms.

3) Customer onboarding packet processing

Problem: Multiple forms and IDs must be processed and checked.
Why this fits: Document extraction + ID parsing patterns (capabilities depend on region/SKU—verify).
Example: A bank extracts identity fields and address details, then routes exceptions to manual review.

4) Claims intake automation (insurance)

Problem: Claims arrive with mixed document types and attachments.
Why this fits: Combine classification + extraction, store structured outputs.
Example: A claims portal ingests PDFs, extracts claimant details, and triggers downstream workflows.

5) Contract metadata extraction for search

Problem: Contracts are PDFs; searching by parties/dates/terms is hard.
Why this fits: Layout + custom field extraction to build a metadata index.
Example: Legal ops extracts effective date, parties, renewal terms into a search index.

6) Shipping and logistics document processing

Problem: Bills of lading and packing lists vary by carrier and region.
Why this fits: Custom model for organization-specific formats; table extraction for line items.
Example: A logistics system extracts SKU quantities and shipment IDs and reconciles inventory.

7) Compliance evidence collection

Problem: Compliance teams need structured evidence from scanned documents.
Why this fits: Repeatable extraction pipeline + auditable logs/metrics.
Example: Automated extraction populates compliance records and flags missing fields.

8) Clinical form digitization (with strict controls)

Problem: Paper forms must become structured records; privacy is critical.
Why this fits: Managed service with Azure security primitives; private networking options.
Example: Intake forms are digitized; extracted data is stored in a secure database with access controls.

9) Real estate document intake

Problem: Leases and disclosures include tables and key fields.
Why this fits: Layout understanding + custom extraction for domain fields.
Example: A property management platform extracts rent, term, and deposit information into the system of record.

10) Manufacturing QA documentation

Problem: Certificates and test reports arrive as PDFs/scans.
Why this fits: Custom extraction + consistent structured output.
Example: Extract serial numbers, test dates, and pass/fail metrics for audit trails.

11) Student admissions document processing

Problem: Transcripts and forms need indexing.
Why this fits: OCR + custom model for specific transcript layouts.
Example: Extract student ID, GPA, and completion dates, then route to reviewers when confidence is low.

12) LLM/RAG pipeline “document-to-structure” stage

Problem: LLMs are unreliable at raw OCR and precise field extraction.
Why this fits: Deterministic extraction first, then LLM summarization/QA on structured results.
Example: Extract invoice tables and totals with Document Intelligence, then ask an LLM to explain anomalies.

6. Core Features

Feature availability can vary by region, API version, and SKU. For anything you plan to standardize across environments, verify in official docs.

6.1 Prebuilt document models

What it does: Extracts structured fields from common document types (for example invoices and receipts).
Why it matters: Minimal setup; fast time-to-value.
Practical benefit: You can build an MVP without collecting/training data.
Limitations/caveats: Field sets and accuracy depend on document quality and supported languages; not all regions support the same prebuilt models.

6.2 Layout extraction (document structure + OCR)

What it does: Detects text, lines, words, selection marks, tables, and layout geometry (bounding regions).
Why it matters: Layout is the foundation for downstream parsing and custom extraction.
Practical benefit: Enables table extraction and reliable citation of where data came from in the page.
Limitations/caveats: Scans with skew, blur, or low resolution reduce accuracy; handwriting support depends on service capabilities—verify.

6.3 Custom models for specialized documents

What it does: Lets you train or configure models to extract fields from your own document formats.
Why it matters: Real businesses rarely have one standardized template.
Practical benefit: Consistent extraction from vendor-specific forms, internal templates, and region-specific documents.
Limitations/caveats: Requires representative sample documents; model lifecycle management (retraining, drift monitoring) is your responsibility.

6.4 Confidence scores and traceability

What it does: Returns confidence values for extracted fields and often includes bounding regions for where the field was found.
Why it matters: You can route low-confidence results to human review.
Practical benefit: Enables “human-in-the-loop” QA and compliance.
Limitations/caveats: Confidence is not a guarantee of correctness; calibrate thresholds with real validation data.

6.5 Batch and asynchronous-friendly patterns

What it does: Supports processing patterns suitable for higher volume document ingestion (commonly via async pollers in SDKs).
Why it matters: Production workloads often require concurrency and backpressure controls.
Practical benefit: Better throughput and resilience compared to synchronous “single request” patterns.
Limitations/caveats: You must implement retries, idempotency, and queue-based decoupling for reliability.

6.6 Integration with Azure security primitives

What it does: Works with Azure resource management, keys, and (in many Azure AI services) Microsoft Entra ID / RBAC.
Why it matters: Helps meet enterprise security requirements.
Practical benefit: Central access control, auditing, and secret rotation.
Limitations/caveats: Exact auth methods vary by resource type and configuration—verify Entra ID support for your setup in official docs.

6.7 Networking controls (where supported)

What it does: Can be integrated with private networking patterns (for example private endpoints) to avoid public exposure.
Why it matters: Many document workloads include sensitive data.
Practical benefit: Reduces exfiltration risk and simplifies compliance arguments.
Limitations/caveats: Private networking patterns can complicate development/testing and require DNS planning.

6.8 Tooling for testing and iteration (Studio/Foundry tools)

What it does: Provides UI-based testing (for example Document Intelligence Studio) and workflow integration approaches through Foundry tools.
Why it matters: Faster iteration on extraction results without writing full apps first.
Practical benefit: Rapid evaluation of model fit, sample documents, and output structure.
Limitations/caveats: Tool capabilities evolve; treat UI as a helper, not a substitute for automated tests.

7. Architecture and How It Works

High-level architecture

At runtime, an application or workflow: 1. Receives a document (upload, email, portal submission, or batch input) 2. Stores it (optional but common) in Blob Storage for durability and audit 3. Calls Azure Document Intelligence to analyze it using a chosen model 4. Receives structured output (fields/tables/text + confidence) 5. Validates, enriches, and stores results in downstream systems 6. Monitors performance, errors, and costs via Azure Monitor

Request/data/control flow

Data flow: Document bytes or a document URL → Document Intelligence → structured extraction result
Control flow: Orchestrator (Function/Logic App/Foundry workflow) schedules work, retries on transient errors, and routes exceptions
Human-in-the-loop: Low-confidence results can be routed to a review UI or task queue

Integrations with related services

Common Azure integrations: – Azure Storage (Blob): document staging, immutability policies, lifecycle management – Azure Functions: event-driven processing – Azure Logic Apps: workflow automation and connectors – Azure Service Bus / Storage Queues: decouple ingestion from processing – Azure SQL / Cosmos DB: store extracted structured data – Azure AI Search: index extracted text and metadata for retrieval – Azure Key Vault: manage keys, secrets, and certificates – Azure Monitor + Log Analytics: operational visibility – Azure AI Foundry tools: project organization, workflow building, and collaboration (capabilities vary—verify)

Dependency services

Minimum dependencies are typically: – An Azure subscription – A Document Intelligence resource Optional but strongly recommended for production: – Key Vault – Storage – Logging (Log Analytics workspace) – Queueing (Service Bus/Storage queue) – Private networking (VNet + private endpoints), if required by security policy

Security/authentication model

Common approaches: – API key authentication: simple, but keys must be protected and rotated – Microsoft Entra ID / RBAC: preferred in enterprise where supported; reduces reliance on long-lived secrets (verify support for your resource type) – Managed identities: ideal for Functions and other Azure compute calling the service without embedded secrets (verify supported auth flows)

Networking model

Public endpoint by default (restrictable with network rules)
Private endpoint patterns may be available depending on service configuration—verify requirements, DNS, and supported scenarios
For document URLs: if you provide a URL to Document Intelligence, the service must be able to reach it; private documents typically require SAS URLs or an internal access pattern (verify supported private access patterns)

Monitoring/logging/governance considerations

Enable diagnostic settings to send logs/metrics to Log Analytics
Track:
Request counts and latency
Error rates by model
Throttling occurrences (quota/rate limits)
Cost per document type (page counts and model selection)
Use Azure Policy for:
Required tags (cost center, environment)
Allowed regions
Private endpoint enforcement (where applicable)

Simple architecture diagram (Mermaid)

flowchart LR
  U[User / App] -->|PDF/Image| A[Foundry Tools Workflow or App Logic]
  A -->|Analyze document| DI[Azure Document Intelligence]
  DI --> R[Structured Results: fields, tables, text + confidence]
  R --> S[App / Database / Search Index]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Ingestion
    UP[Upload Portal / Email Intake] --> BLOB[Azure Blob Storage]
    BLOB --> EG[Event Grid]
    EG --> Q[Queue: Service Bus or Storage Queue]
  end

  subgraph Processing
    Q --> FN[Azure Functions (Managed Identity)]
    FN -->|Call| DI[Azure Document Intelligence]
    DI --> OUT[Extraction Output]
    OUT --> DB[(Azure SQL / Cosmos DB)]
    OUT --> SEARCH[Azure AI Search]
  end

  subgraph Governance_and_Security
    KV[Azure Key Vault] --> FN
    MON[Azure Monitor + Log Analytics] <---> FN
    MON <---> DI
    POL[Azure Policy / Tags] --> DI
    VNET[VNet + Private Endpoints (where supported)] --- DI
    VNET --- BLOB
  end

  subgraph AI_App_Layer
    FOUND[Azure AI Foundry Tools (Project/Workflow)] --> FN
    FOUND --> SEARCH
  end

8. Prerequisites

Account/subscription/tenant requirements

An active Azure subscription
Access to create:
Resource groups
Azure Document Intelligence resources
(Optional) Storage account, Key Vault, Log Analytics workspace
Ability to use Azure AI Foundry in your tenant (if your organization restricts it, request access)

Permissions / IAM roles

Minimum recommended roles: – For resource creation: Contributor on the target resource group (or a custom role) – For operational management: Reader + specific monitoring roles – If using Entra ID auth: appropriate Azure AI service roles (often “Cognitive Services User” or similar—verify exact role names for Document Intelligence in official docs)

Billing requirements

A payment method on the subscription
Ensure your organization allows provisioning Azure AI services

CLI/SDK/tools needed

Azure CLI (optional but helpful): https://learn.microsoft.com/cli/azure/install-azure-cli
Python 3.9+ (recommended for the lab)
A modern browser for Azure Portal and Foundry tools

Region availability

Document Intelligence is regional; choose a supported region for your workloads.
Azure AI Foundry features can vary by region/tenant—verify.

Quotas/limits

Expect limits around: – Request rate (transactions per second/minute) – Maximum document size and page count – Concurrency limits per resource These vary by model and API version—verify in official docs and plan load testing.

Prerequisite services (recommended for production)

Azure Storage account (Blob)
Log Analytics workspace
Key Vault
Queueing (Service Bus/Storage queue)

9. Pricing / Cost

Do not rely on blog posts for pricing—use the official pricing page and calculator for current rates and regional differences.

Current pricing model (how it is typically billed)

Azure Document Intelligence is generally billed based on: – Number of pages processed (a primary cost driver) – Model type used (prebuilt vs layout vs custom can differ) – Training or build operations for custom models (if applicable) – Potential differences by: – Region – SKU/plan (for example free vs standard tiers where available) – API version and feature set

Official pricing page (verify current SKUs and units):
https://azure.microsoft.com/pricing/details/ai-document-intelligence/

Azure Pricing Calculator (estimate your region and volume):
https://azure.microsoft.com/pricing/calculator/

Pricing dimensions to track

Pages/month by document type (invoice, receipt, general docs, etc.)
Average pages per document
Percent of documents requiring reprocessing
Ratio of prebuilt vs custom model usage
Dev/test usage (often overlooked)
Outbound data transfer (if exporting results across regions)

Free tier (if applicable)

Azure services often offer limited free tiers for development. Availability and limits can change—verify in the official pricing page and in the Azure Portal SKU selection.

Cost drivers

Direct drivers: – Total pages analyzed – Higher-cost model selection (if applicable) – Re-analysis due to workflow errors (duplicate processing) – Custom model training/build cycles

Indirect/hidden drivers: – Storage costs for document retention (Blob) – Network egress (downloading documents/results across regions or to on-prem) – Logging costs (Log Analytics ingestion volume) – Human review tooling (if you build it) – Queueing and function execution (if used)

Network/data transfer implications

Keeping storage and Document Intelligence in the same region reduces latency and potential egress costs.
If documents must be processed in a different region due to service availability, you may incur data transfer costs and compliance complexity.

How to optimize cost

Use the least-expensive model that meets accuracy needs (for example, don’t use an expensive model when layout/OCR is sufficient).
Implement idempotency (avoid double-processing the same document).
Cache results and store structured outputs so you don’t re-run extraction.
Use confidence thresholds and human review only for low-confidence fields rather than reprocessing entire documents.
Control Log Analytics volume (sample logs, adjust retention, filter noisy logs).
Separate dev/test resources and enforce budgets.

Example low-cost starter estimate (conceptual)

A starter pilot might process: – A few hundred documents/month – 1–2 pages per document – Mostly prebuilt invoice or receipt extraction

To estimate: 1. Count total pages per month 2. Select your region and model type in the pricing page/calculator 3. Add storage costs for retaining originals and results 4. Add logging costs if diagnostics are enabled

(Exact numbers vary by region and SKU—use the official calculator.)

Example production cost considerations

For production (tens/hundreds of thousands of pages/month), consider: – Reserved capacity is not typically how Azure AI services are billed; it’s usually consumption-based—verify if any commitment plans exist for your enterprise agreement. – Use multiple resources if you need higher throughput (but manage governance). – Build dashboards: cost per vendor, per document type, per business unit.

10. Step-by-Step Hands-On Tutorial

This lab shows a realistic, beginner-friendly way to use Azure Document Intelligence in Foundry Tools: – Provision Document Intelligence in Azure – Validate extraction quickly in official tooling – Use Azure AI Foundry tools to run a small workflow step that calls Document Intelligence and returns structured fields

UI labels in Azure AI Foundry evolve. If a screen name differs, use the nearest equivalent and verify in official docs.

Objective

Extract key fields from an invoice PDF using Azure Document Intelligence, then run the extraction as a small callable step inside an Azure AI Foundry workflow/project context.

Lab Overview

You will: 1. Create an Azure Document Intelligence resource 2. Test extraction using Document Intelligence Studio (tool-based verification) 3. Create an Azure AI Foundry project and store the Document Intelligence endpoint/key securely (as secret variables or a connection) 4. Add a simple Python-based tool/step that calls the Document Intelligence SDK and prints extracted fields 5. Validate results 6. Clean up to avoid charges

Step 1: Create a resource group

Expected outcome: A resource group exists to contain all lab resources.

Option A (Azure Portal): 1. Go to https://portal.azure.com 2. Search Resource groups 3. Select Create 4. Choose: – Subscription – Resource group name (example: rg-di-foundry-lab) – Region (any)

Option B (Azure CLI):

az login
az account set --subscription "<YOUR_SUBSCRIPTION_ID>"
az group create --name rg-di-foundry-lab --location <YOUR_AZURE_REGION>

Step 2: Create an Azure Document Intelligence resource

Expected outcome: You have an endpoint URL and an API key for Document Intelligence.

Azure Portal steps: 1. In the portal, search for Document Intelligence (Azure AI Document Intelligence). 2. Select Create. 3. Select: – Subscription – Resource group: rg-di-foundry-lab – Region: choose the region that meets your needs – Pricing tier/SKU: choose the lowest tier that supports your test (verify free tier availability) 4. Create the resource. 5. After deployment: – Open the resource – Find Keys and Endpoint – Copy: – Endpoint – Key 1 (or Key 2)

Store these securely. For the lab you can temporarily keep them in a password manager.

Step 3: Quick verification using Document Intelligence Studio

Expected outcome: You confirm the service works before writing any code.

In your Document Intelligence resource, locate the link to Document Intelligence Studio (or navigate via official docs entry point).
Choose a prebuilt invoice (or similar prebuilt model).
Provide a sample invoice: – Use a known test document (many official quickstarts link to sample docs), or – Upload a non-sensitive sample PDF you own
Run analysis.

Verify you see extracted fields such as invoice number, vendor name, invoice date, total, and line items (exact field names depend on the model).

If Studio fails, do not proceed until you resolve: – wrong region/SKU – network restrictions – invalid key/endpoint

Step 4: Create an Azure AI Foundry project (Foundry tools)

Expected outcome: A Foundry project exists where you can run a workflow/tool that calls Document Intelligence.

Open Azure AI Foundry (start from Azure’s official Foundry landing page or your organization’s entry point). – Official documentation entry point (verify current URL): https://learn.microsoft.com/azure/ai-studio/ (Azure AI Studio/Foundry documentation paths may change)
Create a Project (or equivalent container).
Associate it with the same Azure subscription/resource group if prompted.

In the project, locate where to configure secrets or connections. Common patterns include: – Project “Connections” – Secret/environment variables – Linked Key Vault (recommended)

Step 5: Store Document Intelligence credentials securely for the project

Expected outcome: Your workflow can access the endpoint/key without hardcoding them.

Preferred approach (production): Azure Key Vault + managed identity (more secure).
Lab approach: project secret variables (if available).

Create two secret values in the Foundry project context: – DI_ENDPOINT = your Document Intelligence endpoint – DI_KEY = your Document Intelligence key

If the Foundry UI supports “connections” to Azure resources, use that approach instead and reference the connection in your tool step. If you cannot find a connection option, use secret variables.

Step 6: Create a small Python tool/step in Foundry tools to call Document Intelligence

Expected outcome: You run a step that calls Document Intelligence and returns extracted invoice fields.

In your Foundry project, create a workflow/flow where you can add a Python tool (naming varies: “tool,” “component,” “step,” or “node”).

Use the following Python code as the core logic.

SDK note: Azure SDK package names and classes can change across major versions. The safest approach is to start from the official quickstart for your chosen language and adapt it into this tool step. The code below demonstrates the pattern and should work with the current Document Intelligence SDK family, but verify imports and install commands in official docs.

Install dependencies in the environment used by the Foundry tool (if the UI provides a package/dependency setting). If you can run pip:

pip install azure-ai-documentintelligence

Python tool code (core extraction logic):

import os

def extract_invoice_fields(invoice_url: str) -> dict:
    """
    Calls Azure Document Intelligence prebuilt invoice model for a document URL.
    Returns a small dictionary of commonly used fields.
    """
    endpoint = os.environ["DI_ENDPOINT"]
    key = os.environ["DI_KEY"]

    # Verify the latest SDK usage in official docs if this import fails.
    from azure.ai.documentintelligence import DocumentIntelligenceClient
    from azure.core.credentials import AzureKeyCredential

    client = DocumentIntelligenceClient(endpoint=endpoint, credential=AzureKeyCredential(key))

    # Model ID for prebuilt invoice is commonly "prebuilt-invoice" in Document Intelligence.
    # Verify model IDs in official docs for your API version.
    poller = client.begin_analyze_document(
        model_id="prebuilt-invoice",
        analyze_request={"urlSource": invoice_url},
    )
    result = poller.result()

    # Extract a few common fields (field names vary; verify with your results)
    extracted = {
        "document_count": len(result.documents) if getattr(result, "documents", None) else 0,
        "fields": {}
    }

    if getattr(result, "documents", None):
        doc = result.documents[0]
        fields = getattr(doc, "fields", {}) or {}

        def get_field_value(name: str):
            f = fields.get(name)
            if not f:
                return None
            # SDKs often expose .value or typed properties; verify in your environment.
            return getattr(f, "value", None) or getattr(f, "content", None)

        extracted["fields"]["VendorName"] = get_field_value("VendorName")
        extracted["fields"]["InvoiceId"] = get_field_value("InvoiceId")
        extracted["fields"]["InvoiceDate"] = get_field_value("InvoiceDate")
        extracted["fields"]["InvoiceTotal"] = get_field_value("InvoiceTotal")

    return extracted

def main(invoice_url: str) -> dict:
    return extract_invoice_fields(invoice_url)

Provide an input URL to a sample invoice PDF. For a low-friction test, use a public sample document URL from official documentation or a trusted repository. In production, you typically: – Upload to Blob Storage – Generate a short-lived SAS URL – Analyze using that SAS URL

Run the flow/tool.

Step 7: Review output and add a basic validation rule

Expected outcome: You see extracted field values and can detect missing/low-quality results.

Confirm output contains some non-null fields.
Add a simple rule in your workflow: – If InvoiceTotal is missing → route to manual review queue – If vendor name is missing → attempt fallback (layout extraction + regex) or manual review

Even for prebuilt models, you should expect occasional misses due to scan quality or unusual templates.

Validation

Use this checklist:

Studio validation:
Document Intelligence Studio shows extracted invoice fields for the same sample document
Workflow validation:
Foundry tool run returns a dictionary with non-empty fields
Azure resource validation:
In the Azure Portal, your Document Intelligence resource shows recent activity (metrics/requests) after running the flow (exact metric names vary—verify)

Troubleshooting

Common issues and fixes:

Authentication error (401/403) – Verify DI_ENDPOINT is correct (no typos, correct region endpoint). – Verify DI_KEY is correct and not expired/rotated. – If using Entra ID auth, verify role assignments and token scope (advanced; verify in docs).
Model not found / invalid model ID – Confirm model ID in official docs for your API version. – Prebuilt model names can differ across API versions—verify.
Document URL not accessible – If using a URL, ensure it is publicly reachable or is a valid SAS URL. – Some private network setups block outbound access; confirm network rules.
Timeouts / throttling – Reduce concurrency in tests. – Implement retry with exponential backoff in production. – Verify quota limits and request rate caps.
Unexpected empty fields – Try a higher-quality PDF or image. – Confirm the document matches the model type (invoice vs receipt). – Validate results in Studio to isolate whether it’s a workflow/code issue or an extraction issue.

Cleanup

Expected outcome: You stop ongoing charges.

Delete the resource group:

az group delete --name rg-di-foundry-lab --yes --no-wait

In Azure AI Foundry: – Delete the project (if it was created only for this lab), or – Remove stored secrets/connections and any uploaded documents.
If you created: – Log Analytics workspace: confirm retention settings or delete it – Storage account: delete it to avoid ongoing storage costs

11. Best Practices

Architecture best practices

Decouple ingestion from extraction using queues. This prevents spikes from breaking your pipeline.
Store original documents in Blob Storage with lifecycle policies (hot → cool → archive).
Keep extraction outputs in a structured store (SQL/Cosmos DB) and optionally index text in Azure AI Search.
Use a multi-stage pipeline: 1) classify document type (if needed)
2) extract fields
3) validate
4) enrich/normalize
5) publish to downstream systems

IAM/security best practices

Prefer managed identities and Entra ID/RBAC where supported.
If using API keys:
Store keys in Key Vault
Rotate keys regularly
Restrict access via RBAC to Key Vault secrets
Use least privilege. Split roles by:
operators (monitoring)
developers (read-only to prod logs)
CI/CD (deploy permissions)

Cost best practices

Track pages processed by environment and workload.
Prevent duplicate processing with content hashes or blob metadata.
Use budgets and alerts in Azure Cost Management.
Turn on verbose logging only for debugging; keep normal operations lean.

Performance best practices

Use async processing patterns and concurrency controls.
Keep storage and Document Intelligence in the same region when possible.
Use batching and queues; avoid synchronous processing in user-facing request paths for large PDFs.

Reliability best practices

Implement retries with exponential backoff for transient errors.
Make processing idempotent (safe to retry without duplicating downstream effects).
Use dead-letter queues for documents that repeatedly fail.
Track “poison documents” and handle them separately.

Operations best practices

Enable diagnostics to Log Analytics; create dashboards for:
success rate by model
latency percentiles
throttling events
Maintain runbooks:
key rotation
quota increase requests
incident response steps

Governance/tagging/naming best practices

Tag resources: env, app, owner, costCenter, dataClassification
Use consistent naming:
di-<app>-<env>-<region>
Use Azure Policy for:
allowed regions
required tags
private endpoint enforcement (if applicable)

12. Security Considerations

Identity and access model

Use Azure RBAC wherever supported to avoid distributing API keys.
For API keys:
Treat keys as secrets
Avoid storing them in code, repos, or build logs
Prefer Key Vault references in runtime environments

Encryption

Azure services typically encrypt data at rest by default; verify specifics for Document Intelligence.
Ensure TLS is used in transit (HTTPS endpoints).
If storing documents in Blob Storage, consider:
customer-managed keys (CMK) for encryption (where required)
immutability policies for compliance evidence

Network exposure

Restrict public access where possible.
Use private endpoints and VNet integration patterns when supported and required.
Avoid exposing document analysis endpoints to the public internet without strict controls.

Secrets handling

Key Vault for:
Document Intelligence keys (if used)
Storage SAS signing keys (avoid long-lived SAS; prefer short-lived SAS)
Rotate keys and validate rotation does not break workflows.

Audit/logging

Enable diagnostic logs and maintain retention aligned to compliance needs.
Monitor for:
spikes in usage
repeated auth failures
unexpected regions or client IPs (where logged)

Compliance considerations

Documents often contain PII/PHI/financial data.
Ensure:
data classification policy
least-privilege access controls
region selection aligns with residency requirements
vendor risk and compliance review is completed
For regulated workloads, confirm whether additional controls are required (DLP, private networking, CMK, etc.).

Common security mistakes

Hardcoding API keys in application configuration files checked into source control
Using long-lived SAS URLs for document access
Not restricting who can read extracted results (often more sensitive than the original document)
Logging raw document content or full extraction payloads unnecessarily

Secure deployment recommendations

Private endpoint + Key Vault + managed identity (where supported) for production
Separate dev/test/prod subscriptions or at least resource groups with strong RBAC boundaries
Document retention policy: delete or archive documents based on compliance requirements

13. Limitations and Gotchas

The exact limits depend on model, region, and API version—verify in official docs before committing to an architecture.

Known limitations (typical)

Quality dependency: poor scans, skewed photos, and low resolution reduce extraction quality.
Template variance: extreme layout differences may require custom models or multiple models.
Language support varies (OCR accuracy and prebuilt model support differ by language).
URL accessibility: analyzing by URL requires the service to fetch the document from that URL (SAS/public reachability considerations).

Quotas

Rate limits and concurrency caps can cause throttling under load.
You may need multiple resources or a quota increase process—verify Azure support paths.

Regional constraints

Not every region supports every feature/model. Plan a region strategy early.

Pricing surprises

Large PDFs with many pages can multiply costs quickly.
Reprocessing documents due to workflow bugs doubles spend.
Diagnostic logging can increase operational cost (Log Analytics ingestion).

Compatibility issues

Legacy SDKs may reference “Form Recognizer” naming; ensure you’re using current packages and endpoints.
Output field names can change by model version; do not hardcode assumptions without tests.

Operational gotchas

Missing idempotency causes duplicates.
Lack of dead-letter handling leads to silent data loss.
Teams forget to delete dev resources (ongoing base costs like storage/logs remain).

Migration challenges

Migrating from legacy Form Recognizer endpoints/SDKs may require code changes.
Custom model management differs by API versions—plan time for validation and regression testing.

Vendor-specific nuances

Document Intelligence is best at extraction; it is not a full BPM/workflow solution by itself. Use Functions/Logic Apps/Foundry tools for orchestration.

14. Comparison with Alternatives

How to think about alternatives

If you need field-level structured extraction from documents, Document Intelligence is usually the closest match.
If you need only basic OCR, a simpler OCR service may be enough.
If you need end-to-end document workflow, pair extraction with orchestration services.
If you want open-source/offline, you trade off managed scaling and enterprise controls.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Azure Document Intelligence in Foundry Tools	Structured extraction at scale integrated into AI workflows	Prebuilt + custom extraction, Azure governance, integrates with Foundry tools	Consumption cost at scale, model/region variability, requires pipeline engineering	When documents are core inputs to AI + Machine Learning workflows and you want managed extraction
Azure AI Vision OCR	Basic OCR needs	Simpler OCR scenarios, can be cost-effective for pure text	Not the same as prebuilt invoice/receipt structured extraction	When you only need text, not structured fields/tables
Azure OpenAI (LLM-only extraction)	Flexible parsing for highly variable docs (after OCR)	Great for summarization and reasoning	Not deterministic; can hallucinate; needs OCR/structure first	Use after Document Intelligence for enrichment, not as the primary extractor
Azure Machine Learning (custom CV/NLP)	Highly specialized extraction beyond standard models	Full control, custom training	Higher build/ops complexity	When managed extraction can’t meet requirements and you have ML expertise
AWS Textract	Cross-cloud teams on AWS	Strong document extraction features	Different ecosystem; migration/integration overhead for Azure shops	When you’re already standardized on AWS
Google Document AI	Google Cloud ecosystems	Specialized processors and tooling	Different ecosystem; may not align with Azure governance	When you’re standardized on Google Cloud
Tesseract + custom pipelines (self-managed)	Offline/edge constraints	No per-page cloud fees; offline	Ops burden, scaling, accuracy challenges for complex docs	When cloud calls are not allowed and you accept higher engineering cost

15. Real-World Example

Enterprise example (regulated finance)

Problem: A finance enterprise processes multi-page invoices and supporting documents across multiple subsidiaries. They need consistent extraction, audit trails, and strict access controls.
Proposed architecture:
Documents uploaded to Blob Storage (immutable retention for audit)
Event Grid triggers ingestion → Service Bus queue
Azure Functions (managed identity) calls Azure Document Intelligence
Results stored in Azure SQL (structured fields) + Azure AI Search (full text)
Azure AI Foundry tools used to manage the AI app workflow, evaluation, and iteration for downstream enrichment (for example, anomaly detection and summaries using approved models)
Key Vault for secrets, Private Endpoints for network isolation, Log Analytics for monitoring
Why this service was chosen:
Strong structured extraction capability
Fits Azure governance and networking model
Supports scalable ingestion patterns
Expected outcomes:
Reduced manual entry
Measurable SLA improvements
Clear auditability (who processed what, when, and with what result confidence)

Startup/small-team example (SaaS expense automation)

Problem: A small SaaS team needs to extract receipt and invoice fields quickly without building OCR and parsers.
Proposed architecture:
Simple web app uploads to Blob Storage
App calls Document Intelligence directly for receipt/invoice extraction
Results stored in a managed DB
Minimal Foundry tools usage to standardize the AI workflow and keep experimentation organized as the product grows
Why this service was chosen:
Fast MVP via prebuilt models
Simple API integration
Clear scaling path to queues/functions later
Expected outcomes:
Faster product iteration
Lower operational burden compared to self-managed OCR
Predictable cost model based on pages processed

16. FAQ

Is “Azure Document Intelligence” the same as “Form Recognizer”?
Azure Document Intelligence is the current product naming. “Form Recognizer” is commonly used in older SDKs, samples, and blog posts. Verify the latest naming, endpoints, and SDK packages in official docs.
What does “in Foundry Tools” mean?
It generally means you’re using Document Intelligence as part of an AI application workflow built and managed using Azure AI Foundry tooling (projects, workflow orchestration tools, connections, and app-building utilities).
Do I need Azure AI Foundry to use Azure Document Intelligence?
No. Document Intelligence can be called from any application via API/SDK. Foundry tools help structure and operationalize the broader AI workflow.
Can I process documents stored in private Blob Storage?
Yes, commonly via short-lived SAS URLs or by uploading document bytes directly (depending on API/SDK patterns). Verify the recommended secure approach in official docs.
Should I send document bytes or use URLs?
For many production patterns, you store documents in Blob and use SAS URLs for analysis, or you send bytes directly from your service. URLs simplify some flows but require careful access control.
How do I choose between prebuilt and custom models?
Start with prebuilt models for common document types. Use custom models when your document formats are unique or when prebuilt output doesn’t match required fields.
How accurate is it?
Accuracy depends on document quality, template variability, language, and model selection. Always validate with representative samples and implement human review for low-confidence fields.
Can it extract tables and line items?
Many document models and layout extraction support table detection. For invoices, line items are a common requirement; validate with your invoice layouts.
What’s the best practice for human review?
Use confidence thresholds and route exceptions (not all documents) to a review queue. Store the bounding region so reviewers can quickly confirm fields.
Does it support Microsoft Entra ID authentication?
Many Azure AI services support Entra ID/RBAC; support can vary by resource type and configuration. Verify the current authentication options for Document Intelligence in official docs.
How do I monitor failures and performance?
Enable diagnostic settings, ship logs/metrics to Log Analytics, and build dashboards for throughput, error rate, latency, and throttling.
How do I avoid reprocessing the same document?
Store a hash of the document content (or blob ETag/version) and keep a processing ledger. Make processing idempotent.
Is it suitable for real-time user uploads?
For small documents, yes. For large PDFs or unpredictable loads, use async processing with a queue and notify the user when results are ready.
What are the main cost risks?
Unexpected high page counts, repeated processing, and large dev/test usage. Implement budgets and cost dashboards early.
Can I use it for RAG pipelines?
Yes. It’s often best to extract clean text/structure first (Document Intelligence), then index in search and use LLMs for summarization/QA.
Do I need to keep the original documents after extraction?
Depends on compliance and business requirements. Many teams keep originals for audit; others delete quickly for privacy. Decide and implement lifecycle policies.
How does Foundry help operationally?
Foundry tools can help standardize AI app development, manage resource connections, and keep workflows organized. Exact capabilities depend on your Foundry setup—verify in official docs.

17. Top Online Resources to Learn Azure Document Intelligence in Foundry Tools

Resource Type	Name	Why It Is Useful
Official documentation	Azure AI Document Intelligence docs: https://learn.microsoft.com/azure/ai-services/document-intelligence/	Primary source for concepts, models, limits, API versions, and how-to guides
Official pricing	Pricing page: https://azure.microsoft.com/pricing/details/ai-document-intelligence/	Current SKUs, billing units, and regional pricing notes
Pricing calculator	Azure Pricing Calculator: https://azure.microsoft.com/pricing/calculator/	Build estimates for your region, volume, and environment split
Official quickstarts	Document Intelligence quickstarts (see docs section “Quickstarts”)	Copy/paste working SDK patterns and authentication approaches
Official studio/tooling	Document Intelligence Studio (linked from docs/resource)	Rapidly test extraction on real documents and inspect fields/confidence
Foundry documentation	Azure AI Foundry / Azure AI Studio docs: https://learn.microsoft.com/azure/ai-studio/	How to use Foundry tools (projects/workflows/connections) that can incorporate Document Intelligence
Azure Architecture Center	Azure Architecture Center: https://learn.microsoft.com/azure/architecture/	Reference architectures for ingestion, event-driven processing, and governance patterns
SDK references	Azure SDK docs (language-specific) via https://learn.microsoft.com/azure/	Find current SDK packages/classes and supported authentication methods
Samples (official/trusted)	Azure samples repositories on GitHub (search “document intelligence” under https://github.com/Azure-Samples)	Practical examples for end-to-end pipelines (verify recency and API versions)
Community learning	Microsoft Learn training paths: https://learn.microsoft.com/training/	Structured learning modules that align with Azure services and fundamentals

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, cloud engineers, architects	Azure operations, automation, CI/CD, cloud governance around AI workloads	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate	DevOps fundamentals, SDLC tooling, cloud basics useful for AI workload delivery	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations teams	Cloud ops practices, monitoring, reliability patterns	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, platform engineers	Reliability engineering, observability, incident response for cloud services	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops + AI practitioners	AIOps concepts, monitoring automation, ML-assisted ops workflows	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	Cloud/DevOps training content (verify current offerings)	Beginners to intermediate	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training (verify current offerings)	DevOps engineers and students	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps guidance and services (verify current offerings)	Small teams needing practical help	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support/training resources (verify current offerings)	Operations teams	https://www.devopssupport.in/

20. Top Consulting Companies

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps/engineering services (verify exact portfolio)	Delivery support, automation, cloud operations around AI services	Implement event-driven doc ingestion; set up monitoring and cost controls	https://cotocus.com/
DevOpsSchool.com	Training + consulting (verify current consulting offerings)	Enablement, DevOps processes, platform practices	Build CI/CD for AI workflows; governance standards for AI resources	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify exact offerings)	Cloud operations, SRE practices, delivery pipelines	Observability rollout; incident response runbooks for document pipelines	https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

Azure fundamentals: subscriptions, resource groups, RBAC, networking basics
Security fundamentals: Key Vault, managed identities, least privilege
Data fundamentals: Blob Storage, queues, basic database concepts
Basic Python/.NET/JavaScript development for SDK usage
Monitoring basics: Azure Monitor, Log Analytics, alerts

What to learn after this service

Workflow orchestration at scale:
Azure Functions, Logic Apps, Service Bus
Search + retrieval:
Azure AI Search indexing patterns
AI enrichment:
Azure OpenAI for summarization, classification, and anomaly explanation (use responsibly)
MLOps and governance:
Model/version management (especially for custom models)
CI/CD and environment promotion patterns
Compliance engineering:
Data retention, DLP, access reviews, audit readiness

Job roles that use it

Cloud Engineer / Platform Engineer
Solutions Architect
Backend Developer / Integration Engineer
Data Engineer
SRE / Operations Engineer
AI Engineer (when documents are inputs to AI apps)

Certification path (if available)

Azure certifications change over time. Commonly relevant certifications include: – Azure Fundamentals (AZ-900) – Azure Administrator (AZ-104) – Azure Developer (AZ-204) – Azure Solutions Architect (AZ-305) – AI-focused Azure certifications (verify current offerings on Microsoft Learn)

Always confirm current certification names and objectives on Microsoft Learn: https://learn.microsoft.com/credentials/

Project ideas for practice

Invoice ingestion pipeline with queue + Function + Document Intelligence + SQL
Receipt extraction mobile backend with confidence-based review
Contract metadata extraction + Azure AI Search indexing
Multi-tenant extraction service with per-tenant keys, budgets, and tagging
RAG pipeline: extract → index → chat over documents with citations

22. Glossary

Azure Document Intelligence: Azure AI service that extracts structured information from documents (formerly associated with “Form Recognizer” naming).
Foundry Tools / Azure AI Foundry: Azure’s app-building and workflow tooling for AI solutions (capabilities vary; verify current docs).
Prebuilt model: A Microsoft-provided model optimized for common document types (for example invoices).
Custom model: A model configured/trained for your organization’s document layouts and fields.
Layout extraction: Detection of document structure—text, tables, selection marks, and geometry.
OCR: Optical Character Recognition—turning images/scans into machine-readable text.
Confidence score: A model-provided score indicating extraction certainty; used to drive human review.
Human-in-the-loop: A process where low-confidence results are reviewed/approved by a person.
SAS URL: Shared Access Signature URL granting time-limited access to Azure Storage resources.
RBAC: Role-Based Access Control in Azure for managing who can do what.
Managed identity: Azure-provided identity for services to authenticate without stored secrets.
Private endpoint: Network interface that brings an Azure service into a VNet for private access (availability depends on service).
Idempotency: Designing processing so retries do not cause duplicate downstream side effects.
Throttling: Rate limiting by the service when quotas are exceeded.
Diagnostics settings: Azure configuration to send logs/metrics to Log Analytics, Storage, or Event Hubs.

23. Summary

Azure Document Intelligence in Foundry Tools combines a practical document extraction engine (Azure Document Intelligence) with Azure’s AI application tooling ecosystem (Foundry tools) to help you build end-to-end document-to-data workflows.

It matters because most business processes still rely on PDFs, scans, and forms—and turning those into structured, validated data unlocks automation across finance, onboarding, claims, compliance, and analytics.

From an architecture standpoint, it fits best as a managed extraction component in a queue-based, observable pipeline integrated with Storage, Functions/Logic Apps, Key Vault, and monitoring. From a cost standpoint, your biggest levers are pages processed, model choice, and avoiding reprocessing. From a security standpoint, prioritize least privilege, secret hygiene (Key Vault), and private networking patterns where required.

Use it when you need reliable structured extraction and want an Azure-native path to production. Next step: build a small production-grade proof-of-concept with a queue, Function, Blob Storage, and dashboards—then validate accuracy and costs with real documents before scaling.

Category