Salesforce deal context in Draft templates, now in beta

Draft can now read deal context from Salesforce. Starting today, tenants on Draft 3.9 can connect an opportunity to a template and have the deal-point form pre-filled from CRM fields, with the source of each value shown beside it. This is a beta. Below is what changed, why we built it this way, what to watch for and what it does not yet do.

What changed

The deal-point form, introduced in Draft 3.6, is the structured intake a drafter completes before Draft composes a document: parties, term, territory, payment terms, liability tier, governing law, and the practice-specific points the firm’s template defines. Until now the form was filled by hand or from a previous draft.

With the beta enabled, a drafter opening a template can select a Salesforce opportunity. Draft reads a configured set of fields from that opportunity and its related account, and populates the matching form fields. Each pre-filled value shows a small source marker: the Salesforce object, the field name and the time it was read. The drafter can accept, edit or clear each value. Nothing is composed until the drafter confirms the form.

Field mapping is configured by an administrator, once per template. A typical mapping covers counterparty legal name, counterparty address, deal value, currency, contract term, territory and the account owner. Firms can map custom Salesforce fields to custom deal points.

Playbook thresholds that depend on deal value now resolve automatically. If the firm’s playbook sets the liability cap at a multiple of annual fees above one threshold and a fixed sum below it, the correct tier is selected from the mapped deal value, and the citation on the resulting clause shows both the playbook rule and the Salesforce field that triggered it.

Why

The deal-point form was built on the premise that boilerplate should write itself and lawyers should spend their time on the points that are actually negotiated. In practice, the form was being filled from information that already existed in the CRM, by someone copying it across, with the predictable errors: last year’s deal value, the trading name instead of the legal entity, the wrong currency. The composed draft then inherited the error with a citation attached, which made it look authoritative.

Reading from the source removes the copying step. Showing the source beside each value keeps the drafter responsible for checking it, which matters because the CRM is frequently wrong in ways the drafter is well placed to catch.

The integration is also read-only. The beta does not write anything back to Salesforce. We considered it and decided against for the beta on three grounds. Draft’s output is a legal document and the CRM is a sales record; the direction of authority should run from the executed contract to the CRM, not from a first draft. Write-back introduces a second integration surface with its own permission model. And several firms told us plainly that they would not enable the integration if it could modify CRM data.

We are testing a narrow write-back that records only “draft generated” with a link, as an activity on the opportunity, and nothing else. It is not in this beta.

What to watch for

Legal entity versus account name. Salesforce account names are often trading names. The mapping should point at a field that holds the legal entity name, and the firm should confirm that field is maintained. Draft flags a Note where the mapped party name does not match the pattern of a registered entity name for the counterparty’s jurisdiction, but this catches obvious cases only.

Currency and value. Deal value is read with its currency field. Where the opportunity currency differs from the template’s default, Draft prompts the drafter rather than converting. Where the value is in a field that holds annualised rather than total contract value, the playbook tier can resolve incorrectly; the mapping screen asks the administrator to confirm which it is.

Stale data. The source marker shows when the value was read. Draft reads at form-open time and does not refresh during the session. If the opportunity changes while the form is open, the drafter will not see it until the template is reopened.

Permissions. The integration uses a Salesforce connected app with read access scoped to opportunities and accounts. Users see only values from opportunities they could open in Salesforce themselves. Where a drafter lacks access to the selected opportunity, the form shows no pre-filled values and says why.

Known limitations

One opportunity per draft; multi-opportunity bundles must be handled manually. Related objects beyond account and opportunity, such as quotes or contacts, are not read in this beta. Salesforce sandboxes are supported for testing but a tenant can connect to one production org only. Field mapping does not yet support formula fields or fields on custom objects more than one relationship away from the opportunity. Templates in languages other than English pre-fill correctly but the source markers are shown in English. And the integration is not available in air-gap mode, for the obvious reason.

Enabling the beta

An administrator connects the Salesforce org from the integrations page, authorises the connected app, and configures a mapping for at least one template. Drafters then see an “import from Salesforce” option when opening that template. The beta is expected to run until early 2027.

Start with one template and the deal points the CRM actually gets right. Expand the mapping once the drafters stop correcting the pre-filled values.