How MuleSoft IDP and Agentforce Structure Complex Contract Data in Salesforce

For teams managing service agreements, MuleSoft IDP and Agentforce turn contract review from a manual document search into a governed Salesforce workflow, without asking AI to interpret legal language.

Contracts are rarely standardized, simple, or short. They arrive from customers, vendors, and partners in different formats, with different structures and varying consistency from one document to the next. For one of our clients, that was exactly the challenge.

The client manages service agreements and customer-provided contracts in Salesforce using the standard Contract object. These agreements run from 50 to 200+ pages and carry the terms that surface long after signature: renewal language, payment terms, rate review rights, volume commitments, invoicing deadlines, subcontracting language, and licensing requirements.

The problem was never storing the contract. It was helping business users find what they needed without re-reading a long, inconsistent document every time a question came up. We implemented a solution combining Salesforce Contracts, MuleSoft IDP, Salesforce Flow, and Agentforce.

Getting Contract Data Into Salesforce

Before Agentforce could answer anything, the data had to come out of the document and into Salesforce in a structured way. MuleSoft IDP does the extraction, but it processes a bounded number of pages per request and enforces file size limits. A 200-page master services agreement does not fit through that door in one piece, so we built an upload and processing flow around chunking.

• Upload and hand off. A user uploads the PDF from the Contract record. Salesforce Flow stores the file, creates a document extraction result record, and publishes a platform event so MuleSoft knows a request is waiting.

• Chunk. MuleSoft retrieves the file, evaluates its size and page count, and splits larger documents into independently processable sections. Each chunk carries overlap from its neighbors so language crossing a page boundary is not lost at the seam.

• Extract. IDP pulls the requested fields from each chunk and writes the values back to Salesforce.

• Consolidate. Values from every chunk are assembled on the extraction result record, then copied into dedicated IDP fields on the related Contract.

Lesson Learned: The Model Decides Your Chunk Size

This is the part we would tell any team starting down the same path. The AI model running inside MuleSoft IDP has a major impact on extraction quality, and on the chunking architecture you are allowed to build.

Fifty pages per extraction was the advertised ceiling. In practice, the model available at implementation time held us to about ten. That is not a tuning detail; it changes the shape of the solution. Ten-page chunks meant more chunks per contract, more platform events, more consolidation logic, and more chances for a clause to split across two extractions. It also cost quality: a model seeing ten pages has less context to judge whether the paragraph in front of it is the renewal clause that governs or an exhibit restating one.

Chunk size is not a throughput setting. It is a context-window decision, and it shows up in the quality of every field you extract.

Credit where it is due: Salesforce moved on this quickly. With their release of additional models plus a patch, 50-page chunks became supported again. The gain was immediate on both axes: fewer chunks and less consolidation overhead, and better information per field, because each pass could see a whole section rather than a slice of one.

It is worth saying plainly that hitting a product limitation mid-implementation is a normal part of building on an evolving platform, and the measure of a platform is how fast that limitation closes. Salesforce’s roadmap for IDP kept pace with what our client needed, and their support teams were transparent about the constraint while the fix was in flight. That responsiveness is a real part of why we keep building on this stack.

The takeaway: treat the model as an architectural variable, validate advertised page limits against the model you are actually assigned, and make chunk size configurable rather than baked in. Because we did, moving from ten pages to fifty was a parameter change instead of a rebuild. Keep the overlap either way; it is cheap insurance.

Turning Extracted Data Into Answers

With the extracted values on the Contract record, we configured an Agentforce employee agent around the user’s daily workflow. Users ask a plain question from the record and get a controlled readback of the relevant data: what are the payment terms, does this contract automatically renew, what does it say about non-renewal notice, what is the rate review cadence, are there volume guarantees, is anything flagged for review.

Agentforce answers using only the extracted Contract fields in Salesforce. Nothing else.

Controlled Readback, Not Legal Interpretation

A key part of the design was being intentional about what the agent should not do. It does not give legal advice, interpret contract language, assign risk ratings, or recommend what the business should do next. It is a structured contract data readback assistant.

