Docusign IAM Now Native in Salesforce: What Changes

Docusign Intelligent Agreement Management (IAM) is now built directly into Salesforce, Agentforce, and Slack, Docusign and Salesforce announced on October 13, 2026. Sales teams can now generate, send, and track agreements from inside the standard Salesforce object model instead of through a bolt-on connector, and Agentforce can trigger those same workflows as an agent action. For teams that already built a custom Docusign-to-Salesforce bridge, the practical question isn't whether to adopt native IAM, it's where the native flow stops and your integration still has to pick up the work.

What did Docusign and Salesforce actually announce?

The October 13, 2026 announcement brings the Docusign IAM platform natively into Salesforce, Agentforce, and Slack, replacing the older model where Docusign lived mostly as an installed package sitting alongside Salesforce data. This is the shipped version of a roadmap item Docusign had publicly listed for months: CRM integrations in IAM for Sales, filed under "Platform Services & Extensibility," which promised to bring IAM "directly into Salesforce and Dynamics 365" so teams could "generate contracts, trigger approval workflows" without leaving the CRM.

Docusign was also named a 2027 Salesforce Global Partner of the Year alongside the launch, which tells you this isn't a side integration Docusign is quietly maintaining, it's a flagship part of the partnership going forward.

Two other pieces of context matter for anyone deciding whether to touch their existing setup:

• Docusign made its MCP server generally available to every AI agent on September 30, 2026, so Agentforce calling into Docusign isn't an isolated Salesforce feature, it's part of the same agent-facing surface Claude, ChatGPT, and Copilot use.
• Docusign shipped Connected Forms as an early access feature in its October 8, 2026 Admin release, the same week as the Salesforce news, which points to agreement intake (not just signature) becoming a bigger part of what "native" means going forward.

How is native IAM different from the old Docusign for Salesforce connector?

The old model (and the "IAM for Sales" beta that preceded this launch) typically shipped as a pre-built solution package: a set of installable workflows and document templates mapped to Salesforce's standard sales objects. You installed it, configured it against your org, and it worked well for the contract-to-close motion most B2B sales teams run.

The native version removes most of that install-and-configure step for the common case. Agreement generation, sending, and status now live close enough to the CRM record that a rep (or Agentforce, acting on the rep's behalf) can pull up expired contracts, summarize terms, and kick off a new agreement without leaving Salesforce. That's a real simplification for anyone running a standard sales process on Salesforce's default objects.

What hasn't changed is the underlying mechanism: Docusign still exposes this functionality through the same category of pre-built workflows and templates it always has for IAM for Sales, just with tighter native plumbing and an Agentforce action layer on top. That distinction matters once your Salesforce org has grown past the standard objects.

What does native IAM cover out of the box?

Based on the announcement and Docusign's own "IAM for Sales" documentation, the native integration is built to handle:

• Generating and sending agreements tied to standard Salesforce objects (Accounts, Opportunities, Contacts)
• Triggering approval workflows as part of a deal's progression through the pipeline
• Surfacing agreement status and renewal dates back into the CRM record
• Letting Agentforce act on agreements conversationally (find expiring contracts, summarize terms, send a renewal) as part of the broader Salesforce-Slack-Agentforce surface

If your Salesforce instance runs a mostly out-of-the-box sales process, this is a genuine win: less custom plumbing to build and maintain, and one less connector your team has to patch when Salesforce or Docusign ship an API change.

Where does native IAM still need an integration layer?

This is the part the press release doesn't spell out, and it's where most of the real engineering work in a Docusign-Salesforce rollout actually lives. Docusign's own agreement-automation research found that companies integrating agreement management with CRM platforms like Salesforce beat their financial goals more often than peers who don't, but that research is about having the integration at all, not about every integration pattern being covered by the native package.

Three situations still point back to the Docusign Agreement Manager API or a custom extension app, rather than the native flow, based on how Docusign has scoped IAM for Sales to date:

Custom objects. If your agreement needs to key off something that isn't a standard Account, Opportunity, or Contact, for example a custom "Renewal Request" object, a partner-specific pricing object, or a multi-entity contract record, the pre-built templates aren't built around it. (Note: Docusign has not published a definitive list of unsupported objects for the native launch, so treat this as an architectural expectation based on how the IAM for Sales solution package has always worked, not a confirmed restriction.)

Non-standard approval chains. The native workflows map to a conventional deal-approval path. If your org routes approval through a legal review queue, a finance threshold check, or a multi-region sign-off sequence that doesn't match Salesforce's default approval process, you're extending or replacing the native workflow, not configuring it.

Cross-org agreement visibility. If agreements need to be visible or triggerable from systems outside the Salesforce org the native package was installed into (a separate Salesforce instance after an acquisition, an ERP, a vertical SaaS tool), native IAM's visibility stops at the org boundary. That's an API and webhook problem, which is the same category of work our guide to integrating Docusign with Salesforce, SAP, and enterprise systems walks through.

Native IAM vs. a custom integration: which do you need?

Your situation	What to use
Standard sales objects, conventional approval path	Native IAM for Sales, out of the box
Custom Salesforce objects drive the agreement	Agreement Manager API or an extension app
Approval routing doesn't match Salesforce defaults	Custom workflow logic on top of IAM
Agreements need to be triggered from outside Salesforce (another CRM, an ERP, a portal)	Webhook-based integration, see Baton for reliable Docusign-triggering patterns
You're an ISV building a packaged Docusign experience for your own app	Docusign App Center extension app, not a reliance on IAM for Sales

What this means if you already built a custom Docusign-Salesforce bridge

Don't rip it out reflexively. Audit it against the three situations above first. If your bridge exists purely to recreate "generate an agreement when an Opportunity closes," you can likely retire that piece in favor of the native flow and redirect the engineering time elsewhere. If your bridge exists because of a custom object, a non-standard approval chain, or because agreements need to be visible from a second system, that logic is still yours to own. Native IAM didn't just get more convenient for the standard case, it also made the line between "standard" and "custom" sharper, which makes it easier to decide what to keep.

For teams weighing a full Docusign IAM implementation against native Salesforce features, the honest framing is: native IAM for Sales is the default now for standard contract-to-close flows, and everything outside that default is still an integration project, API work, or an extension app, same as before this announcement.

FAQ

Does Docusign IAM for Salesforce replace Docusign's old Salesforce connector? For standard sales processes built on Accounts, Opportunities, and Contacts, yes, the native integration announced October 13, 2026 is designed to cover that case without a separately managed connector.

Can Agentforce trigger Docusign workflows directly? Yes. The announcement describes Agentforce acting on agreements, for example finding expiring contracts or sending a renewal, as part of the same native integration, consistent with Docusign making its MCP server generally available to agents the month before.

Does native IAM support custom Salesforce objects? Docusign has not published a confirmed list of what's out of scope for the native launch (unverified), but IAM for Sales has historically shipped as a pre-built package of templates mapped to standard objects. Treat custom-object workflows as integration work via the Agreement Manager API until Docusign documents otherwise.

Do I still need Docusign Connect or a webhook relay if I use native IAM? Only if you need agreement events visible or actionable outside the Salesforce org the native package lives in. Inside that org, native IAM handles its own event flow. Across orgs or into other systems, you're back to Docusign's Connect webhooks or a managed relay layer.

Next step

If you're deciding whether your existing Docusign-Salesforce setup can retire in favor of native IAM, or whether a custom object or approval chain means you still need an integration layer, talk to the fluidlabs team about a working session to map your current setup against what native IAM actually covers.