Data 360
Document AI in Data 360: turning a PDF into columns an agent can query
Chunking a contract for retrieval lets an agent read what it says. Document AI does the other job: it pulls named fields, ContractValue, RenewalDate, TotalAmount, out of the PDF into a Data Lake Object your Flows, Calculated Insights, and agents can query. Here is how the schema, the two processing modes, and the licensing work, and where extraction still needs a human check.
Most teams point a retriever at their PDFs when what they needed was a database column. The two are not the same job, and reaching for the wrong one is why an agent can quote a contract fluently but can’t tell you whether it renews next month.
Retrieval chunks a document, embeds the pieces, and lets a model read the passages that match a question. It answers “what does this contract say about termination.” Document AI answers a different question: “what is the contract value, and when does it renew.” It reads the document once and writes the fields, ContractValue, RenewalDate, PaymentTerms, into a structured Data Lake Object you can filter, compare, and trigger on.
My rule: if you need the value of a field to drive logic, a number to compare or a date to fire on, that is extraction, and Document AI is the tool. If you need the text for a model to read and summarize, that is retrieval. A serious use case usually needs both, on the same document, for different reasons.
What Document AI produces
Document AI is a Data 360 feature that uses a large language model to read an unstructured document and return structured fields. The model reading each document is one of the Trust Layer’s hosted models, GPT-4o, Gemini, or Claude, so the same Einstein Trust Layer masking and logging that governs your agents governs this too.
The document lands first as an Unstructured Data Lake Object, a UDLO that references the file. Document AI then runs the file against a schema configuration you define and writes the extracted values into a regular Data Lake Object. From there the data behaves like any other DLO: you can map it into a Data Model Object, feed it a Calculated Insight, point a search index at it, or expose it to an agent action.
That last hop is the point. Once a vendor invoice’s TotalAmount and DueDate are columns in a DLO, an agent doesn’t have to read the PDF to reason about them. It queries a number. The document became data.
The schema is the part you design
Everything good or bad about an extraction traces back to the schema configuration. The schema is a list of the fields you want and the data type each one should be, and Document AI extracts exactly what you name, nothing more.
You build it two ways. The document schema builder lets you add fields and tables by hand, naming each one and setting its type. Or you let Data 360 auto-generate a first draft from a sample document and then correct it. For a stable document like a supplier invoice, hand-building is worth the half hour, because the field names you choose become the column names every downstream Flow and query depends on.
A schema for an invoice is small and concrete:
Document AI schema: VendorInvoice
field VendorName text
field InvoiceNumber text
field InvoiceDate date
field DueDate date
field Currency text
field SubtotalAmount number
field TaxAmount number
field TotalAmount number
table LineItems
column Description text
column Quantity number
column UnitPrice number
column LineTotal numberTables matter as much as fields. An invoice has one vendor and one total, but many line items, and Document AI can extract a repeating table into a child structure rather than flattening it. Get that right and reconciling a three-way match against a purchase order is a join, not a parsing exercise.
Real-time or batch, and how to choose
Document AI runs in two modalities, and the choice is about where the documents come from.
Real-time, the API modality, invokes Document AI directly on a document stored in Salesforce or sent at run time. A file arrives through a channel or a Flow, you call the Document AI API with your configuration and the document, and you get the extracted payload back to act on immediately. Reach for it when a person or a process is waiting on the result, a customer uploads an ID during onboarding, a rep drops a signed order form into a case.
Batch modality processes a set of documents defined through a UDMO and persists the extracted values as new Data Lake Objects. Batch is built for volume: a nightly sweep of a cloud-storage bucket full of contracts, a backlog of scanned statements. Nobody is waiting on any single document, so it optimizes for throughput and lands everything in DLOs ready for segmentation and insights.
The pattern I keep coming back to pairs the two. Batch-extract the historical corpus once to populate the DLOs, then real-time-extract each new document as it arrives so the structured view stays current without re-sweeping the whole bucket.
A worked example: contracts that warn you before they lapse
Put the pieces together on a renewals problem, because it shows extraction feeding logic rather than search.
Contract PDFs sit in cloud storage. A batch Document AI job runs them against a schema that pulls ContractValue, RenewalDate, PaymentTerms, and CounterpartyName, and writes those into a DLO. You map that DLO onto the Account and Contract Data Model Objects, so each extracted contract lines up with the customer it belongs to.
Now the values can drive something. A Calculated Insight scores renewal risk from RenewalDate and ContractValue, the high-value contract lapsing in 45 days scoring higher than the small one a year out. An Agentforce agent reads that score and drafts the outreach for the account executive before the window closes.
No human retyped a contract, and no agent had to read one at answer time. Extraction turned the document into fields, insights turned the fields into a signal, and the agent acted on the signal. The same shape works for loan packets, insurance policies, and statements of work. Only the schema changes.
Where extraction still needs a hand
Document AI is an LLM reading a document, which means it is very good and occasionally confidently wrong. Treat the output as a strong draft, not gospel, and build the checks that habit implies.
Validate before you write anything downstream. A missing TotalAmount, a DueDate earlier than the InvoiceDate, a currency that doesn’t match the vendor record, each is a cheap rule that catches a bad extraction before it posts to your ERP. The same discipline keeps an accounts-payable agent auditable: the model proposes, a deterministic check disposes.
Design for the messy document, not the clean sample. Scans, rotated pages, handwriting, and two invoices in one PDF all degrade extraction, and the fix lives before Document AI, in the quality of what you feed it. A schema that matches your best template and a corpus full of your worst will disappoint.
Watch the cost and the license. Every document is an LLM inference metered in credits, so a one-time batch over a large archive is a real line item worth estimating against your rate card first. And Document AI needs a Data 360 license; it is not available on the legacy Customer Data Platform SKU, which is the first thing to confirm before you design around it.
What I would build first
Pick one high-volume, high-consistency document, an invoice, a specific contract template, an onboarding form, and hand-build a tight schema for it. Resist the urge to extract 40 fields; extract the six that drive a decision.
Run it in batch over a sample of your real documents, not the vendor’s clean example, and read the output critically to find where the schema or the source quality falls down. Add the validation rules that catch the failures you saw. Only then wire the DLO into a Calculated Insight or an agent action, and turn on real-time extraction for new arrivals.
Done that way, Document AI stops being a demo that reads one perfect PDF and becomes the thing that retires a data-entry queue. The document was always the bottleneck; Document AI turns it into a column.
Understanding the basics
What is Document AI in Salesforce Data 360?
Document AI is a Data 360 capability that uses a large language model to extract structured fields from unstructured documents like invoices, contracts, and forms, and writes them into a Data Lake Object. Unlike retrieval, which chunks a document so an agent can read passages, Document AI pulls named values such as total amount or renewal date into columns your Flows, Calculated Insights, and agents can query directly.
How is Document AI different from chunking a document for RAG?
They solve opposite problems on the same file. Chunking and embedding make a document searchable so a model can read the relevant text and answer an open question about it. Document AI extracts specific, named fields into structured data you can filter, compare, and trigger on. Use retrieval when you need the text read; use Document AI when you need a value to drive logic; use both when a document has to do each.
Does Document AI support real-time and batch processing?
Yes. Real-time, or API, modality runs extraction on a document stored in Salesforce or sent at run time and returns the result immediately, which fits interactive flows where someone is waiting. Batch modality processes a set of documents defined through a UDMO and persists the results as new Data Lake Objects, which fits high-volume sweeps of external storage where no single document is time-critical.
What licenses do I need for Document AI?
You need a Data 360 license. Document AI is not available with the legacy Customer Data Platform licenses, so confirm your entitlement before designing around it. Because each document is processed by a Trust Layer LLM, extraction also consumes credits per document, which is worth estimating against your rate card before a large batch run.
Sitting on a queue of PDFs your team retypes into Salesforce by hand? Turning documents into governed, structured data that a Flow or an agent can act on is core integration work, and exactly what we do. Talk to us about your data foundation.
