Salesforce Flows Integration
Most REDA Financials automation needs no code at all: Flows read and write the accounting objects like any records, posting is a field update, and the package contributes a ready-made action for PDF generation. Here's the declarative toolkit.
The packaged action: "Generate PDF Document"
In the Flow action picker under category REDA Financials: give it a Source Record ID and the Source Object API Name (e.g. refin__Sales_Invoice__c) and it renders, attaches, and returns Success / Content Version ID / Content Document ID / Public URL / Error Message. Bulk-safe in loops. Classic uses: generate on a schedule, attach to your own email flows, produce paper the moment a record-triggered condition hits.
The package ships two invocable actions — this one, and Create E-Invoice Trail under the E-Invoicing category (see Apex Development). A small surface, documented completely. Its self-description: "Generates a PDF for the given source transaction record and attaches it as a File."
| Input | Required | Packaged description (verbatim) |
|---|---|---|
| Source Record ID | Yes | "The Id of the source transaction record (SI, CR, CD, CM, PO)." |
| Source Object API Name | Yes | "Fully qualified API name of the source object (e.g. refin__Sales_Invoice__c)." |
| Output | What you get |
|---|---|
| Success | Per-row true/false — check it before using the other outputs |
| Content Version ID / Content Document ID | The generated file, already attached to the source record as a Salesforce File |
| Public URL | Populated only "if the Entity has Auto Public URL enabled; null otherwise" — the packaged wording says Entity, but the flag the code reads is refin__Auto_Public_URL__c ("Generate Public URL for PDFs") on the document's Territory, resolved document → Entity → Territory — build your email links conditionally |
| Error Message | The reason when Success is false; missing inputs return the verbatim "sourceRecordId and sourceObjectApiName are required." |
Supported source objects — exactly four, plus one special case: refin__Sales_Invoice__c, refin__Cash_Receipt__c, refin__Cash_Disbursement__c, refin__Purchase_Order__c; credit memos are handled as a Sales Invoice type (refin__Sales_Invoice_Type__c), so pass the SI object name for them. In loops the action is genuinely bulk-safe: requests are grouped by object, generated in bulk, and results return in input order — one bad row fails alone with its own Error Message.
refin__Auto_Gen_PDF_Sales_Invoice__c, refin__Auto_Gen_PDF_Cash_Receipt__c, refin__Auto_Gen_PDF_Cash_Disbursement__c, refin__Auto_Gen_PDF_Purchase_Order__c, refin__Auto_Gen_PDF_Credit_Memo__c. If "every posted invoice gets a PDF" is the whole requirement, flip the toggle; reserve the Flow action for conditional or scheduled generation.
refin.PDFGeneratorAPI (and to refin.EInvoiceTrailCreator), so a user with any REDA Financials permission set can run the action. A running user with none of them — a Flow running as a service account, say — still needs the class granted explicitly. Test in a sandbox with the real runtime user before shipping the Flow.
Posting (and more) from Flow
| Flow move | What happens |
|---|---|
Create refin__Sales_Invoice__c + lines (Draft) | Real draft — numbered, defaulted, validated |
Update refin__Status__c → 'Posted' | Full posting engine — tax, WHT, rates, all guards (a refusal faults the Flow with the verbatim message: build a fault path) |
| Create an application record | Applies a receipt/credit with all matching rules |
| Record-triggered Flow on status change | Your notification/integration logic at the accounting moment (fires on UI and API changes alike) |
Set refin__Auto_Apply_Receipt__c = true on a posted receipt | Triggers the auto-apply run for that receipt — flag fields like this are designed Flow touchpoints |
Three Flows worth stealing
- The approval bridge: your custom approval process ends by setting Approval Status to 'Approved' and status to 'Posted' — document flows from request to books, no clicks.
- The big-invoice bell: record-triggered on Sales Invoice, entry condition Status = Posted AND Total > 50,000, action = notify the controller's channel.
- The paper chase: scheduled Flow finds posted invoices missing PDFs (Generated At null), loops them through Generate PDF Document.
A worked Flow at Meridian: the tenant welcome packet
Meridian Properties Group sends every newly posted first invoice with its PDF attached. One record-triggered Flow on refin__Sales_Invoice__c: entry condition Status changed to Posted; a decision checks it's the customer's first posted invoice; the Generate PDF Document action runs with the record's Id and refin__Sales_Invoice__c; a fault-tolerant decision on Success branches — true continues to the email action with the Content Document attached, false logs the Error Message to a case for AP. Total build time: an afternoon, no Apex, upgrade-safe by construction.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| No fault path on the posting update | A closed period faults the whole Flow run — and whatever else it was mid-way through | Every status-update element gets a fault connector routing the verbatim message somewhere a human reads |
| Using the Public URL output unconditionally | It's null unless the document's Territory has Generate Public URL for PDFs enabled — your email template ships a blank link | Branch on the output, or use the Content Document attachment instead |
| Passing a Purchase Invoice to Generate PDF Document | PIs aren't in the supported set (SI, CR, CD, PO, CM-via-SI) — the row fails | Check the supported-objects list; vendor bills don't need customer-facing PDFs |
| Editing posted records from a before-save Flow | Posted documents are locked to everyone — the Flow faults on fields outside the whitelisted workflow set | Restrict same-record edits to Drafts; react to posted records, don't rewrite them |
| Duplicating package automation in your own Flows | Recurring generation, auto-apply, aging snapshots already run on the Operations schedule — a parallel Flow competes with them | Check the Operations tab's twelve cards before building; extend, don't duplicate |
Where to go next
- Streaming API — event-driven counterparts.
- Apex Development on REDA — when Flow runs out of road.
- Operations Scheduler — the automation the package already runs for you.
Frequently asked questions
Working as designed: a posting gate refused (closed period, approval pending, unbalanced…). The fault message is the exact reason; route it to a human or fix the data upstream. Never retry blindly — the gate will hold.
Standard guidance applies: before-save for same-record field tweaks on drafts (posted records are locked anyway), after-save for reactions (notifications, related records). Don't fight the package's own automation — react to final states.
The calculation service is an Apex surface; from Flow, the practical route is creating the draft document (tax previews in the form; amounts finalize at posting). If you truly need raw calculation in Flow, a thin invocable wrapper around GlobalTaxService is a ten-line Apex class — see Apex Development.
Because the objects are the API: creating, updating and status-flipping records covers posting, applying and reacting without bespoke actions. PDF generation and creating an E-Invoice Trail are the two jobs that genuinely needed packaging — everything else is standard Flow on standard records.
Only if you use FX Rate Sync in a multi-currency org: the package writes daily rates through that separately-installed Flow because dated conversion rates exist only when Advanced Currency Management is enabled. If it's missing, the sync tells you verbatim: "The \"Create_Dated_Conversion_Rate\" Flow is not installed. FX Rate Sync requires this Flow to write DatedConversionRate records. Please install the REDA FX Rate Sync component."
Was this article helpful?