SandForge: Realistic Data for Salesforce Sandboxes

Forge your Salesforce sandboxes. SandForge populates your developer sandbox with realistic data: cloned from a real record or generated synthetically, with production guardrails. One WebView UI, no Command Palette required.

Why switch from SFDMU or Data Loader?

• No config file to author. Paste a record ID: BFS discovery walks the relationship graph for you and lookups are remapped on write (a record type the target does not have keeps its source Id, and the SandForge log names it). No export.json to hand-write, no field mapping to keep in step with the schema.
• No mandatory CSV round-trip. Records move org to org over the API. CSV import is still there when you want it — one door in, not the only one.
• Production Guard on by default. Forge refuses a production org as a target; the other modules ask you to confirm any write to one, and DELETE there is blocked outright. Nothing to switch on, nothing to remember.
• Your existing SFDMU config keeps working. The Migration module imports an export.json into a Sync config, so what you already built comes with you.

Your first clone in 2 minutes

1. Connect your orgs: click the SandForge icon in the Activity Bar, open the org dropdown at the top of the launcher, choose New organization..., then Import from SF CLI to pull in every org authenticated in the Salesforce CLI.
2. Open Forge: click the flame icon in the sidebar, or run SandForge: Open Forge from the Command Palette.
3. Paste a root record ID from your UAT sandbox into Record ID or Salesforce URL (an Account works well).
4. Click Discover Graph, then tune Depth, Records per object, and Anonymize PII.
5. Click Review & Execute toward your dev sandbox. IDs are remapped as the records are written; a record type with no active record type of the same API name on the target keeps its source Id, and the SandForge log names it.

New here? The built-in Get Started walkthrough (Help → Welcome → "Get started with SandForge") guides you through these steps directly inside VS Code.

First steps, safely

1. Clone into a Developer sandbox or a scratch org. Forge writes only to a sandbox, a scratch org or a Developer Edition org; it refuses a production org, and any org it cannot tell is one of those.
2. Simulate first. On Review, Simulate takes every record through the write stage and writes nothing. Its results say how many records a real run would insert and how many gaps it found against the target.
3. Read the Automation and Gaps tabs. Automation lists what the target runs on the records the run writes (flows, processes, workflow rules, Apex triggers, assignment and duplicate rules), marks what sends an email or a text message, and says what may refuse a removal of the run's records; a real run asks you in VS Code to confirm what fires on insert and update before it writes anything. Gaps lists what the target would refuse or change in the rows, read from its metadata or found by a simulation or a rehearsal, each with the decisions it allows; the tab counts the gaps that will refuse rows and have no decision yet.
4. Emails and phone numbers are neutralized by default. Every email address is written under .invalid and every phone number as a fictional one, so the target's automation reaches no one; past 10,000 distinct numbers in one run, a phone field is left empty instead, and Results counts it. Keep emails and phone numbers as they are turns that off.
5. Rehearse when the target has validation rules or triggers. A simulation checks the rows against the target's fields; Rehearse has the target itself judge them, in calls it rolls back whole: every row when the run creates 200 or fewer, otherwise one row for each object, record type and set of filled fields. You confirm the calls it costs in VS Code first, and that confirmation names what a rollback cannot take back: platform events published immediately and callouts already made.
6. Remove a run from Results. Remove the records this run created deletes them from the target, children before their parents, into its recycle bin; its confirmation lists what the target runs as they are deleted. Records the run linked to, which the target already held, are kept, and so is a record changed since the run unless you include it. The runs under Recent runs, and under Older runs once they leave that list, offer the same removal.

Modules

SandForge ships 14 modules in a single extension:

Safety is on by default: Forge refuses a Production org as a target, and for every other module Production Guard asks for confirmation before any write on a Production org and blocks DELETE there. Each of its decisions is recorded with the run it concerns, in Reports → Audit Trail.

Screenshots

FAQ

• Does my data leave my machine? Beyond the orgs you connect, only to Anthropic, and nothing before you turn the AI Assistant on (it is off by default) and store your own key, which stays in VS Code Secret Storage. From then on a failed run's error message is sent too, unless sandforge.ai.errorResolution is off; the FAQ lists what each feature sends. Telemetry is off by default and, turned on, only writes error reports to a local log.
• Can I point it at production? Reads, yes. Forge never writes to one: it refuses a production target outright. The other modules' writes go through the Production Guard: a confirmation first, and destructive operations (DELETE) are blocked outright.
• Is this an SFDMU replacement? For moving data between orgs from your editor, yes — and without the config file: you paste a record ID, SandForge discovers the relationship graph and remaps IDs on write (a record type the target does not have keeps its source Id, and the SandForge log names it). SFDMU keeps the edge for headless CI, where it has a real binary and SandForge does not. Switching costs nothing you already built: the Migration module imports your existing export.json into a Sync config, non-destructively — nothing is written to your orgs.
• Which orgs are supported? Any org authenticated in the Salesforce CLI (sf), imported in one click.
• Is it free? Yes — MIT licensed, no account, no paid tier.

Documentation

Requirements

Installation

From Marketplace (recommended)

1. Open VSCode
2. Go to Extensions (Ctrl+Shift+X)
3. Search for SandForge
4. Click Install

From VSIX

Download sandforge.vsix from the Releases page, then run Extensions: Install from VSIX... from the Command Palette.

Keyboard Shortcuts

In-app, press Ctrl+K for the command palette and G + a letter to jump between modules (see the Help page for the full map). On macOS, use Cmd instead of Ctrl.

Configuration

See the full list of settings in the VSCode Settings UI under "SandForge".

Internationalization

Full UI in 6 languages: English, French, German, Spanish, Japanese, Brazilian Portuguese. Key parity across locales is enforced in CI, and your language choice persists across sessions. Numbers and dates are formatted with Intl APIs in the language picked in SandForge, keeping the editor's regional conventions when the editor uses that same language. Durations are not: they are composed from fixed h/min/s/ms tokens and read the same in every locale.

Support

• Report an issue
• Ask a question (Q&A)
• Changelog
• Security policy

Missing a feature? Open a feature request — responses are fast.

Author

Stephane Berthoz

License

MIT