AppExchange Integrations
Running your ERP on Salesforce has a compounding advantage: the rest of your stack probably already connects to Salesforce. CRM, payment processors, expense tools, e-signature, document management — AppExchange integrations land in the same org as your books, and "integrating with REDA Financials" usually reduces to ordinary record mappings.
The natural fits
| Category | Integration shape |
|---|---|
| CRM (native!) | The same Account records ARE your customers and vendors — opportunity-to-invoice is a Flow, not an interface file. The original reason finance-on-Salesforce wins. |
| Payment processors | Processor apps that write payment records → map settlements to Cash Receipts (auto-apply does the matching); payout batches reconcile like any bank line. |
| Expense management | Approved expense reports → Expense-type Purchase Invoices via Flow or API — born settled, correctly booked. |
| Bank feeds / e-invoicing | First-class extension contracts rather than generic integrations. |
| E-signature / document tools | Files and links on the same records — a signed lease beside the recurring invoice template it authorizes. |
Evaluating any app against your books — the four questions
- Where does money enter the ledger? Every integration that "creates financial data" should end in REDA documents (invoices, receipts, journals) posted through the normal engine — never direct writes to accounting transactions.
- Who is the integration user and what set do they hold? The packaged permission sets govern API writes exactly as UI writes — an app posting AP documents needs the AP set, and gets the AP guardrails.
- What happens on failure? Posting gates refuse bad data with clear messages — the app must surface them, not swallow them.
- Does it respect the locks? Posted-document immutability, closed periods, reconciled-record protection — a well-behaved app treats a refusal as an answer.
What your security review will find
When the security team audits the org before approving a new app alongside REDA Financials, here is the package's complete outbound footprint — small enough to memorise:
| Item | What ships | What it's for |
|---|---|---|
Remote site OCR_API | See Remote Site Settings in your org | REDA's AI service endpoint for REDA Financials AI features (OCR, Bank Reconciliation) — unrelated to the separate REDA AI product |
Remote site Open_Exchange_Rates | See Remote Site Settings in your org | Open Exchange Rates API for automated daily FX rate sync into DatedConversionRate, via an internal package service |
| Named credentials | None | — |
| Connected apps | None | — |
| Inbound webhooks / custom REST endpoints | None | — |
Everything else talking to your org — the payment app's callbacks, the middleware's OAuth — belongs to those apps and to your org's own configuration, governed by your policies. That separation is what makes the review tractable: REDA's own surface never grows because you installed something next to it.
Provisioning the integration user
| The app does… | Grant this packaged permission set |
|---|---|
| Creates and posts customer documents (invoicing, payments in) | Accounts Receivable v2 |
| Creates and posts vendor documents (bills, payments out) | Accounts Payable v2 |
| Reads financial data for reporting/BI | Read Only v2 |
| Journal-level interfaces (payroll, consolidation) | Accounting Controller v2 |
| Administers configuration programmatically | Accounting Admin v2 — sparingly, and only when genuinely needed |
Use the v2 sets. From version 1.610 they are the ones to assign, and the only ones that can be assigned to a user on a Salesforce Platform licence; the unsuffixed v1 sets are deprecated. Add a REDA licence seat for any user that writes accounting documents — the licence check applies to API writes exactly as to humans. One app, one user, one set: shared "integration" logins across apps make every audit question unanswerable.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Letting an app write "financial records" into its own objects only | Money exists in the app but not in your books — the ledger goes blind to it | Insist the integration ends in posted REDA documents; the app's records can link to them |
| Granting the integration user Accounting Admin "to be safe" | Every app failure now has configuration-level blast radius | The narrowest packaged set that does the job; escalate only on evidence |
| Skipping the Reference mapping | No idempotency key, no reconciliation trail back to the source system | Map the app's transaction identifier into Reference on every document it creates |
| Assuming the app "handles accounting" because it posts successfully | Posting proves data validity, not accounting policy — wrong GL mappings post fine | Have the controller review the app's document mapping (GLs, entities, tax) before go-live, then spot-check monthly |
Where to go next
- REST API for Accounting Data — the mechanics under most apps.
- Extension Packages — the built-for-purpose contracts.
- API Overview — the whole map, one page.
Frequently asked questions
The classic journal interface: payroll system exports the summary, a scheduled job (or the JE form's CSV upload, for the manual version) creates the monthly journal. Recurring templates handle the fixed accrual pattern between runs.
The durable answer is the architecture: anything that writes clean drafts through the API integrates well. For current partner apps and provider extensions, ask REDA — ecosystems move faster than manuals.
Both work — middleware speaks the same REST/Bulk APIs. Choose by your team's operating model; the REDA-side pattern (draft → post → events) is identical either way.
The package's triggers and guards run on every write regardless of who writes — another app can't switch them off, and there is no bypass flag for it to find. What can collide is business logic: two systems both creating receipts for the same payments, say. That's an integration-design question, not a platform risk.
They're the special case with first-class contracts: instead of generic record mapping, providers implement refin.BankFeedProvider or refin.EInvoiceProvider and register in a setup record. See Extension Packages — evaluating those apps starts from the contract, not the four questions above.
Was this article helpful?