Trigger Document Generation From Salesforce Flow: A Clean API Pattern

The wrong shape: per-template Apex classes

It is common to see a separate Apex class per template: GenerateProposalPDF, GenerateInvoicePDF, GenerateNDA. Each one duplicates logic and drifts. Admins cannot wire any of them into a Flow without dev help.

The right shape is one stable, well-documented Flow-callable action plus an Apex API that takes template ID and source record ID as inputs. Everything else is configuration.

The action interface that Flow loves

• Input: templateId, sourceRecordId, options map (locale, currency override, attach mode).
• Output: documentId, contentVersionId, fileUrl, status, errorMessage.
• Bulk-friendly: accepts a list and returns a list, so screen-flow and record-triggered flows both work.
• Idempotent: same template + record + run key returns the same document; safe to retry.

Patterns Flow admins use

1. Quick action on Opportunity: screen flow with template picker → invoke action → show success.
2. Record-triggered: when stage = "Closed Won," generate the welcome packet.
3. Scheduled flow: monthly statement generation for active accounts.
4. Sub-flow in larger automation: contract → e-sign → onboarding email all chained.

Where Apex API stays in the picture

• Apex triggers and asynchronous jobs needing precise control.
• Integration code in managed packages.
• Complex batch jobs that need governor-limit-aware patterns.
• External-system callbacks (webhook receivers) that fan back into Salesforce.

Authentication, permissions, and named credentials

The action must run under the user's permissions (CRUD/FLS on source records) and respect sharing rules. Named credentials handle the external generator endpoint—no hardcoded secrets. Permission sets gate who can invoke the action; specific templates can have stricter permission scoping.

Error handling that admins can debug

• Structured error codes (TEMPLATE_NOT_FOUND, FIELD_MAPPING_INVALID, SOURCE_RECORD_MISSING_FIELD) with human messages.
• Optional fault path in Flow with the error message to display to the user.
• Generator audit log written to a custom object regardless of success/fail.
• Retry semantics documented: which errors are transient (retry) vs permanent (escalate).

Testing the Flow path

1. Unit tests for the invocable action with mocked generator endpoint.
2. Flow tests with sample data sets covering success and failure paths.
3. Sandbox integration test against the real generator.
4. Performance test with bulk inputs (200 records in one invocation).

The reusability benefit, with numbers

Before: 12 templates × 8 hours of dev per template change = 96 dev hours per quarter spent on layout tweaks. After: one stable API + admins editing visual templates → dev hours drop to near zero for layout changes; dev focuses on real business logic.

Where DocForge for Salesforce fits

DocForge for Salesforce ships a Flow-callable invocable action with the interface above, a documented Apex API, structured errors, idempotency, and bulk support. Sign in and wire your first record-triggered flow in a sandbox.