A Salesforce data load is a deploy in disguise: every row runs the org’s triggers, validation rules and flows, and you find out what they did after the rows are in. renmy runtime is a local Salesforce Apex runtime that runs the same automation on your own computer, against a small database it brings with it, with no Salesforce org, scratch org or sandbox. The Data Loader in its JetBrains plugin, Renmy Runtime - Salesforce IDE, maps a CSV onto an object, and Simulate runs every row through those triggers, flows and validation rules in a transaction that is rolled back, so you see which rows would be refused, and why, before any reach the org. Upload to Org then sends the same file to the org you pick. The real load still happens in the org; the rehearsal is local, free and repeats in seconds.
Nimbus was renamed renmy runtime in October 2026; the record of the rename is at Nimbus is now renmy runtime.
Why a Salesforce data load is a deploy
Picture the file: 5,000 invoices from the old system, cleaned up in a spreadsheet, saved as a CSV. You map the columns, press go and watch the counter. When it stops, the error file holds 300 rows the org refused, and each of the 4,700 it accepted fired a flow that created a task nobody wanted.
Nothing went wrong with the tool. A data load does what a user does when they save a record, five thousand times, without pausing. For every row the org runs the automation built up over the years, in a fixed order: before-save flows, before triggers, validation rules, duplicate rules, the save, after triggers, assignment rules, workflow rules, processes and after-save flows. The row that fails comes back as a line in an error file. The row that passed but did something you did not intend is harder to find, because nothing reported it.
A developer who changes a trigger gets a validation step before the change reaches production. A data load has never had one: the first time your file meets the org’s automation is the real run.
Who this is for: admins who load and update data, migration leads moving or consolidating orgs, and anyone who has opened an error CSV after a load and wished they had seen it first. No terminal, no code. IntelliJ IDEA Community is free, and the plugin installs the runtime for you.
What a local runtime is, in plain words
Apex, triggers, validation rules and flows run inside Salesforce, on Salesforce’s servers. That is why every change is deployed and every test waits for the org. A local runtime is a copy of that engine that runs on your own computer instead.
renmy runtime is one. It executes real Apex (classes and triggers), SOQL, DML and Salesforce Flows (record-triggered, autolaunched and screen flows) against an embedded PostgreSQL, a small database that ships inside the program that you never install or manage. No Salesforce org, no scratch org, no sandbox, no Docker, no JVM: one program for macOS, Linux and Windows. A Java or JavaScript developer who presses “run test” has always had this; Salesforce developers ran Apex tests in an org and waited. What is a local Apex runtime? explains the idea from zero.
It is not a mock or a guess. Governor limits are enforced. Triggers and flows fire in the platform’s documented order of execution, and a flow fault arrives as the error Salesforce would raise: FIELD_CUSTOM_VALIDATION_EXCEPTION for a Custom Error element, CANNOT_EXECUTE_FLOW_TRIGGER for anything else (how flows run locally). Where the runtime matches the platform and where it does not is a public record at renmy.net/parity; read it rather than trusting any claim of a perfect match.
How to rehearse a data load in IntelliJ IDEA
1. Install the plugin and open the project
In IntelliJ IDEA, open Settings → Plugins → Marketplace and install Renmy Runtime - Salesforce IDE (JetBrains Marketplace, version 1.15.1). IntelliJ IDEA Community, which is free, is enough. The Marketplace installs the one dependency, LSP4IJ; no JDK of your own is needed.
Then open your Salesforce DX project: the folder with an sfdx-project.json that your developers keep in version control. Ask them for a checkout; it holds the triggers, flows and validation rules the rehearsal will run. On first open the plugin installs the runtime into ~/.nimbus/bin and starts it. The Free tier needs no account.
If the org has automation the project does not, the rehearsal cannot run it. Drift, in the Org workspace, marks every file as in sync, differs, org only or local only, and Retrieve from Org fetches what the project lacks. Anything that talks to an org needs the Salesforce CLI; Authorize New Org… runs its browser login.
2. Put the file on the Data Loader
Open the Org workspace and its Data Loader tab. Drop the CSV on it, choose a file, paste rows, or right-click a file in the Project view and pick Use in Data Loader. Choose the operation: insert, update, upsert or delete.
The object is read from the Id prefix of the key column and the columns are mapped onto fields. A cell that cannot be read lands in the Problems table before anything else happens. For invoices-q3.csv, set to update:
- Id →
Id, the key column; the prefixa0BidentifiesInvoice__c. - Amount →
Net_Total__c, matched by field label. - Status →
Status__c, matched by API name; a picklist with 4 values. - Due →
Due_Date__c, matched by label, with a note: 3 cells are not a date.
Three bad dates are visible before anything has run.
3. Press Simulate
Simulate runs every row through the local runtime in batches of 200, inside a transaction that is rolled back. The triggers, flows and validation rules in the project fire for each row, as the org’s would. The report says what would change and which rows would be refused, and why:
Simulate 200 rows · 1 batch · rolled back
197 would update
3 refused by validation rule Amount_Positive:
"Net total must be greater than zero"
Predicted Changes… Problems… Retry Failed RowsPredicted Changes lists what would change on each row, including what a before-save flow or a trigger writes on the way; Problems lists the refused rows with the platform’s own message. The local database is left as it was.
4. Fix the file and simulate again
Three invoices have a negative net total. Fix them in the spreadsheet, save, drop the file again, press Simulate. Each pass takes seconds, and the org has not been touched. Repeat until the report says zero refused and Predicted Changes shows what you meant.
5. Upload to Org
Upload to Org sends the same file to the org you pick. The confirmation names the org and the row count, progress streams per batch, and the rows the org rejected can be exported and retried after you fix them. Anything in the plugin that writes to an org asks first and names the org.
What the rehearsal catches, and what it does not
It catches cells that cannot be read as the field’s type, validation rules with the message the user would have seen, triggers that throw, what triggers and before-save flows would write onto each row, and flow faults as the error the platform raises. It does not catch what is not on your machine: automation that exists only in the org is invisible until you retrieve it. For an update or upsert, the rows the file points at should exist locally too; Clone Org Data in the Workbench copies a slice of the org down for exactly that.
This is the honest boundary. The rehearsal is local; the load goes to the org, and the org is the final authority. What it removes is every refusal the project’s own automation would have produced, seen on your machine first.
The Workbench: editing rows with the automation switched on
The Data Loader is for files. The Workbench, in the Develop workspace, shows the local database one object at a time, in a grid, with a SOQL box above it. Editing a cell here is not a database update behind the automation’s back. renmy runtime runs it as Apex DML on the same interpreter a test uses, so triggers fire, before-save flows run, and a validation rule refuses here what it would refuse in the org, with the platform’s own message:
refused INV-004209 · Net_Total__c · FIELD_CUSTOM_VALIDATION_EXCEPTION:
Net total must be greater than zero (Amount_Positive)
the row is unchanged · 1 DML statement · InvoiceTrigger before updateThat makes the Workbench the place to try one awkward record before you build a file of five thousand. Data from switches the grid to an org for reading, Pull into Local copies the selected rows down, and the Branch control keeps separate copies of the local data for separate pieces of work. Save as Fixture writes the rows in view as an @IsTest data class, which is the hand-off to your developers: the records you found awkward become the records their tests use. Apex test data factories explains what they do with it.
I already have a sandbox. Why rehearse locally?
Because a load into a sandbox is still a load, and if the result is wrong, undoing it is another load. The sandbox is shared, its data is whatever the last refresh and the last colleague left there, and a refresh is not something you do between two attempts at a file.
The rehearsal rolls back. Each pass takes seconds, and nothing leaves your machine unless you point a panel at an org; source, schema and data stay local (security). The sandbox keeps the job only it can do: the dress rehearsal with the org’s full configuration, integrations and user interface, once the file is clean.
Try it
For an admin the path is the plugin: install Renmy Runtime - Salesforce IDE in IntelliJ IDEA, open the Salesforce DX project, then Org → Data Loader. A developer who wants the same runtime in a shell needs one command:
curl -fsSL https://renmy.net/install.sh | sh # macOS, Linux
irm https://renmy.net/install.ps1 | iex # Windows PowerShell
cd your-sfdx-project
renmy test "*"Frequently asked questions
Do I need a Salesforce org to simulate a data load?
No. Simulate runs every row through renmy runtime on your own computer, in a transaction that is rolled back; no org is contacted. You need an org, with the Salesforce CLI logged in to it, only for Upload to Org, and the confirmation names that org and the row count before anything is sent.
Do triggers, flows and validation rules really run during the simulation?
Yes. Every row runs through the local runtime in batches of 200, in the documented order of execution: before-save flows, before triggers, validation rules, duplicate rules, the save, after triggers, assignment rules, workflow rules, processes and after-save flows. Only what is in the project folder runs. The parity record at https://renmy.net/parity lists where the runtime matches the platform and where it does not.
Is the Data Loader free?
Yes. The Data Loader with Simulate and Upload to Org, the Workbench, Schema and the SOQL and Apex consoles are in the Free tier of the plugin: $0, no card, no account, one machine. Pro, which adds debugger stepping, watch mode and mutation testing, is free during the public beta and lists at $19 a month afterwards. Pricing is at https://renmy.net/#pricing.
Do I have to be a developer to use this?
No. There is no code to write and no terminal to open. IntelliJ IDEA Community is free, and the plugin installs the runtime the first time you open a Salesforce DX project. You need a checkout of that project from your developers, since it holds the automation the rehearsal runs, and the Salesforce CLI for anything that talks to an org.
What happens to rows the org rejects during the upload?
Progress streams per batch, and the rows the org rejected can be exported and retried once you have fixed them. A row the org refuses after a clean rehearsal usually points at automation the org has and the project does not; Drift marks it and Retrieve from Org fetches it before the next attempt.
Rehearse the file before the org sees it
The Data Loader in renmy runtime for JetBrains simulates every row locally, with the triggers, flows and validation rules firing and the transaction rolled back. The Free tier needs no account and no org.