--- schema_version: "1" id: 328249fcb79cffdb30b16bdfadf29f7c37814d56c2740943b12c2b1dbece0877 title: Data 360 Document AI collection: architect version: next locale: en-us portal_url: https://docs.salesforce.com/architect/next/en-us/fundamentals/guides/data360-document-ai.md canonical_url: https://staging.architect.salesforce.com/docs/architect/fundamentals/guide/data360-document-ai.html source_site: staging.architect.salesforce.com content_type: documentation content_hash: 5023f0d9798295e34831aa0aee054acbe4fec6df3dd4cfa193f3309478e85a16 products: - Fundamentals - Architect Site Content Repo updated_at: 2026-07-01T00:00:00Z --- ## Overview Enterprises handle a wide range of document types, including invoices, purchase orders, legal contracts, and technical manuals. Manual processing is slow, error-prone, and consumes an estimated 15–25% of employee time. Earlier automation approaches (for example, _Robotic Process Automation (RPA)_, _Optical Character Recognition (OCR)_, and workflow tools) reduced some of the burden, but produced rigid pipelines, high maintenance overhead, and siloed adoption across individual business teams. Documents carry rich structural context (for example, table hierarchies, spatial field relationships, and cross-referenced sections) that flat-text processing can't preserve. Stripping a document to plain text discards the business context that makes extraction accurate and useful, which degrades the quality of downstream analytics, _Artificial Intelligence (AI)_ inference, and process automation. To be effective, _Intelligent Document Processing (IDP)_ systems must classify documents by type, extract structured data accurately from variable layouts, and deliver that data in a governed, queryable form to downstream systems. IDPs must also handle document variability at scale without requiring per-template configuration for every new document format, and they must be centralized and accessible across business units. This challenge is compounded by the sheer volume of the key issue\: unstructured data accounts for approximately 80% of all enterprise data, and the majority accumulates in document form across file systems, Cloud storage, and content repositories that are outside the reach of _Customer Relationship Management (CRM)_ systems, AI agents, and analytics platforms. _Data 360 Document AI_ is the Salesforce document processing capability within _Data 360_, which is designed to address this gap. It extracts, classifies, and analyzes unstructured and semi-structured document content using _Large Language Models (LLMs)_, _Optical Character Recognition (OCR)_, _Natural Language Processing (NLP)_, and _Machine Learning (ML)_. The output is structured, governed, and queryable data that integrates into the _Data 360_ pipeline where _Agentforce_ agents, analytics tools, and automation workflows can access it via standard interfaces without requiring custom extraction or transformation layers. ## Why Does Document AI Matter? Enterprise data platforms process structured, tabular data. However, the majority of enterprise data arrives as documents and remains inaccessible to CRM, ERP, AI agents, and analytics pipelines until someone manually extracts it. This is an architectural gap, not a workflow problem. ### Limitations of Rules-Based Extraction Earlier approaches combined manual re-keying, rules-based OCR, and RPA scripts. These methods worked on a small scale, but they couldn't handle the volume, variety, and velocity of the types of documents that modern enterprises generate. Rules-based tools require explicit templates per layout variant. Any format change breaks extraction and requires a developer, a new template, and a deployment cycle. At scale, this produces fragile point solutions with no centralized governance, shared schema, and path to AI-readiness. Inconsistent extraction pipelines propagate downstream. In other words, analytics inherit data inconsistencies, AI models produce unreliable outputs, and regulated content like _Personal Health Information (PHI)_ and _Personally Identifiable Information (PII)_ lack systematic governance. ### AI-Native Document Processing LLMs extract fields without explicit templates. A single schema configuration governs extraction across layout variants, languages, and formats, which adapts to the document rather than requiring the document to conform to a fixed structure. This shifts document processing from a maintenance-heavy, siloed operation to a governed, centralized capability. ![Overview of Data 360 Document AI showing how batch and transactional pipelines turn unstructured documents into governed, queryable data](https://architect.salesforce.com/ns-assets/data360-doc-ai/data360-document-ai-overview.png) _Data 360 Document AI_ operationalizes document processing within the _Data 360_ platform via two pipelines. - The _Batch Pipeline_ routes extracted data through ingestion, identity resolution, calculated insights, activations, analytics, and Agentforce activation. - The _Transactional Processing Pipeline_ exposes a REST API that returns structured _JSON_ synchronously, which allows architects to route document-derived data to Salesforce _SObjects_, the _Data 360 Data Lake Object_/_Data Model Object (DLO/DMO)_ pipeline or external databases and warehouses without batch setup overhead. In both cases, extracted data enters a governed, schema-driven model rather than a fragmented set of point tools. ## Product In Scope [Data 360 Document AI](https://help.salesforce.com/s/articleView?id=data.c360_a_document_ai.htm&type=5) is the Salesforce native _Intelligent Document Processing (IDP)_ capability within the _Data 360_ platform. It converts unstructured and semi-structured document content into governed, queryable data that fully participates throughout the entire _Data 360_ lifecycle. ## What Is Data 360 Document AI? [Data 360 Document AI](https://help.salesforce.com/s/articleView?id=data.c360_a_document_ai.htm&type=5) is the Salesforce native _Intelligent Document Processing (IDP)_ capability within _Data 360_. It ingests unstructured and semi-structured documents, extracts structured data using a declarative schema configuration, and delivers that data to the _Data 360_ pipeline for harmonization, identity resolution, analytics, and Agentforce activation. Data 360 Document AI supports two processing modalities\: - **Bulk batch Processing\:** Processes large document sets that are defined in _Unstructured Data Model Objects (UDMOs)_ on an event-driven basis. - **Transactional Processing\:** Processes a single document via REST API and returns a structured _JSON_ payload synchronously. Architects can then route that payload to the _Data 360 DLO/DMO_ pipeline, Salesforce _SObjects_, or external databases and warehouses via _MuleSoft_, _Apex_ callouts, or _Einstein Trust Layer (ETL)_ pipelines. The target tier is an architectural decision driven by latency, governance, and data residency requirements. Document AI currently supports PDF files, image files (JPEG, PNG), and handwritten documents. ## Core Components _Data 360 Document AI_ assembles four processing technologies into a single governed pipeline. Each component handles a distinct stage of the document-to-data lifecycle\: - **Optical Character Recognition (OCR)\:** Converts scanned images, handwritten content, and image-based PDFs into machine-readable text before LLM processing. A minimum of 150 DPI is recommended for reliable extraction. - **Large Language Models (LLMs)\:** Route extraction through the _Einstein_ LLM gateway using the user-chosen model. The LLM receives OCR output alongside the _JSON_ schema configuration and returns a structured extraction payload. _Gemini_ and additional models are being planned for future implementation. - **Natural Language Processing (NLP)\:** Performs contextual understanding, entity recognition, date parsing, and semantic field extraction directly within the LLM via structured prompt engineering—the schema-defined prompt and OCR output serve as the sole inputs. All LLM interactions are routed through the ETL, which enforces zero data retention with model providers and masks _PII_ in text-based inputs before they reach the model. No separate NLP engine is employed. - **Multi-Modal Processing\:** Processes embedded images within PDFs as separate extraction inputs, which allows the LLM to extract data from diagrams, image-rendered tables, and mixed-content pages that OCR alone can't parse. In addition to the four processing technologies, _Document AI_ also handles\: - **Einstein Trust Layer\:** Routes all LLM interactions through the ETL, which enforces zero data retention with model providers and masks _PII_ before inputs reach the LLM with the exception of multimodal data (for example, attached documents that are processed via _Document AI_) where PII masking isn't currently supported and data is sent as-is to external models. The ETL only governs the LLM interaction path. Extracted data that's written to _Data Lake Objects (DLOs)_ is stored as-is; field-level masking at rest must be addressed through downstream data governance controls. - **File Size Limits\:** _Document AI_ processes files up to 10MB per request. LLM context length limits may further constrain processing for dense, multi-page documents within this boundary. ## Key Architectural Principles Enterprise architects that are deploying _Data 360 Document AI_ should apply these principles before committing to an implementation design. - **Select the pipeline before designing the schema.** The _batch_ and _transactional_ processing pipelines differ in ingestion model, schema binding, target flexibility, and latency. It's important to confirm which pipeline each use case requires before defining the schema as retrofitting adds avoidable rework. - **Design schemas at the document-type level.** Using a single, well-crafted schema per document type is more maintainable than using per-use-case configurations, and it's also the largest lever for extraction quality. Doing this correctly requires using a diverse set of documents—including edge cases—rather than designing from a single example. Use prompts iteratively at the _field_, _table_, and _schema_ levels to find gaps, and then test and refine them against multiple document samples before finalizing. Keep in mind that a schema that works well on one document may fall short on others, so breadth and iteration are essential. Schema flexibility—including removing columns that don't reliably extract across document types—is equally important. Holding on to fields that introduce noise or inconsistency undermines the overall extraction quality, so it's important to treat column removal as a first-class design decision. - **Choose the correct target tier per field group.** Fields that are driving CRM workflows or approvals write to _SObjects_. Fields that are enriching the unified profile or feeding analytics belong in the _DLO/DMO_ pipeline. Fields that are serving external systems belong in the _RDBMS_ tier. Keep in mind that a single schema may fan out to multiple tiers simultaneously. - **Enforce governance before processing regulated content.** Regulated data needs protection at every layer. That's why it's important to configure _PII_ masking, data classification tags, and _Attribute-Based Access Control (ABAC)_ after extracted data is stored in the output _Data Lake Objects (DLOs)._ This provides fine-tuned enforcement and context-aware access that's based on data classification, user role, and organizational context. _Governance_ is split across two paths\: the _ELT_ governs the LLM interaction, while the extracted data that's stored in DLOs must be governed separately—directly at the DLO and database levels—through _Data Space_ configurations, _Permission Sets_, and _ABAC_ policies. These controls must maintain consistency at the storage tier—not only the application layer—so access restrictions remain intact regardless of how data is accessed after ingestion. Keep in mind that gaps in any layer may expose regulated data downstream even when others are correctly configured. - **Design for failure modes before production.** Address null field handling, OCR quality thresholds, file size pre-validation, LLM context overflow, RDBMS write idempotency, and credit budget limits before the first production batch run. These aren't edge cases—they're predictable failure surfaces that must be explicitly handled in pipeline design, not discovered during runtime. - **Treat confidence scores as a first-class routing signal, not a diagnostic afterthought.** Extraction results carry field-level confidence values that are derived from the log probabilities (logprobs) of the underlying model output. For every extracted field, table, or column, the score reflects the model's token-level certainty of the extracted value. This makes confidence scores a statistically grounded signal that's reliable enough to serve as the primary gate for _Human-in-the-Loop (HITL)_ escalation thresholds. Use confidence scores to systematically identify low-quality extractions and initiate HITL checkpoints for low-confidence field values, ambiguous schema matches, or repeated pipeline failures instead of relying on heuristics or manual spot-checks. When automated recovery isn't possible, HITL-backed confidence scoring ensures that human judgment is applied exactly where it's needed. - **Design activation paths in parallel with schema design.** The value of _Document AI_ comes from being able to activate extracted data within Salesforce workflows and agents. It allows you to design Agentforce _Actions_, _Flows_, and _Calculated Insights_ alongside extraction schema design, not after. ## Architecture\: Data 360 Document AI Pipeline _Document AI_ operates within two pipelines\: - A _batch_ pipeline for high-volume, UDMO-backed processing - A _transactional_ _processing_ pipeline for real-time, API-driven extraction Both pipelines share the same schema configuration contract and ETL governance, but they differ in how documents enter the system and where extracted data lands. Let's take a closer look at each pipeline. ### Batch Processing Pipeline The _batch_ pipeline processes recurring document sets that are defined by a UDMO. It suits scheduled or event-driven use cases where documents are ingested from enterprise storage, then pass through document extraction, and are delivered to the _Data 360 DLO/DMO_ pipeline for harmonization, identity resolution, and activation. **Real-World Scenario** Each day, an insurance carrier receives thousands of medical claim documents from provider portals that are uploaded as PDFs into _Amazon S3_. The UDMO defines the in-scope document set and sends all claim PDFs to the `/claims/incoming/` bucket within a 24-hour window. ![Batch processing pipeline for an insurance carrier's medical claims, from ingestion through harmonization, identity resolution, and Agentforce activation](https://architect.salesforce.com/ns-assets/data360-doc-ai/data360-document-ai-batch-processing.png) #### Stage 1\: Ingest Documents are ingested into _Data 360_ from enterprise source systems without physical duplication. Supported sources include _Amazon S3_, _Google Cloud Storage_, Salesforce CRM file objects, _MuleSoft-orchestrated_ pipelines, and direct API uploads. In _AIforce_ deployments, documents are ingested via cloud storage connectors or the _Ingestion API_, which bypasses the CRM layer. The _Model Context Protocol (MCP)_ server exposes ingestion as a callable tool for external AI agents and LLM clients. Upon ingestion, raw documents are stored as _Unstructured Data Lake Objects (UDLOs)_, which map to the physical location and metadata of each document without moving or transforming the source file. **Example\:** Claims PDFs are ingested from _S3_ into _Data 360_ via the cloud storage connector. Each document is stored as a UDLO that points to the _S3_ object. No physical duplication occurs. #### Stage 2\: Extract _Document AI_ processes each UDLO against a schema configuration that defines which fields to extract along with their target data types. The UDMO defines which documents are in scope. The LLM (_GPT-4o_, _Gemini_, or _Claude_) reads each document and returns a structured extraction payload. **Example\:** _Document AI_ processes each UDLO against a claims schema that defines fields like\: ClaimID, PatientName, DiagnosisCode, BillingAmount, and ServiceDate. LLMs then read each PDF and return a structured extraction payload. #### Stage 3\: Persist Once the data is extracted, it persists into DLOs, which are the raw storage layer of _Data 360_. DLOs retain extracted fields without imposing business logic, which preserves an accurate physical representation for downstream transformation and traceability. The UDLO retains a reference to the source document to enable field-level lineage at any point in the pipeline. **Example\:** All extracted fields land in a _Claims DLO_, which preserves a raw, accurate representation of each claim with full lineage that can be traced back to the source PDF. #### Stage 4\: Harmonize DLO fields map to DMOs that align with the standard _Customer 360 Data Model_. This is the boundary where document-derived data transitions from raw, extracted fields to business-meaningful entities. The _Invoice DLO_ maps to an _Invoice DMO_, and fields like _CustomerID_ and _BillingAmount_ become join keys and match attributes within the unified data model. Harmonized document data participates in segmentation, _Calculated Insights_, and activation via the same interfaces that are used by CRM and transactional data. **Example\:** The _Claims DLO_ maps to a _Claims DMO_. The PatientID and PolicyNumber fields become join keys that link claim records to unified patient profiles. #### Stage 5\: Unify Harmonized DMO data participates in identity resolution. Extracted fields (for example, customer names, email addresses, or account numbers) serve as match keys for linking document records to _Unified Individuals (Golden Records)_, which closes the document-to-profile gap. **Example\:** Extraction fields (for example, PatientName, DateOfBirth, and PolicyNumber) serve as match keys for identity resolution, which links claim records to the correct _Unified Individual_. This occurs even if the same patient appears under slightly different name spellings across documents. #### Stage 6\: Derive Insights Architects define _Calculated Insights_, which are aggregated metrics that are computed across harmonized document data (for example, the total spend from various invoice line items, contract renewal risk scores, and claim severity indices). **Example\:** _Calculated Insights_ compute TotalClaimsPerPatient, AverageClaimAmount, and HighRiskClaimScore across harmonized claim data for Agentforce queries. #### Stage 7\: Act Harmonized, identity-resolved data is accessible to Agentforce Agents, _Tableau_, marketing platforms, and Salesforce _SObjects_. The target tier is an architectural decision that's driven by latency, governance, and data residency requirements. **Example\:** A _Claims Adjudication Agentforce Agent_ queries the _Data 360_ DMOs and CIs to find high-risk claims for priority review. _Tableau_ dashboards show claim volume and anomaly trends. Approved claim records circle back to the _Claims SObject_ to initiate payment workflows. In _AIforce_ architectures, activation routes directly to external systems via the _Query API_, _Pub/Sub API_, or Cloud data warehouse activation targets. Then, the MCP server finds harmonized document data and _Calculated Insights_ as callable tools for external AI agents. ### Transactional Processing Pipeline The _transactional processing_ pipeline handles single-document extraction at runtime without a UDMO or pre-ingested UDLO, which suits event-driven use cases (for example, a customer uploading a form, an agent receiving a PDF, or an external system initiating extraction within a transactional processing workflow). ETL governance applies to both pipelines identically. **Real-World Scenario** While applying for a loan, a bank customer uploads a PDF of their utility bill via the bank's mobile app. The event initiates extraction in real time, which means that no pre-ingested UDLO or UDMO is involved. ![Transactional processing pipeline showing real-time, synchronous REST API extraction for a loan applicant's utility bill](https://architect.salesforce.com/ns-assets/data360-doc-ai/data360-document-ai-ad-hoc-processing.png) #### Stage 1\: Define Schema Configuration Before invoking the API, architects must define and store a schema in _Data 360_ that specifies the fields, data types, and extraction instructions in _JSON Schema_ format. Each schema is assigned a unique _schema ID_. At runtime, the calling application references the schema ID to keep the extraction logic centralized in _Data 360_ rather than embedding it in application code. **Example\:** The bank's team has a pre-defined `ProofOfAddress` schema in _Data 360_, which specifies fields like `CustomerName`, `AddressLine1`, `City`, `PostCode`, and `DocumentDate`. This information is stored as a versioned configuration that can be referenced by a _schema ID_. #### Stage 2\: Submit Documents The calling application submits the document and schema ID in a single REST API request as a base64-encoded payload or file reference. No UDLO ingestion is required. _Document AI_ applies the document extraction and returns the structured output based on the provided schema. **Example\:** The mobile app submits the utility bill as a base64-encoded payload alongside the `ProofOfAddress` schema ID in a single REST API call. This process doesn't require a UDLO ingestion step. #### Stage 3\: Extract The LLM processes the OCR output against the schema and returns a structured JSON payload synchronously. Fields that aren't found in the document are returned as _null_. The caller owns the full JSON response and proceeds to routing. **Example\:** _Document AI_ applies OCR to the PDF and the LLM returns a structured JSON payload with extracted address fields. Fields that aren't found (for example, if the `PostCode` is missing from the bill) are returned as _null_. #### Stage 4\: Route to Target (Optional) Once extracted, the JSON payload can be routed to one or more target tiers depending on the use case\: - **Salesforce SObject\:** Maps directly to _SObject_ fields via _Apex_ or _Flow_ for CRM workflows and approvals. - **Data 360 DLO/DMO Pipeline\:** Routes into a DLO for harmonization, identity resolution, _Calculated Insights_, and Agentforce grounding. - **External RDBMS or Data Warehouse\:** Routes via _MuleSoft_, _Apex_ callout, _Platform Events_, or ETL for systems that are outside of Salesforce. - **Custom Integration\:** Returns structured JSON payloads to the calling application for storage in any external system or data store. - **Downstream Flow or Agent\:** Passes the structured JSON output directly to a downstream flow or agent without any persistence into a _SObject_. This is a common pattern for customers who use _Document AI_ as a real-time extraction step within a larger automation or agentic workflow. Keep in mind that a single schema may fan out to multiple tiers simultaneously, with different field groups routing to different targets from the same extraction point. **Example\:** A `ProofOfAddress` payload may fan out to three tiers at once (for example, `CustomerName` and `AddressLine1` write to the _Contact SObject_), which initiates an address verification _Flow_. Then, the full payload routes into a DLO for harmonization and risk scoring, and a copy routes to the bank's KYC system via _MuleSoft_ for regulatory compliance logging. #### Stage 5\: Act Once it's written, extracted data activates within the target system immediately. For _SObject_ targets, the triggers, flows, and approval processes are activated in the upserted record. For _DLO/DMO_ targets, data enters the _harmonization and identity resolution_ pipeline and Agentforce context. For external _RDBMS_ targets, data is available to downstream queries as soon as the write completes. **Example\:** The _address verification Flow_ immediately activates in the upserted _Contact_ record, which advances the loan application to the next stage. The Agentforce _loan officer Agent_ finds the verified address from the _Data 360_, and the KYC system records the document submission for audit purposes. ## When Should You Use Document AI? _Document AI_ is best suited for specific architectural conditions. Applying it outside of those conditions introduces unnecessary complexity and additional costs. As architects, it's important to evaluate this criteria before committing to _Document AI_ as the extraction mechanism. **Use Document AI when\:** - **Documents are the primary data source.** The required information exists only in document form and is unavailable from a structured API or database (for example, scanned contracts, lab reports, intake forms, or insurance claims). - **Document layouts vary across sources.** The same document type arrives from multiple vendors, partners, or regions with different field positions and formats. Schema-driven LLM extraction adapts without per-layout maintenance. - **Extracted data must feed Data 360 or Agentforce.** Extraction must participate in identity resolution, _Calculated Insights_, or Agentforce grounding. _Document AI_ is delivered directly into the _DLO/DMO_ pipeline without a separate ETL layer. - **Volume justifies governed automation.** Document volume exceeds what manual processing can handle without measurable labor costs or data quality risks. - **Documents contain regulated content.** _PHI_, _PII_, or financial data must route through a zero-data-retention, PII-masking layer before reaching an LLM. The ETL satisfies this natively. Customers who require no extracted content to be persisted at any point should also consider the _transactional API_ flow, which returns structured output directly to the calling application without writing to any _SObject_ or data store. - **The use case is event-driven.** A document arrives at runtime (for example, a customer upload, an agent PDF attachment, or an external system trigger). The _transactional processing_ pipeline handles synchronous, single-document extraction without batch setup. **Don't Use Document AI when\:** - **Source data is already structured.** If the upstream system exposes a REST API, database table, or structured file (for example, CSV, JSON, or XML), use a standard _Data 360_ connector. Running structured data through an LLM extraction pipeline adds latency and credit costs without additional benefits. - **Documents are machine-generated with a fixed schema.** System-generated PDFs from a known ERP or billing platform with a stable layout are better suited for a deterministic parser. LLM extraction is designed for variability, and applying it to fixed-schema documents wastes context and credits. - **Accuracy requirements exceed LLM confidence thresholds.** _Document AI_ doesn't guarantee 100% extraction accuracy. Use cases where a missed or incorrect field value carries significant financial, legal, or clinical risk requires an HITL validation step. Don't use _Document AI_ as the sole extraction layer for high-stakes decisions without a validation workflow. - **Documents exceed platform constraints.** The current 10MB file size limit and LLM context length constraints make _Document AI_ unsuitable for large or dense documents without pre-processing to split and reassemble them outside of the platform. - **Note\:** At Salesforce, we're actively improving these acceptance guardrails to expand supported file sizes, page counts, and file extensions. Constraints will continue to evolve moving forward. ## Use cases\: Review The Patterns in Practice ### Batch Pipeline Use Cases Let's take a closer look at several scenarios that use the _Document AI batch_ pipeline backed by a UDMO source object. In these instances, extracted data routes through the _Data 360 DLO/DMO_ pipeline for harmonization, identity resolution, _Calculated Insights_, and Agentforce activation. Each use case is best suited for scheduled or event-driven, high-volume document processing. **Agentforce Sales\: Contract and Invoice Intelligence** _Contract_ PDFs are ingested from Cloud storage via the _batch_ pipeline. The schema extracts ContractValue, RenewalDate, PaymentTerms, and CounterpartyName, and then maps them to the _Account_ and _Contract_ DMOs. _Calculated Insights_ derive renewal-risk scores. Agentforce alerts account executives before renewal windows close, which eliminates manual contract review and missed renewals. **Agentforce Service\: Case Deflection and Knowledge Grounding** _Survey_ PDFs and case attachments are ingested via the _batch_ pipeline. The schema extracts sentiment indicators, issue categories, and resolution notes, and then maps them to the _Case_ and _Knowledge Article_ DMOs. Agentforce queries the harmonized knowledge base when the case opens and locates relevant troubleshooting steps, which reduces Agent search overhead. **Agentforce Health\: Clinical Document Processing** Lab reports, intake PDFs, and handwritten clinical forms are ingested via the _batch_ pipeline. The schema extracts fields—including _PatientID_, _DiagnosisCode_, _MedicationName_, and _TestResult_—and then maps them to the _Health Cloud_ DMOs, which supports HIPAA-aligned care coordination and clinical research workflows. **Financial Services\: Loan and Tax Document Automation** Loan applications, tax returns, and income statements ingest via the batch pipeline. The schema extracts fields—including AnnualIncome, TaxYear, and EmployerName—and then maps them to the _Financial Account_ DMOs. _Calculated Insights_ join document-derived income data and CRM data to facilitate automated credit-risk scoring. Agentforce locates the extracted loan details inline during customer service interactions. This pattern directly supports the [Loan Prequalification Agent](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions) use case that's published on the Salesforce _Agentic Enterprise Solutions_ developer center. **HR\: Workforce Document Processing** Onboarding documents, tax forms, and certification PDFs are ingested via the _batch_ pipeline. The extracted fields are mapped to the _Employee Record_ DMOs, and then linked to the _Unified Employee_ profile. Specific _Flows_ initiate onboarding tasks and compliance checks based on the extracted data. This pattern directly supports the [Automate Resume Processing](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions) Agentic use case. _Document AI_ extracts skills, employment history, and qualifications from resume PDFs, which Agentforce then uses to match candidates against open-role criteria and route them to hiring workflows. **Professional Services\: Proposal and Research Intelligence** Proposal decks and research reports are ingested via the _batch_ pipeline. Extracted frameworks, benchmarks, and engagement summaries are mapped to custom DMOs, and then indexed for vector search. Agentforce retrieves contextually relevant recommendations at query time, which are grounded in extracted document content. This pattern extends the [Ground Agentforce on Website Content](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions) pattern. Documents are indexed via _Document AI_ and serve the same grounding function for Agent responses as website content that's indexed via _Data 360_ connectors. **HIPAA Compliance Status\:** The _Health Cloud_ patterns described in this paper apply ETL controls (for example, zero data retention and PHI masking) for text inputs. These controls alone don't constitute HIPAA certification. Architects that are designing for regulated clinical environments must confirm current HIPAA certification status with the Salesforce compliance team before committing to a _Document AI_-based architecture within those contexts. ### Transactional Processing Pipeline Use Cases Let's take a closer look at several scenarios that invoke the _Document AI_ REST API with a schema that isn't bound to a UDMO. Extracted JSON payloads route directly to external systems synchronously at runtime. **Supply Chain\: Vendor Invoice Processing to ERP** When a _vendor invoice_ PDF arrives in a monitored storage bucket or email gateway, an event trigger calls the _Document AI_ REST API with the invoice and a pre-defined schema ID. The schema extracts the VendorID, InvoiceNumber, LineItems, TotalAmount, TaxAmount, and DueDate. The JSON payload routes via _MuleSoft_ to the _ERP Accounts Payable_ module with _null_ field validation and idempotent upsert logic, which eliminates template maintenance for supplier format variability. **Legal Operations\: Contract Review to CLM** When a _contract_ PDF is uploaded to the legal portal, the backend calls the _Document AI_ REST API synchronously. The schema extracts the GoverningLaw, IndemnityCapAmount, TerminationNoticePeriod, AutoRenewalClause, and CounterpartySignatory. The JSON payload routes via _Apex_ callout to the _Contract Lifecycle Management (CLM)_ system. Any fields that aren't found are returned as _null_, and the CLM applies the default obligation rules to the missing values. **Insurance Claims\: First Notice of Loss Processing** When a policyholder submits a _First Notice of Loss (FNOL)_ form, the backend portal calls the _Document AI_ REST API synchronously. The schema extracts the PolicyNumber, IncidentDate, IncidentLocation, DamageDescription, ClaimantName, and ContactPhone. The JSON payload routes to the _claims management_ database via _Apex_ callout or ETL, which creates a pre-populated claim record for adjusters to review before the formal claim is opened. ## Design Considerations and Failure Modes Before you move to production, you must create designs for these failure scenarios. - **Null Field Handling\:** The LLM returns _null_ for fields it can't locate or confidently extract. Validate null-handling logic at schema design and implement default value or rejection logic in the integration layer before writing to any targets with _NOT NULL_ constraints or required match keys. - **OCR Quality Degradation\:** OCR accuracy degrades below 150 DPI, on irregular handwriting, or on noisy scans. Misreads propagate into LLM extraction as corrupted input without error signals. Enforce minimum scan quality at ingestion and implement confidence threshold checks on numeric and date fields. - **Schema Version Mismatch\:** Updating a schema configuration after a batch job is scheduled causes in-flight documents to process against the previous version, which produces missing or renamed fields that break downstream mapping. Version schemas explicitly and coordinate updates with batch job schedules. - **File Size Limits\:** Documents that exceed 10MB are rejected. Batch pipeline failures are silent without monitoring configured, and transactional callers receive a _4xx_ error. Pre-validate file sizes at ingestion and implement pre-processing to split or compress documents that regularly approach the limit. - **LLM Context Overflow\:** Dense or multi-page documents may exceed the LLM context window within the 10MB limit. The LLM silently drops content that exceeds context. Implement a chunking strategy that splits documents by page range and reassembles the extracted fields before transferring them to the target. - **Trust Layer Masking Affecting Extraction\:** The ETL operates at the prompt level—not the document level—so masking doesn't apply to document content that passes through _Document AI_. Schema fields that depend on _PII_ values in the document aren't affected by ETL-masking policies. - **External RDBMS Write Idempotency\:** The _transactional processing_ pipeline doesn't have any built-in idempotency for external _RDBMS_ targets. _Integration layer_ retries create duplicate rows unless the write logic handles de-duplication explicitly. Implement idempotent upserts using a document fingerprint or external ID on all external write paths. - **Credit Exhaustion Mid-Run\:** Large batch runs may exhaust _Digital Wallet_ credits before all documents are processed, which produces incomplete DLO datasets that downstream steps view as complete. Set consumption alerts to 75% and 90% of available credits and limit batch sizes to stay within the credit budget for each cycle. - **Schema Field Limit — Architectural Constraint\:** _Document AI_ enforces a 50-field limit for root-level fields in a schema configuration. This is a design-time constraint—not a runtime error—and architects must account for it during data model and schema design. - For use cases that require broader extraction\: - Prioritize ruthlessly. Narrow the schema to fields that drive automation value, not exhaustive document coverage. - Leverage nested objects (up to 3 levels; batch mode with source object only) to reduce the root-level field count without sacrificing extraction depth. - Decompose complex documents across multiple _Document AI_ configurations that target distinct document sections, write results to separate DLOs that join downstream in _Data 360_. - **API Rate Limits\:** _Document AI_ enforces a limit of 50 extraction API calls per minute per tenant. The theoretical ceiling is 300 calls per minute, which is governed by the _Einstein LLM Gateway_. High-volume transactional integrations must be designed with exponential backoff, request queuing, and tenant-level throughput budgeting. Don't assume that burst capacity is available in multi-tenant production environments. - **API Latency Profile\:** _Document AI_ extraction APIs are fully synchronous. Typical response times range from 5–15 seconds, and they vary by file size and schema complexity. - This has direct implications for integration architecture\: - Set caller timeouts to a 30-second minimum. - Don't invoke _Document AI_ in flows with sub-second SLA requirements. - Factor latency into throughput calculations against the rate limit ceiling for _batch processing_ pipelines. - **Encrypted and Password-Protected Documents\:** _Document AI_ doesn't process password-protected files (user passwords are required to open files) or PDFs that are encrypted with an owner/permissions password, including files that open normally but restrict copying, printing, or editing at the _PDF permissions_ layer. - This constraint sits at the ingestion boundary\: - Design _document intake_ pipelines to detect and route encrypted files to a _rejection_ or _manual processing_ path before they reach _Document AI_. - Don't rely on runtime error handling as the primary gate. ## Well-Architected Alignment _Data 360 Document AI_ aligns with several pillars of the Salesforce _Well-Architected Framework_. - **Trust\:** The ETL enforces zero data retention with LLM providers, masks _PII_ inputs before they reach the model, and scans outputs for sensitive content. Architects must extend this posture to extracted data at rest. Field-level masking in DLOs isn't applied by the ETL, and it requires downstream _Data Space_ policies and _Permission Sets_. - **Reliability\:** Each failure mode in the _Design Considerations_ section—null field extraction, OCR misread, schema version mismatch, file size breach, LLM context overflow, ETL masking interference, RDBMS write idempotency and credit exhaustion—represents a distinct failure class with a documented detection signal and resolution path. - **Operational Excellence (change management)\:** The schema-driven extraction model decouples the extraction logic from the document layout. When a vendor changes an invoice format or a regulatory form is updated, architects only need to update one schema configuration rather than modifying integration code. - **Operational Excellence (maintainability)\:** Centralizing schema configurations in _Data 360_ rather than embedding extraction logic in application code makes extraction intent explicit, versioned, and auditable. All downstream targets consume the same schema contract regardless of their target tier. - **Operational Excellence (integration reuse)\:** _Document AI_ exposes extraction across multiple integration surfaces\: REST API, _Apex_, _Flow_, _MuleSoft_, Agentforce _Actions_, and the MCP server. A single schema configuration fans out to multiple target tiers simultaneously without rebuilding the extraction capability per consumer. - **Resource and Cost Optimization\:** The pipeline selection guidance, 10MB file size boundary, and pre-assembly LLM context length constraints represent performance-aware design decisions. The _When to Use_ section formalizes the conditions for when _Document AI_ isn't the right tool (for example, sub-second latency requirements, fully-structured source data, and fixed-schema machine-generated documents). ## Quick-Start Guide for Architects This is a structured starting point for configuring _Data 360 Document AI_ in a sandbox environment. Complete all phases in the sandbox before moving to production. ### Before You Begin Before beginning configuration, you must confirm\: - **File Size\:** Validate that the representative document sizes are under 10MB. - **Pipeline\:** Confirm whether the use case requires the _batch_ pipeline (UDMO-backed, high-volume) or the _transactional processing_ pipeline (API-driven, single-document). This drives all subsequent configuration. - **Target Tier\:** Confirm where the extracted data lands—Salesforce _SObject_, _Data 360_ DLO/DMO, external RDBMS, or a combination. - **Agentforce Dependency\:** Before deploying any Agentforce-powered document processing, confirm that a supported [LLM](https://help.salesforce.com/s/articleView?id=ai.generative_ai_large_language_model_support.htm&type=5) (for example, _GPT-4o_) is enabled in your org via the ETL settings. Agentforce is a hard platform prerequisite for _Document AI_. The entire _Document AI_ feature surface—including all extraction APIs—is unavailable until Agentforce is active in the target org. Factor this into org readiness assessments and provisioning sequencing. Allow a few minutes for API availability to stabilize post-enablement. - **Agentforce Disablement Impact\:** If Agentforce is disabled after _Document AI_ is configured and deployed, then all extraction processing (UI and API) will be blocked immediately. The same applies to model disablement. Disabling the underlying model has an equivalent effect on _Document AI_ availability. In both cases, the existing schema configurations are preserved and will remain visible—no configuration or data loss will occur—but the capability is fully inoperable until Agentforce and the model are re-enabled. Design operational runbooks to treat Agentforce availability and model enablement as _Document AI_ health dependencies. - **Credit Consumption/Pricing\:** Use _Data 360_ credits or _Flex Credits_ for TCO estimates that are derived from representative sample documents. #### Phase 1\: Schema and Pipeline Configuration - **Create the schema configuration.** Define extraction fields, data types, and instructions in _JSON Schema_ format in the _Data 360 Document AI_ setup. For the _batch_ pipeline, bind it to a UDMO. For the _transactional processing_ pipeline, create it without a source object. Record the schema ID. - **Align field names to the target tier.** Match field names to DLO column definitions, _SObject_ API names, or RDBMS column names. Misaligned names create mapping overhead in the integration layer. - **Configure the UDMO source object (batch only).** Define documents in scope and configure ingestion source connectivity (for example, _S3_, _Google Cloud Storage_, _Salesforce Files_, or _MuleSoft)_. Confirm that the ingestion service account has the required _IAM_ or _OAuth_ credential scope. - **Apply PII masking policies.** Configure _Data Masking_ policies in the ETL settings before processing any regulated content. Define which field types (_PHI_, _PII_, and financial identifiers) are masked before inputs reach the LLM. **Don't** defer this step. - **Assign Data Space scope and Permission Sets.** Scope processing to the appropriate _Data Space_ and configure _Permission Sets_ to control schema creation, batch job execution, REST API invocation, and downstream activation. - **Configure API authentication (transactional processing pipeline only).** Create a _Connected App_ with _OAuth_ scopes cdp_ingest_api and api. For org-internal callers, use a _Named Credential_ that links to an _External Credential_. For external callers, configure _OAuth 2.0_ client credentials or a JWT-bearer flow. Test and validate extraction before proceeding. #### Phase 2\: Integration and Target Configuration - **SObject write-back\:** Implement an _Apex_ (@InvocableMethod) or _Flow_ element that maps JSON response fields to _SObject_ fields. Use Database.upsert() with an external ID to prevent duplicates. Apply _Field-Level Security_ on target _SObject_ fields. - **Data 360 DLO/DMO pipeline\:** Map extracted DLO fields to DMOs that align with the _Customer 360 Data Model_. Configure identity resolution rules to link document records to _Unified Individuals_. Define _Calculated Insights_ and add DMOs for Agentforce. For the transactional processing pipeline, route the JSON payload to a DLO via the _Ingestion_ API first. - **External RDBMS or data warehouse\:** Select the integration pattern\: _MuleSoft_ (existing integration fabric), _Apex_ HTTP callout (lightweight, org-native), _Platform Events_ with the _Pub/Sub_ subscriber (event-driven), or ETL (high-volume batch). Implement idempotent upserts using a document fingerprint or external ID on all external write paths. - **Activation paths\:** Connect Agentforce actions to schema configurations for interactive extraction. Configure _Flow_ or _Apex_ triggers for automated processing workflows and establish the activation targets for each field group. - **Error handling (transactional processing pipeline only).** Configure the full HTTP response surface\: **200** (_successful_, including partial _null_ responses), **400** (_malformed request_ or _schema ID not found_), **413** (file exceeds 10MB), **5xx** (service error). Implement exponential backoff for _5xx_ retries with a maximum of 3 attempts. Log the raw JSON response and schema ID on every call. #### Phase 3\: Validate and Prepare for Production - **Test schemas against sample documents.** Submit representative samples via the _Document AI_ interface or REST API. Confirm extraction accuracy, field coverage, and null handling across layout variations. - **Validate null field handling.** Confirm that all downstream targets can handle _null_ values for _fields not found_ in a document. Keep in mind that _NOT NULL_ constraints fail silently without explicit null handling. - **Pre-validate file sizes.** Confirm that production documents stay under 10MB. Implement pre-processing to split or compress documents that regularly approach the limit. - **Validate end-to-end extraction.** For the _batch_ pipeline, initiate a full run and confirm that the extracted fields land correctly in each target tier. For the _transactional processing_ pipeline, trace the JSON response through the _integration_ layer to the target. Verify the trigger and flow execution for the _SObject_ targets, the identity resolution linkage for the _DLO/DMO_ targets, and the idempotency for the _RDBMS_ targets. - **Confirm Trust Layer behavior.** The ETL doesn't apply _PII_ masking to document content, so the LLM will return _PII_ data in extracted fields as-is. Confirm that your schema fields, data routing, and downstream storage are designed to handle PII-bearing output appropriately, and ensure that any compliance or retention requirements are addressed outside of the platform. - **Set Digital Wallet alerts.** Configure consumption alerts at 75% and 90% of available credits. Establish batch size limits and ad-hoc rate estimates within the credit budget for each cycle. - **Validate batch monitoring (batch pipeline only).** Review extraction success rates, null field rates, and job completion in the _Data 360_ monitoring console. Confirm the tag propagation from the UDLO through the DLO to the DMO in data lineage. - **Validate API error handling (transactional processing pipeline only).** Test all error conditions\: **413** (documents over 10MB), **400** (invalid Schema IDs), **200** (valid extractions with partial nulls). Confirm that the retry logic fires on simulated **5xx** responses without creating duplicate writes. ## Conclusion This document highlights the architectural foundations of _Data 360 Document AI_\: - Two processing pipelines and when to use them - The schema configuration model - The target tier decision framework - Core technology constraints - Failure modes - _Well-Architected Framework_ alignment The [Quick-Start Guide for Architects](/docs/architect/fundamentals/guide/data360-document-ai#quick-start-guide-for-architects) provides the configuration sequence for a sandbox proof of concept. The core architectural posture supports document-derived data that's governed at the _Schema_ layer, processed via an ETL-enforced LLM pipeline, and delivered to the same _Data 360_ data lifecycle that governs all of our other enterprise data. Architects who apply these principles—selecting the correct pipeline, designing schemas at the document-type level, and designing for failure modes before production—build extraction capabilities that scale and endure under regulated industry governance requirements. ### About the Authors **Yugandhar Bora** is a Software Engineering Architect at Salesforce who specializes in data architecture within the _Data and Intelligence Applications_ platform. He leads _Enterprise Architecture Review Board (EARB)_ initiatives that focus on data governance and unified data models, while also contributing to automated platform provisioning solutions. **Ananth Anto** is a Director of Product Management at Salesforce _Data 360_ who leads _Document AI and Data Graph_ initiatives. Based in Bangalore, he works with enterprise customers to solve real-world document-processing and data-intelligence challenges. He enjoys exploring _Enterprise_ use cases for _Generative AI (Gen AI)_. **Nishan Naseer** is a Software Engineering Architect at Salesforce who works on _Unstructured Data Processing_, _RAG_ pipelines, and _Document Intelligence_. He's passionate about harnessing the power of AI to tackle real-world challenges and find creative solutions to complex customer issues.