How to Use Salesforce Flow to Trigger Document Generation Automatically

Even when a team has document generation set up, a rep still has to click a button. When an Opportunity closes at 6pm on Friday, that contract doesn’t go out until Monday morning when someone clicks Generate. That’s not a document generation problem anymore, it’s a timing problem, and it’s the kind of small gap that costs deals momentum right when momentum matters most. Salesforce Flow document generation removes that last manual step entirely. This post covers when to use Flow versus a Quick Action, the most common use cases worth automating, and a step-by-step build for the most common trigger of all: Opportunity stage changes to Closed Won. 

When to Use Flow vs a Quick Action for Document Generation 

Not every document should generate automatically, and knowing which approach fits which situation matters more than defaulting to full automation everywhere. 

Quick Action makes sense when a rep needs to choose a template or review details before generating, keeping a human deliberately in the loop. A sales rep preparing a custom proposal, where deal terms vary enough that someone should confirm the right template and pricing before the document goes out, is a clean example. The click isn’t friction here, it’s a checkpoint that’s actually doing something useful. 

Flow is the right call when generation should happen automatically the moment a condition is met, with zero rep action required. An Opportunity moving to Closed Won is the clearest example: the deal is done, the terms are locked, and there’s no reason a document should wait for someone to remember to click a button. 

URL Button sits in between, one click with pre-configured settings, but still requiring a human to actually press it. A support rep generating a resolution summary at the end of a call is a good fit here, fast and simple, but still tied to a specific moment a person is present for. 

Use Cases for Flow-Triggered Document Generation 

A handful of triggers cover most of what teams actually automate. An Opportunity stage changing to Closed Won is the classic case, a contract generates and emails to the customer the moment the deal closes, no waiting for Monday morning. 

A new Contact record being created can trigger a welcome letter automatically, useful for onboarding flows where the first touchpoint should be immediate rather than whenever someone gets to it. A Case status changing to Resolved can generate a resolution summary and attach it directly to the record, giving support teams a clean, automatic paper trail without extra admin work. 

A custom object field updating to Approved, common in procurement or contract workflows, can trigger an agreement to generate and route out for signature the instant approval happens. And a Scheduled Flow running at month-end can generate invoices for every active subscription record in one batch, which is exactly the kind of high-volume, repetitive task Flow is built to remove from a human’s plate entirely. 

How Flow Calls 360 InstantDocs to Generate a Document 

The mechanism itself is simple once you understand the shape of it. 360 InstantDocs exposes an Invocable Action that Salesforce Flow can call directly, the same way Flow calls any other native or custom action. 

The Flow passes four parameters into that action: templateId, identifying which template to use; parentRecordId, the specific Salesforce record the document should pull data from; parentObjectName, the object that record belongs to; and documentType, specifying whether the output should be a PDF or a Word file. 360 InstantDocs takes those four inputs, generates the document, and saves it directly to the record. No code, no Apex, no developer required anywhere in that chain, it’s entirely configurable inside Flow Builder. 

Step-by-Step Building a Flow to Generate a Document When an Opportunity Closes 

This is the most detailed section, and it’s worth following closely. Every step below should be reproducible in your own Salesforce org, ideally starting in a sandbox before touching production. 

Step 1: Create a new Record-Triggered Flow on the Opportunity object. Start from Flow Builder, choose Record-Triggered Flow, and set the object to Opportunity. 

Step 2: Set the trigger to “A record is updated” when Stage changes to Closed Won. This ensures the Flow only fires on the specific transition that matters, not every time an Opportunity record is touched. 

Step 3: Add a Get Records element to retrieve the Template record ID for the contract template. This pulls the correct templateId dynamically, rather than hardcoding it, which matters if you’re managing multiple contract templates across different deal types. 

Step 4: Add an Action element, searching for Create Document Manager or createDocumentManagers. This is the Invocable Action exposed by 360 InstantDocs, and it should appear in the Action search results once the package is installed and configured. 

Step 5: Map input parameters. Set templateId from the Get Records result in Step 3, parentRecordId to the Opportunity Id from the triggering record, parentObjectName to Opportunity, and documentType to Pdf. 

Step 6: Optionally add a second Action to send an email with the generated document attached. This step is covered in more detail in the next section, but it can be added directly here in the same Flow. 

Step 7: Save and activate the Flow. Give it a clear, descriptive name, something like “Opportunity Closed Won – Contract Generation,” so it’s easy to identify later in a list of active Flows. 

Step 8: Test by updating an Opportunity stage on a sandbox record. Move a test Opportunity to Closed Won, confirm the document generates correctly, and check that it attaches to the record as expected before considering the Flow production-ready. 

Adding Email Delivery to the Flow 

Generating the document is only half the value. Adding an email action right after the generate action means the document delivers to the Opportunity’s contact automatically, the moment it’s created, with no separate manual send required. 

This second action typically uses Flow’s built-in email composer, referencing the document that was just generated as an attachment, along with the contact’s email address pulled from the Opportunity’s related Contact record. Subject line and body can be static or dynamically built using merge fields from the Opportunity itself, the contact’s name, deal amount, and close date, so the email reads as personalized rather than generic. Once configured, this second action runs in the same Flow, right after generation, so the whole sequence, generate then send, happens as one continuous automated step with no gap in between. 

Scheduled Flows for Bulk Document Generation 

Not every use case is triggered by a single record changing. Monthly invoicing is the clearest example of a workload that fits a different pattern entirely: a Scheduled Flow runs on the first of each month, queries all active subscription records at once, and calls the document generation action for each one in a loop. 

This is where the Invocable Action’s support for bulk input becomes genuinely useful. Rather than firing the action once per record in a slow, sequential pattern, a properly built Scheduled Flow can pass a batch of records through in a way that processes efficiently, generating invoices for dozens or hundreds of active subscriptions in a single scheduled run rather than requiring a separate trigger for each one. 

Common Errors and How to Fix Them 

A few issues come up often enough to call out directly. If templateId is blank, the Get Records element likely didn’t find an active template for that object, usually because the template is still in draft status or the filter criteria in the Get Records element don’t match what’s actually stored on the Template record. 

If generation fails silently, check the errorMessage output variable from the Invocable Action. Flow won’t always surface a visible error on its own, so it’s worth explicitly checking that output variable and logging or displaying it during testing rather than assuming success just because the Flow didn’t throw a visible fault. 

If the document isn’t appearing on the record, double-check that parentRecordId and parentObjectName were passed correctly and match each other, a mismatched object name against a valid record Id is one of the more common configuration mistakes, and it tends to fail quietly rather than with an obvious error.