Testing REDA in a Sandbox

Q: I ran a manual job twice and got an error.

Only one run of a job executes at a time. REDA responds: "A similar job is currently in process. Please wait for the existing job to be complete prior to initiating a new job. Contact your system admin for further assistance." Wait for the first run to finish, then retry.

Q: Can I reset a test lease and start over?

Yes, if it isn't occupied. Reset Lease deletes the lease's charges, tickets, and invoices and returns it to the application stage. An occupied lease refuses: "Occupied Lease can not be reset. Please contact your System administrator."

Admin 8 min read Updated July 2026

A sandbox is a full copy of your Salesforce org that you can break safely — the right place to rehearse a configuration change, a new leasing rule, or an upgrade before it touches production. Because REDA has no way to switch its automation off during data work, a change that looks small can cascade widely, which is exactly why you try it in a sandbox first. This guide is about the REDA-specific parts of that: the org-local state you must re-check in every fresh or refreshed sandbox, the minimum set of background jobs to schedule so a test actually runs, and the reset and delete-guard realities you'll meet. The platform mechanics of sandboxes — types, refresh cadence, how data copies — are standard Salesforce, so we point you to the official documentation for those.

Getting there. Sandboxes are created in Salesforce Setup (standard platform feature). Inside a sandbox, REDA navigation is identical: App Launcher → REDA or REDA Admin.
Access you'll need. Creating and refreshing sandboxes is a Salesforce administrator task. Inside the sandbox, the same REDA permission sets apply — they copy with the org — so the REDA Admin Console still requires REDA - Master Data - Admin.

REDA has no trigger bypass. Data loads and configuration changes fire all of REDA's automation, just as manual work does. That makes production experiments genuinely risky — and it's the whole reason to rehearse a change in a sandbox first, where you can watch what the automation does before you commit to it.

Why test in a sandbox

Two kinds of change earn a sandbox rehearsal every time:

Leasing Rule edits. Editing a Leasing Rule re-copies its settings onto every active lease governed by that rule — overwriting manual tweaks in the process. That's a wide, hard-to-undo blast radius, so a sandbox is where you learn which fields move before you touch production.
Upgrade rehearsal. A new REDA release lands in a sandbox first. Rehearse the upgrade there — confirm your jobs, settings, and integrations still behave — before you upgrade production.

Charge and billing-policy changes (recurring-invoice windows, late-fee and month-to-month parameters) and flow-deactivation experiments belong here too, for the same reason: you get to see the side effects in a place where they don't matter.

REDA state to re-check in every sandbox

A sandbox copies your org, but several pieces of REDA state are per-org — they don't reliably survive a copy or refresh, and a sandbox will happily run with whatever it inherited or lost. Run this checklist against every fresh or refreshed sandbox before you trust a test:

Check	Where	Why it matters
Scheduled jobs present for what you're testing	REDA Admin Console → Scheduled Jobs	Schedules are per-org admin state — nothing is guaranteed to be present.
Accounting extension setting	REDA Admin Console → Global App Settings	An org-local setting; it decides whether invoices sync to REDA Financials during your test.
Multi-currency setting	Global App Settings	The master gate for currency-stamping behavior.
Data Service disabled or re-keyed	Data Service configuration (admin)	Web-lead keys are org config — live forms must not point at the sandbox, and the sandbox must not receive production traffic.
Portal / site base-URL settings	App settings (org-local records)	REDA flows deep-link through these URLs; stale production URLs in a sandbox misdirect test flows.
Which suite packages exist	Setup → Installed Packages	A REDA-only sandbox behaves differently from a full-suite one (for example, no invoice-to-Sales-Invoice sync without the Financials extension present).
Async Logs empty baseline	REDA Admin → REDA Async Logs	A clean baseline makes any test failure easy to spot.
Email deliverability	Salesforce Setup (standard)	Platform behavior — verify before any test that might send mass email.

A sandbox Admin Console Scheduled Jobs tab with nothing scheduled.

A sandbox's Admin Console Scheduled Jobs tab — every job still Not Scheduled, which is exactly why nothing bills until you schedule them.

Keeping tests contained

A sandbox is a real, working org — which means it can email real people and reach real endpoints if you let it. Before you run anything that sends or syncs, contain it:

Email. Confirm email deliverability settings before a test that might notify tenants or owners. This is standard-platform behavior — verify it, don't assume it.
Web forms and portal links. Never point a live web lead form at a sandbox, and never let a sandbox use production Data Service keys. Re-key or disable Data Service in the sandbox.
Accounting sync. Check the accounting extension setting so you know whether test invoices will sync to Financials — and whether that's what you want during the test.

Testing billing end-to-end

The most common sandbox surprise is that nothing bills. That's not a broken install — it's that REDA's billing is driven by background jobs, and those jobs are per-org state that a sandbox may not have. An unscheduled sandbox produces zero invoices. To test billing, schedule only the job the scenario needs:

