The problem
Your billing, CPQ, or order-management system generates an event and you want Salesforce to produce a customer-ready document and send it for signature without someone clicking around in Salesforce. The external system can call Salesforce, but you don't want to install packages or write a full integration service. You need an approach that's safe for admins to set up, auditable, and works reliably at scale.
Four practical patterns to trigger DocuGen from another system
Savvy DocuGen can be triggered by a button, a stage change, a field change, or a new file. That gives you four clean integration patterns. Pick the one that fits your external system's capabilities and your risk profile.
1) Field-change trigger — best for simple, reliable automation
Pattern: External system updates a boolean or picklist field on the Opportunity (or Quote, Contract, or a custom object). DocuGen is configured to run when that field changes to the target value.
When to use it: The external system can call Salesforce's REST API and you want the simplest, lowest-friction flow. No human clicks. Works well for single-doc generation per event.
Example scenario: Your billing system marks Opportunity.Generate_Doc__c = true when an order is provisioned. The external system calls Salesforce once per order and DocuGen generates a 60-page Master Services Agreement and sends it for signature to the account contacts.
How to implement (admin-friendly):
- Create a checkbox or picklist field, e.g.
Generate_Doc__c, on Opportunity.
- Configure DocuGen to trigger when
Generate_Doc__c is set to true.
- Have the external system call Salesforce and update that field. A minimal REST call from the external system looks like this (outside of Salesforce):
PATCH /services/data/vXX.0/sobjects/Opportunity/006XXXXXXXXXXXXXXX
Authorization: Bearer <access_token>
Content-Type: application/json
{ "Generate_Doc__c": true }
Notes: DocuGen will run in the same way it does for manual field changes. Make sure the external system clears the checkbox or uses a different field on retries to avoid duplicate runs.
2) Stage-change trigger — best when your external system drives sales stages
Pattern: External system updates Opportunity.StageName (or a similar field) to a specific value you use to mean "ready for contract." DocuGen is set to trigger on that stage.
When to use it: Your external system already maps to Opportunity stages and stage transitions match your document lifecycle. This is visible to sales and simplifies reporting.
Concrete numbers: If you run 200 renewals a month and move Opportunities to "Contract Ready" via an external billing job, DocuGen can pick that up immediately and send each renewal for signature without manual work.
3) New file trigger — best when the external system uploads a generated file into Salesforce
Pattern: External system uploads a file to the Opportunity (Salesforce Files) or creates an Attachment. DocuGen is configured to trigger when a new file appears on the record.
When to use it: Your external system already produces a PDF or Word file and can push it into Salesforce. DocuGen can then pick that file up, merge it into other templates if needed, bundle documents, or send it for signature.
Implementation tip: Files up to 40 MB are supported by DocuGen. Note that Notes & Attachments is capped at 25 MB by Salesforce, so push large documents to Files instead.
4) Button-triggered flow — best when a human needs a final review
Pattern: External system writes a flag or creates a child record. A user in Salesforce clicks a custom button to run DocuGen. This gives a final human review before sending.
When to use it: You want the external system to prepare data but still want a sales rep or contract manager to confirm the content. Use this when legal or sales policy requires a last-minute check.
Implementation considerations
Idempotency and retries
External systems often retry on failures. Build an idempotency pattern: either clear the trigger field after DocuGen runs, use timestamps, or add a small matching key like DocRunKey__c so repeated writes don't cause duplicate signature runs.
Who signs and verification
DocuGen sends for signature through your Circularo account and writes the signed PDF back to the same record. Set the signing workflow in DocuGen to match your verifier requirements — for example require a one-time code for signer identity and store signer passwords on the Contact record if needed.
Bulk volume and monitoring
If you expect bursts — say hundreds of renewals in a day — run some tests in your sandbox (DocuGen works in sandboxes exactly as in production) and check how your external system batches updates. Sending 200 separate updates that each trigger signing runs is fine, but watch notification volumes and queuing in Circularo if lots of signers are involved at once.
Security and authentication
The external system must authenticate to Salesforce to update fields or upload files. Use a named integration user with the minimal profile necessary, or OAuth connected app with a scoped integration user. From Savvy DocuGen's side there is no managed package to install and it connects through an authorised connection, so there's nothing for your security team to review inside the org.
Example end-to-end (hypothetical)
Imagine your order system finalises 250 renewals a month. On success it calls Salesforce and sets Opportunity.Renewal_Generate__c = true. DocuGen is configured to trigger on that field, uses a template that pulls Opportunity, Account, and the related Contract line items as repeating rows, bundles that with a terms PDF, sends to contacts via Circularo, and files the signed PDF back to the Opportunity. The whole flow needs no clicks from sales and the signed document is available on the record for finance and legal.
Next steps
Pick the pattern that matches your external system's abilities. If you can update a field, start there—it's the easiest and safest to operate. Test the flow in a sandbox (DocuGen behaves the same there) and include idempotency keys for retries. Savvy DocuGen will fill templates from your records, send through your Circularo account, and write the signed PDF back to the record.
Try it in a sandbox today: configure a field-change or stage-change trigger and have your external system update an Opportunity to see a full generate-and-sign run end-to-end.
Read next