Salesforce e-sign with Atlas

Salesforce admins search for e-sign when Opportunity stages should trigger contracts and signed PDFs should land on the Opportunity record. Atlas integrates through REST middleware, custom fields, and webhooks. There is no managed package on AppExchange today.

> Share: "Flow or Apex calls Atlas create. Signed PDF attaches when webhook fires."

Custom fields

Add to Opportunity (or Contract object):

Use namespaced API names in packaging if you ship a managed app later.

Flow-triggered create

Record-triggered Flow when Stage = "Contract Sent":

1. Get Contact email from Opportunity Contact Role
2. Call Apex @InvocableMethod or External Service (OpenAPI import from https://atlaswork.ai/openapi.json)
3. Apex POSTs to Atlas with document_url from ContentDocument or external CDN
4. Flow updates Opportunity with review URL and status Draft

Example Apex callout skeleton:

HttpRequest req = new HttpRequest();
req.setEndpoint('https://atlaswork.ai/api/envelope');
req.setMethod('POST');
req.setHeader('Authorization', 'Bearer ' + atlasApiKey);
req.setHeader('Content-Type', 'application/json');
req.setBody(JSON.serialize(new Map<String, Object>{
  'document_url' => docUrl,
  'webhook_url' => 'https://your-middleware.example/sf/atlas',
  'metadata' => new Map<String, Object>{
    'external_id' => opp.Id,
    'client_reference_id' => opp.Id
  },
  'parties' => new List<Object>{
    new Map<String, Object>{
      'email' => contactEmail,
      'name' => contactName,
      'role' => 'Customer'
    }
  }
}));

Store API key in Named Credential or Protected Custom Setting.

Middleware webhook to Salesforce

Salesforce cannot verify Atlas HMAC on Platform Events without a middleware layer in most setups. Pattern:

Atlas webhook → AWS Lambda / Vercel / Heroku
  → Salesforce REST PATCH Opportunity
  → Files API upload signed PDF
  → Chatter post for owner

On envelope.signed, middleware downloads PDF and uses Salesforce Files Connect or ContentVersion insert.

Human Send step

Ad-hoc Opportunity PDFs should not auto-email signers. Account executives open Atlas_Review_URL__c, confirm fields, click Send. Template NDAs can use POST /api/templates/{id}/send from Flow when legal approved.

Platform mode for SI partners

Agencies managing multiple Salesforce orgs can use Atlas Platform connected accounts. Pass Atlas-Account: ext_... on create from middleware keyed by Salesforce org id.

Comparison to native Salesforce e-sign

Salesforce supports vendor integrations (DocuSign, etc.) with click-to-config. Atlas fits when:

• Developers already use Atlas API or MCP for product signing
• Usage-based pricing beats per-seat e-sign licenses for low-volume enterprise reps
• Agents in Claude prepare contracts that should share the same envelope store

Testing in sandbox

1. Named Credential pointing at Atlas with sandbox API key
2. Test Opportunity with PDF in Files
3. Complete sign on mobile
4. Verify ContentVersion attachment and stage automation

Reporting dashboards

Salesforce reports can group Opportunities by Atlas_Sign_Status__c to show pipeline stuck in "Pending signature." Combine with Atlas webhook timestamps in a middleware warehouse if you need median time-to-sign across reps.

Experience Cloud considerations

If partners sign inside Experience Cloud, you can email Atlas sign links from Flow or display link components. Embedded signing inside Experience Cloud pages redirects to Atlas hosted sign UI unless you build custom iframe hosting with counsel approval.

Dual vendor migration

Enterprises often run DocuSign managed package alongside Atlas API for new SKUs. Store both vendor envelope ids on Opportunity during parallel run. Retire DocuSign fields when webhook parity and archive export complete for each template family.

CPQ and quoting

If Salesforce CPQ generates quote PDFs, pass rendered PDF URL to Atlas create from CPQ completion trigger. Keep quote version id in metadata for reconciliation if buyer requests changes mid-sign.

FAQ

Does Atlas sync Lead to Contact automatically? No. Pass email and name explicitly on create.

Experience Cloud signers? Signers use Atlas hosted sign pages or links you email. Embed is custom.

Sequential signers on Opportunity? Pass multiple parties ordered in JSON. Atlas handles order.

Governor limits? Batch high-volume sends outside synchronous Flow. Use Queueable Apex for callouts.

Credits? Each Send consumes one Atlas credit. Draft create from Flow is free.

Related

• HubSpot document signing
• Stripe webhook after sign
• E-signature API

Extended FAQ

Lightning Flow vs Apex? Flow for simple callouts. Apex when complex party logic or bulk.

Salesforce Shield? Atlas PDFs stored per your middleware attachment strategy, not automatic Shield encryption.

Community Cloud signers? External signers use Atlas links, not Salesforce login.

Governor limits on bulk? Queueable Apex for batches over ten concurrent callouts.

Managed package timeline? No AppExchange package today. Plan custom fields and middleware.

Partner implementation notes

SI partners should prototype with sandbox Opportunity and real mobile sign step before enabling Flow on production pipelines. Salesforce admins often underestimate file size limits on ContentVersion uploads for signed PDFs returned from Atlas middleware. Stream large downloads through middleware instead of embedding base64 in Flow variables.

API reference

Full route list and request schemas live at /dev. Start with E-signature API for the mental model, then use this guide for copy-paste examples.