Agentforce is instructed to:

• Use only approved extracted fields from the Contract record.

• Treat questions asked from the Contract page as referring to that contract.

• Avoid general knowledge responses, and avoid paraphrasing extracted language.

• Return “Unavailable in extracted contract data" when information is missing.

• Direct users toward specific questions rather than a full contract readout.

• Avoid legal advice, recommendations, negotiation guidance, or risk ratings.

Users get faster access while governance holds. For a legal or compliance stakeholder, the “will not" list is often what makes the “will" list approvable.

Why Prompt Flow Mattered

The client wanted answers across roughly sixty contract areas, from contracting parties and effective dates through renewal terms, rate increase language, payment terms, volume guarantees, licensing requirements, and extraction confidence.

Rather than loading every field into one prompt template, we used a template-triggered prompt flow. It evaluates the question and returns only the relevant category of data. Ask about payment terms, and it returns payment fields. Ask about licensing, and it returns licensing fields.

That keeps the prompt clean, improves routing accuracy, and stops the agent surfacing unrelated fields simply because they happen to be populated. It also keeps the design extensible: a new extracted field is a routing change, not a prompt rewrite.

Business Value

From the Contract record, users need to know nothing about field names, API names, or how the document was processed. They ask a business question and get the values back. The architecture behind it stays deliberately controlled: chunk, extract, consolidate, route, read back without interpretation.

The result:

• Faster access to important contract terms, with far less manual review for sales and account teams.

• Better visibility into renewal and non-renewal requirements.

• Easier review of commercial terms such as payment, rate increases, and volume commitments.

• Clear identification of missing or low-confidence extracted data.

• A governed Agentforce experience grounded in Salesforce data, reducing reliance on unsupported AI interpretation.

The goal was never to let AI freely interpret contracts. It was to combine document intelligence, structured Salesforce data, and a conversational interface so contract information becomes easy to reach, with a clear line between what the system extracts and what a human decides.

Where This Goes Next

A follow-up post will look closer at the document processing architecture: how large PDFs are uploaded, chunked, processed, consolidated, and written back to Contract fields.

Further out, Agentforce can reason across multiple contracts extracted through IDP. That unlocks a richer capability: seeing what changed over time, contract by contract, surfaced through natural language chat with reference sources behind it.

The Same Pattern, Other Documents

Contracts made a good first candidate because they are long, variable, and full of terms people need on short notice. But the pattern travels: chunk, extract, structure, govern the readback. If your organization has a document type people read manually to answer repeat questions, it is probably a fit.

Invoice and AP processing. Line items, totals, tax, PO references, and payment terms pulled from vendor invoices that never share a layout, matched against purchase orders and routed for exception handling instead of keyed by hand.

Loan and mortgage documentation. Applications, income verification, appraisals, and disclosures arriving as a stack of unstandardized PDFs. Extraction turns the packet into a reviewable checklist and surfaces missing data early.

Onboarding and HR forms. Offer paperwork, credentials, and certifications extracted into employee records, with expiration dates that drive proactive renewal reminders rather than an annual audit scramble.

Shipping and customs documentation. Bills of lading, commercial invoices, packing lists, and certificates of origin, each formatted per carrier and country, giving operations one consistent view of a shipment.

RFP and proposal intake. Requirements, deadlines, compliance clauses, and scoring criteria pulled from inbound RFPs so teams qualify quickly instead of re-reading a 90-page solicitation.

In each case the same lesson applies. Validate the model behind the extraction, and the chunk size it will actually permit, before the architecture is set.

The Takeaway

Contracts are one of the most important sources of business truth and one of the hardest to operationalize. Extracting them into Salesforce and making them accessible through Agentforce closes that gap, letting users answer important questions faster, more consistently, and with stronger governance.

If your team is weighing a similar build, the honest advice from this one: start with a document type where the questions repeat, be explicit about what the agent will refuse to do, and pressure-test your extraction model’s real limits before designing around the advertised ones.