Sandbox Testing Guide
A sandbox is a fully isolated copy of your Salesforce environment (Developer sandboxes are included with most Salesforce editions) — the perfect place to install REDA Financials, learn the workflows, and prove your configuration before a single real transaction is posted. Testing in a sandbox first is the biggest single thing you can do to make your go-live calm and predictable. This guide shows you how.
Access you'll need. Creating and refreshing sandboxes is a Salesforce System Administrator task (the “Manage Sandboxes” permission). Once inside a sandbox, rehearsing the setup needs the same Accounting Admin v2 permission set you would use in production.
Choose the right sandbox
Salesforce offers several sandbox types. For a REDA Financials rehearsal, any of them works — the difference is how much production data they contain.
| Sandbox type | What it contains | Best for |
|---|---|---|
| Developer | Your configuration and code, with no production records. You add your own test data. | A clean install-and-configure rehearsal. |
| Developer Pro | Same as Developer, with more storage for test data. | Hands-on training and broader testing. |
| Partial Copy | Your configuration plus a sample of production data. | Testing against some real customers, vendors, and accounts. |
| Full | A complete copy of your production org, data and all. | Final user-acceptance testing with realistic data volumes. |
Set up REDA in your sandbox
- Install the package. Install REDA Financials into the sandbox just as you would anywhere else — see Installation & Upgrades.
- Everyone can test during the free trial. While your free trial is active, every user in the org is automatically licensed to post — no licence assignment needed. Your whole team can jump in and try things straight away.
- Configure the foundation. Seed your chart of accounts and tax packs, set your defaults, create a test entity and territory, and generate periods — the same steps as Post-Installation Setup. This is also your rehearsal of the setup itself.
- Add representative test data. Create a couple of test customers, vendors, products, and a bank account so you can run real-looking transactions.
Build your test plan
The golden rule: post at least one transaction through every module you use, then inspect where it landed in the ledger. Work through the cycles that matter to your business:
- Receivables. Create and post a sales invoice, record a cash receipt, apply it, and issue a credit memo. Check the customer balance and aging.
- Payables. Raise a purchase order, turn it into a purchase invoice, match and post it, then pay it with a cash disbursement.
- Journals. Post a manual journal entry and, if you run multiple entities, an intercompany one — and confirm the automatic offsets.
- Banking. Import a sample statement and run a reconciliation from start to finish.
- Assets. If you track fixed assets, run a depreciation batch and confirm the entries.
- Tax & withholding. Post a transaction in each country you operate in and confirm the tax and WHT lines.
- Period close. Walk a full month-end close once, so the real one holds no surprises.
Verify the accounting
Posting a transaction is only half the test — the other half is confirming it accounted for it correctly. For each test, check:
- The GL postings are right. Open the accounting transactions (or the GL Account Ledger) and confirm each debit and credit hit the account you expected.
- Tax and withholding are correct. Confirm the rates, the tax accounts, and any withholding lines.
- Multi-currency works. If you run more than one currency, check the conversions and the FX gain/loss.
- The statements balance. Run the Trial Balance, Income Statement, Balance Sheet, and aging reports and confirm they are correct and tie out.
- Documents look right. Generate invoices, checks, and statements as PDFs and confirm the branding and details.
Keep the sandbox safe
A sandbox feels real, so take a few precautions to keep your testing from leaking into the real world:
- Keep Salesforce email deliverability set to System email only in the sandbox (the default after a refresh) so test invoices and notifications never email your real customers.
- Use clearly fake customers, vendors, and amounts — not live ones — for anything that generates a document.
- Do not connect real bank feeds or process real payments from a sandbox.
- Remember the OCR inbox: send only test documents to it, never real vendor bills you also process in production.
Customising & extending REDA
REDA Financials AI is a fully extensible application. Because it is built natively on Salesforce, you can tailor it extensively to how your business works — add custom fields and objects, build flows and validation rules, create your own reports and dashboards, add Lightning components, and connect integrations. REDA is designed for this: configuration-driven extension points let you add your own accounting dimensions, form fields, and document columns, often without any code.
That flexibility is powerful, so use it through a safe, repeatable path — the same sandbox-first discipline as the rest of this guide:
- Build the change in a sandbox. Make every customization — a new field, a flow, an integration — in a sandbox, never directly in production.
- Test it completely. Run the customization through a proper test plan and write down your test cases, so you and your auditors have a record that it behaves correctly.
- Release to production. Once your test cases pass, deploy the change to production using your team’s preferred method (change sets, a package, or a deployment tool).
- Complete your post-deployment steps. After deploying, verify the change in production, re-run your key checks, and confirm nothing else was affected.
From sandbox to production
With your sandbox testing signed off, move to production using the Go-Live Checklist. Because you have already walked every step once, the production setup is faster and far less error-prone.
Where to go next
- Installation & Upgrades — install the package into your sandbox.
- Your Setup Roadmap — what to configure and test, in order.
- Go-Live Checklist — promote from sandbox to production.
- Opening Balances Migration — rehearse the data load first.
- Segregation of Duties & Security — test your access model safely.
Frequently asked questions
Not during the free trial. While the trial is active, every user in the org is automatically licensed to post, so you and your team can test freely. The licence key becomes relevant when you move to a paid subscription. See Subscription & Plans.
A Developer Pro or Partial Copy sandbox suits most go-lives — enough room to configure and run every cycle. Use a Full sandbox for final user-acceptance testing with production-scale data.
No. A sandbox and production are separate environments, so your entities, seeded accounts, tax rules, and defaults stay in the sandbox. You repeat the configuration in production when you go live — which is quick, because you have already rehearsed it.
Salesforce sets sandbox email deliverability to System email only by default, which blocks outbound email to real recipients. Leave it that way while testing. Always use clearly fake data for anything that generates a document, just to be safe.
Yes — REDA Financials is fully extensible, and you can tailor it extensively to your business. Build and test every customization in a sandbox first, then release it to production and complete your post-deployment checks. Note that customizations you build are owned by you and are not covered by REDA’s standard general support — REDA supports the packaged app. For help building an extension, contact support@reda.one.
Post at least one transaction through every module you use — receivables, payables, journals, banking, assets — and confirm each one posted to the correct GL accounts. Then run your financial statements and a full month-end close. If those are right, you are in good shape.
Was this article helpful?