Contracts are written, negotiated and signed in Ironclad. Salesforce holds a copy — a workflow record with its status, its approvers and its signers, plus a link back to the real thing. Salesforce does all the talking: it launches the workflow and it goes and fetches the updates. Ironclad never pushes anything in.
Every workflow is launched from an Account in Salesforce — not from an Opportunity, and not from Ironclad directly. Five request types are configured, and the one you pick determines the paper that gets produced.
Launch the request from the customer's account record
all five launch from Account — none from Opportunity
Drafting, negotiation, approvals and signature all live over there
Salesforce pulls the workflow back — it is not pushed. The package makes outbound calls to Ironclad and stores what comes back: status, approvers, signers, and a link to the live workflow. Much of that refresh happens when somebody opens the record, which has a consequence worth understanding.
Object map — everything hangs off the Account
Workflow and Contract are separate branches off the Account. Nothing joins a signed contract back to the workflow that produced it.
Three more sit outside the run: Paused, Canceled and Archive.
| Status | What it means |
|---|---|
| Create | Being drafted — nothing has gone to the customer |
| Review | In negotiation, internally or with the counterparty |
| Sign: Not Out for Signature | Ready to send, but nobody has sent it |
| Sign: Out for Signature | Sitting with a signer right now |
| Complete | Fully executed |
| Paused | Deliberately stopped, expected to resume |
| Canceled | Abandoned |
The request, mirrored into Salesforce. Carries the workflow name, its type, its current status, and a Workflow Link that opens the live workflow in Ironclad. Treat the record as a read-only reflection — editing it here changes nothing over there.
One row per internal approver, with their role and where they have got to. This is how you answer "what is it waiting on?" without opening Ironclad.
One row per signer, with name, email and signing status. Covers both sides, so it is the fastest way to see whether you are waiting on the customer or on someone here.
The executed agreement: account, agreement date, contract type, and who signed for the counterparty. It attaches to the Account only — there is no field joining it to the workflow it came from.
Setup, not day-to-day. Five records define the request types that can be launched, all of them from the Account object. Adding a sixth type means adding a configuration record.
Where failed calls between the two systems land. Nobody watches it by default, which is exactly why it is worth watching — a workflow can look fine in Salesforce while its documents never arrived.
Observations from the live org, worth knowing before anybody reports off this data.
| Observation | Why it matters |
|---|---|
| Roughly half of workflows link to no Account or Opportunity | They cannot be found from the customer record at all |
| Only a small minority carry an Opportunity | Contract status is effectively invisible from the deal |
| Contract has no link to its workflow | No trace from signed paper back to how it was negotiated |
| Hundreds of logged API errors | Documents and messages that silently never synced |
| Errors cluster on documents and communications | Not found, unauthorized, and bad request — three distinct causes |
| Launch groups are configured but unused | A feature switched on and never adopted |
Every workflow record here is a copy of something living in Ironclad, fetched by Salesforce. If the two disagree, Ironclad wins — and the Salesforce side is the one likely to be out of date. Editing the record here sends nothing back; use the Workflow Link and work in the real system.
All five request types are configured against the Account. Starting a contract any other way — in Ironclad directly, or from a document somebody emailed — produces a workflow with nothing tying it to the customer, which is where the orphaned records come from.
Documents and messages are fetched by separate calls from the status, and the error log shows failures concentrated on exactly those two. So a workflow can read Complete while the paperwork never came across — and because these are live callouts, a failure at the moment you looked leaves the record short. If the documents matter, check them in Ironclad.
The Approval and Signature rows tell you who the workflow is actually waiting on. Reading them first saves the round of emails that starts with asking the customer for something that is sitting with your own legal team.