You're testing…	Schedule in the sandbox	Timing note
Recurring rent invoicing	Recurring charges (matching the cycle: monthly / daily / weekly)	Matches today's due charges only — align the charge's next-invoice date with the run day.
Late-fee policy	Late fees (per-day and/or monthly)	Self-healing — a single run picks up all overdue state.
Month-to-month / holdover fees	The month-to-month jobs (per-day and/or monthly)	Self-healing.
Inflation / escalation	Both inflation jobs, plus a rule and that month's index entry	Self-healing; a missing index entry raises "Inflation Index not defined for the period."
Move-out billing edge cases	The delayed move-out job	Processes yesterday's scheduled move-outs.
Straight-line schedules	The straight-line job, or the on-record Calculate action for one lease	The on-record action avoids scheduling for single-lease tests.
Recurring inspections	The recurring inspections job	Frequently missed — schedule it explicitly.
Occupancy snapshots	The snapshot job, or the Create Reconciliation Snapshot action	The action expects a month: "Invalid input. You must provide value in YYYY-MM format. For example for Jan 2026, provide 2026-01."

Timing matters for test design. Recurring-charge runs match only what's due today — they don't catch up — so a recurring-rent test needs the run to land on the right processing day. The late-fee, month-to-month, and inflation runs self-heal: a single run processes everything due up to today, so those tests tolerate loose scheduling.

For spot tests, use the single-record actions. Several batch outcomes are reproducible on one record without scheduling anything — Calculate Straight-Line Schedule, Create Reconciliation Snapshot, and Run Manually on an inflation rule all run for a single record on demand. That's faster than scheduling a job when you only need to check one lease.

Rehearsing risky changes

Three patterns cover most of what a sandbox is for:

Leasing-rule edit and cascade. Change a Leasing Rule field, then open an active test lease and watch which of its fields the cascade overwrites. This is the canonical "why sandbox first" moment — do it here, never in production blind.

Billing-policy change. Adjust a recurring-invoice window or a late-fee parameter, schedule only the relevant job in the sandbox, and run a lease through it end-to-end before applying the change in production.

Flow-deactivation blast-radius test. Because each ticket-process flow is scoped to its record type, deactivating one disables that single process's side effects without touching the rest. Deactivate it in the sandbox and observe exactly what stops happening.

Deactivating a flow changes behavior — that's the point, and the risk. You can deactivate a REDA managed flow but you can't edit it. Deactivating one in a sandbox is how you learn its blast radius safely; repeating that in production changes production behavior, so only do so deliberately and with the sandbox findings in hand.

Resetting between test runs

REDA's delete guards apply in a sandbox exactly as in production — you can't delete a partially-paid or batched invoice, a charge under an approved deal, or a posted reconciliation line just to re-run a scenario. Design tests around that: keep test paths unposted and unapproved where you can, or use Reset Lease.

Reset Lease is the sandbox tester's reset button. On a lease that isn't yet occupied, it deletes the lease's charges, tickets, and invoices and returns the stage to the application stage — REDA warns first: "Upon resetting - the Opportunity Charges, Tickets, and Invoices will be deleted and the Opportunity stage will be set to \"Application New\"." An occupied lease can't be reset; it refuses with "Occupied Lease can not be reset. Please contact your System administrator."

The REDA Async Logs tab after a run, showing clean and flagged log rows.

The REDA Async Logs tab after a test run — a clean baseline of log rows with their success and failure counts.

Worked example: rehearsing a late-fee change

Meridian's administrator wants to change a late-fee policy. The sandbox rehearsal:

Choose or refresh a sandbox and run the re-check checklist — confirm the accounting extension setting and make sure no live Data Service keys are pointed at it.

Schedule only the late-fee jobs in the sandbox. Because late-fee runs self-heal, a single manual schedule is enough.

Set up a test case — a test lease with an overdue invoice — and let the next run raise the fee.

Observe, then apply. Confirm the fee is what you expected, then make the same change in production with confidence.

Sandbox mechanics are standard Salesforce. For sandbox types, refresh cadence, how data copies, and how scheduled jobs behave after a refresh, see the official Salesforce documentation: Sandboxes (Salesforce Help). REDA runs the same installed packages in a sandbox as in production at copy time, so a sandbox on a newer package version may show features this knowledge base doesn't cover yet.

Where to go next

The Go-Live Checklist — the job list to replicate in your sandbox before production.
Scheduling Background Jobs — the job catalog you'll schedule for a billing test.
Leasing Rules — why a rule edit cascades onto active leases, and needs a sandbox first.
Monitoring Async Logs — where job failures surface during a test.
Release Notes — rehearse each upgrade in a sandbox before production.

Frequently asked questions

No. Billing is driven by background jobs that are scheduled per org, and a sandbox has whatever schedule state it happened to inherit or lose. Schedule the relevant jobs in the sandbox (see The Go-Live Checklist) and the invoices will generate.

No. REDA has no trigger bypass — data loads and edits fire all the same automation as manual work. Plan loads accordingly, and deactivate a specific process flow only with care.

Deletion guards apply in a sandbox exactly as in production. Use unposted or unapproved test paths, or use Reset Lease on a lease that isn't occupied to clear its charges, tickets, and invoices.

Only one run of a job executes at a time. REDA responds: "A similar job is currently in process. Please wait for the existing job to be complete prior to initiating a new job. Contact your system admin for further assistance." Wait for the first run to finish, then retry.

Yes, if it isn't occupied. Reset Lease deletes the lease's charges, tickets, and invoices and returns it to the application stage. An occupied lease refuses: "Occupied Lease can not be reset. Please contact your System administrator."

Was this article helpful?