Inside the Pipeline: How Contract Extraction Actually Runs on MuleSoft IDP

A technical walkthrough of the trigger, the authentication, and the operational levers behind the contract data pipeline we described last time, for the architects and admins who have to run it.

Our last post covered why one of our clients turned to MuleSoft IDP and Agentforce to make 200-page contracts queryable from a Salesforce record, and the chunking lesson that came out of it. That post was aimed at the business case. This one is for the people who have to build and maintain the thing: the trigger path, the authentication that has to survive certificate rotation, and the configuration knobs that decide whether a model change is a five-minute property update or a redeploy.

Everything below reflects how the solution is actually documented for the admins and developers who own it going forward, not just how it behaves on a good day.

The Trigger: A Screen Flow, Not an Automatic Job

Extraction is user-initiated. From the action dropdown on the Contract record, a screen flow lets a user either pick a document already attached to the contract or upload a new one. An optional “select pages to send” checkbox accepts the same page-range syntax as a print dialog – 1,5,8 or 1-10,15 – so a user can send a single amendment instead of a whole executed agreement. Leave it unchecked and the full document goes.

The flow’s only other input is a toggle for whether the extraction should overwrite existing values on the contract or leave populated fields alone. That single flag is what lets the same flow serve two very different moments: the first extraction on a new contract, and a re-run after a contract amendment where fields may be overwritten. Each extraction will store an entire IDP extraction of values for the Contract, but this toggle will determine whether to overwrite the Contract’s IDP Extracted information or not.

The Extract Contract Info screen flow, launched from the Contract record’s action dropdown. Company names shown here are illustrative.

The Handoff: A Platform Event, Not a Direct Callout

When the flow finishes, it publishes a platform event, Contract_Extraction__e, and tells the user the request has been made. Salesforce does not call MuleSoft directly. Four fields ride on the event: the ContentVersionId of the submitted document, the filter-pages value from the flow (null means send everything), the requesting user (who owns notifications on the result), and the overwrite flag.

The event-driven handoff decouples the user’s screen flow from IDP’s processing time. A 200-page contract that gets split into several chunk requests does not hold the UI open while it runs. The trade-off architects should plan for: platform events aren’t visible or replayable from Salesforce once consumed, so there’s no native way to confirm MuleSoft picked one up. That visibility gap is closed on the MuleSoft side, not the Salesforce side – which is why the integration log described below matters more here than it would in a synchronous design.

Authentication: The External Client App and Its Certificate

MuleSoft authenticates to Salesforce through an External Client App using a self-signed certificate and a JWT bearer flow, not a stored password. That certificate is created inside Salesforce and expires after one year. When it expires, MuleSoft can no longer authorize, and every extraction stops silently until someone notices. This is the piece of the architecture most likely to cause an outage that has nothing to do with IDP, the model, or the Mule app itself, and it deserves a place on whatever calendar your team uses for recurring platform maintenance.

The rotation is a five-system relay, and it only works if the pieces are done in order:

Generate a new self-signed certificate in Salesforce Setup, with the exportable-private-key option checked, and download it.
Upload the new certificate to the External Client App’s OAuth settings, replacing the expiring one.
Export the certificate to a keystore from Certificate and Key Management, choosing a password at export time: it isn’t retrievable afterward, so record it before clicking export, then paste it in to guarantee an exact match.
Drop the new .jks file into the Mule project’s src/main/resources folder in Anypoint Studio, then update that environment’s .properties file: sf.keystore.path to the new filename, and sf.keystore.alias to the certificate’s name in Salesforce – lowercased, regardless of how the label was cased when it was created.
Update the keystore password on the Salesforce Config global element in the Mule app, then redeploy to CloudHub to apply it.

Certificate and Key Management in Salesforce Setup. The Expiration Date column is the one worth a recurring calendar check.

None of this is difficult in isolation. What makes it worth documenting explicitly is that the failure mode is quiet: nothing in Salesforce tells a user their extraction request went nowhere, so a lapsed certificate tends to surface as “IDP stopped working” days after it actually did.

Making Change a Property Flip, Not a Redeploy

Our first post’s central lesson was that chunk size is a model-dependent setting, not a fixed constant, and that we were glad we hadn’t hardcoded it. The same design instinct shows up across the rest of the Mule application’s runtime properties, which can be updated in Anypoint Runtime Manager without a redeploy:

actionVersion : which published version of the IDP document action the app calls. Publish a new version of the prompts, bump this property, and the app starts using it immediately; roll it back the same way if the new version misbehaves.
sfPrincipal : the Salesforce user under whose identity the app creates and updates records. In production this should be a dedicated Integration User, scoped to only what the extraction pipeline needs to touch.
documentActionId : which document action the app points to at all. Changing this is a bigger lever than a version bump and warrants caution, since it can point the pipeline at a fundamentally different prompt set.

The document extraction app in Anypoint Runtime Manager, where actionVersion, sfPrincipal, and documentActionId live as editable properties.

The pattern worth taking away: every setting that is likely to change on a timeline outside your control, such as a new model, a new prompt version, or a new integration user – should live in application properties, not in code or in a hardcoded config value. It’s the difference between an incident and a configuration change.

The Document Action: A Contract, Literally

Inside Anypoint Platform’s IDP section, the “Contract Action” holds the prompts that tell the model what to extract and how to structure the response. Each prompt asks for a JSON object with named fields, and the Mule application maps those field names directly onto Salesforce API names when it writes the results back.

The Contract Action document action in Anypoint Platform. Each output field on the right maps to a Salesforce API name on the other end.

That mapping is the real contract in this architecture, and it runs in both directions. Rename or remove a field in the prompt’s expected JSON, and the Mule app fails to find what it’s looking for. Rename the corresponding field’s API name in Salesforce without updating the prompt to match, and the same failure happens from the other side. The prompt language itself can be tuned freely to improve extraction quality – that’s expected and encouraged – but the output shape is the piece that has to move in lockstep with the Salesforce schema. Anypoint Platform lets you test a document action against a sample file and inspect the JSON it returns before publishing, which is the right gate to run any prompt change through before it reaches production traffic.

Observability Lives on the Contract Record

Since platform events leave no trail once consumed, the pipeline creates its own: a MuleSoft Integration Logs related list on the Contract record. Every extraction request produces a Request-type log naming the submitted document. Once MuleSoft accepts it, one or more additional logs appear, one per IDP execution ID.

That last detail is a direct, visible echo of the chunking behavior from our first post: a contract over the page limit for a single IDP request comes back as multiple logs with multiple execution IDs, one per chunk. An admin troubleshooting a partial extraction doesn’t need to guess whether chunking happened, the log count on the contract answers it.

This is a bigger design decision than it looks. A lot of companies bring in MuleSoft precisely because they want a dedicated integration platform, but the people who have to operate the result, admins, support staff, business users troubleshooting their own records, live in Salesforce day to day, not in Anypoint. Anypoint has its own monitoring and its own logs, and they’re the right tool for a MuleSoft developer debugging a flow. They’re the wrong tool for a Salesforce admin who just wants to know why one contract’s extraction didn’t come back, and giving that admin an Anypoint login just to answer that question is its own ongoing overhead.

The logging object closes that gap. Every step of the extraction, and every error the Mule app encounters along the way, gets written back to Salesforce as a record, not just the request and the final result. That means the whole lifecycle of an extraction is visible from inside the platform the admin already knows, with no Anypoint credentials required to see it. It’s a small piece of design that pays off disproportionately: it’s the difference between checking a related list on the record and filing a ticket to someone who can log into Anypoint, and it’s a pattern worth carrying into any integration where the people operating it day to day aren’t the people who built it.

What This Means for the Next Build

Stepping back from this specific pipeline, a few principles generalize to any document-intelligence build on Salesforce and MuleSoft:

Decouple the trigger from the processing with an event, not a synchronous callout, but build a durable log somewhere the business user can see it, since events alone leave no trail.
Treat certificate-based auth as a recurring operational task with an owner and a calendar reminder, not a one-time setup step.
Externalize anything tied to a model, a prompt version, or an environment-specific identity into runtime properties, so the fix for the next platform shift is a value change, not a deployment.
Version the extraction schema deliberately. The JSON shape connecting the prompt to your Salesforce fields is an interface contract between two systems that don’t share a deploy pipeline – change it with the same care you’d give an API version.

None of this is unique to contracts. It’s the same discipline we’d bring to invoices, loan packets, HR onboarding documents, or shipping paperwork, any document type where a business user’s question shouldn’t require reading the file.

Closing

The first post made the case for why this pipeline is worth building. This one is the runbook underneath it: the trigger, the auth, the properties, and the logs that keep it running past the day it launches. If you’re evaluating a similar build, budget for the operational pieces up front – certificate rotation and schema versioning in particular – rather than discovering them the first time something quietly stops.