Test Salesforce Flows locally before you activate them

renmy runtime was called Nimbus until October 2026. Same tool, same binary, new name; the record of the rename has the details.

Who this is for. Salesforce admins, flow builders and low-code consultants who build automation in Flow Builder, test it by clicking through a sandbox, and have never typed a command into a terminal. Every command below is explained before it appears. The developer side of the idea is in What a local runtime is, and why Salesforce never gave you one.

Why testing a Salesforce Flow in a sandbox is slow and risky

The way most flows get tested today: build the flow in a sandbox, press Debug, create a record by hand, watch what happens, adjust, repeat. For a record-triggered flow you may add Flow Tests in Flow Builder. Then you activate, deploy to production, and watch the first real records go through.

Debug and Flow Tests are useful, and both run in the org. That is where the trouble starts.

• The sandbox is shared. Someone else’s half-finished flow on Opportunity, a validation rule added on Friday, a trigger a developer is midway through: all of it fires when your record saves. When the result is wrong, you spend the afternoon finding out whose automation did it.
• The data is yours to build, every time. An Account, an Opportunity in the right stage, an owner with the right profile. You click them together, and after the next sandbox refresh they are gone.
• Order of execution is invisible until it bites. Salesforce runs before-save flows, then Apex triggers, then after-save flows, in a fixed order you cannot see in Flow Builder. A flow and a trigger that both create a follow-up Task produce two Tasks, and nobody notices until a sales rep asks why.
• Every round takes minutes. Save, activate, find the record, edit it, open the related list, read, reset the data. Twenty rounds is an afternoon.

None of this is a flaw in your flow. It is what happens when the only place that can run a flow is a shared org.

What “on your machine” means when you build flows

When you click Save in Flow Builder, Salesforce stores your flow as a file: an XML document with every element, decision, formula and assignment in it. Your developers already pull these files down into a project folder on their computers, together with every object, field, trigger and class in the org. That folder is what they keep in version control and deploy from. It is the whole org, as files, on a laptop.

A local runtime is a program that reads those files and executes them right there, with its own small database standing in for the org’s. This is how every other software platform works: a Java developer presses “run test” and a program on their machine answers in a second, without talking to a server. Salesforce never shipped this for Apex or for flows, because the Apex compiler, the database and the test runner all live in Salesforce’s data centres. renmy runtime is that missing program. For you, the practical picture is a private, instant sandbox on one computer, with no other users, that starts empty and throws everything away after each test.

Two words you will meet below. A terminal is the plain text window developers type commands into: Terminal on a Mac, PowerShell on Windows. You type one line, press Enter, and read what comes back. A test is a few lines of Apex that create a record, do the thing your flow reacts to, and check the result. A developer colleague writes it; you can read it, because it says in plain words what the flow is supposed to do.

What renmy runtime does with a Salesforce Flow

renmy runtime executes the flow as it is saved in the file, against an embedded PostgreSQL database, on the computer where the project folder lives. It runs autolaunched, record-triggered and screen flows, including subflows, formulas and decisions. The Apex triggers on the same object run in the same transaction, in the platform’s order of execution, with governor limits enforced. It is the same runner that runs the Apex tests in the project, so flows and triggers are exercised together, by the same test. Not a mock of Salesforce and not a copy of it: a runtime that reproduces its rules.

Concretely: when a test updates the stage of an Opportunity, the before-save flows run, then the Apex triggers, then the after-save flows, and the test reads the records that are left. If your new flow and an existing trigger both create a Task, the test sees two Tasks: the order-of-execution problem from the previous section, found in a fraction of a second, before the flow has touched production or a shared sandbox.

How to test a record-triggered flow before you activate it

The example: a record-triggered flow on Opportunity called Closed Won Follow-Up. After an Opportunity is saved with the stage Closed Won, it creates a Task “Schedule kickoff call” for the owner. The org also has an Apex trigger on Opportunity, written two years ago by someone who has since left.

1. Get the flow into the project folder

Ask your developer to retrieve the flow into the project. On their side it is one Salesforce CLI command, and the result is one file:

sf project retrieve start --metadata Flow:Closed_Won_Follow_Up
# -> force-app/main/default/flows/Closed_Won_Follow_Up.flow-meta.xml

2. Write down what the flow should do, as a test

This is the part a developer writes and you read. The whole test is: make an Opportunity, close it, count the Tasks.

@IsTest
private class ClosedWonFollowUpFlowTest {
    @IsTest
    static void closingAnOpportunityCreatesOneFollowUpTask() {
        Account acct = new Account(Name = 'Harbourlight Ltd');
        insert acct;
        Opportunity opp = new Opportunity(
            Name = 'Harbourlight renewal',
            AccountId = acct.Id,
            StageName = 'Prospecting',
            CloseDate = Date.today().addDays(30)
        );
        insert opp;

        Test.startTest();
        opp.StageName = 'Closed Won';
        update opp;   // the record-triggered flow and the trigger run here
        Test.stopTest();

        List<Task> tasks = [SELECT Subject FROM Task WHERE WhatId = :opp.Id];
        Assert.areEqual(1, tasks.size(), 'Expected exactly one follow-up Task');
        Assert.areEqual('Schedule kickoff call', tasks[0].Subject);
    }
}

Read it top to bottom and it is your acceptance criterion: one Opportunity moved to Closed Won, exactly one Task, with that subject. The records exist only inside the test; nothing is left behind.

3. Run it

In the terminal, inside the project folder:

renmy test ClosedWonFollowUpFlowTest

renmy test means “run tests”; the word after it names which ones. renmy test "*" runs every test in the project (the asterisk means “all”; the quotes stop the terminal from interpreting it). A test like this finishes in tens of milliseconds, SOQL and DML included. The published benchmark puts four open-source suites, 837 tests, at about 1 min 46 s in an org against 2.4 s locally, every test passing in both.

4. Read the result

If the old trigger also creates a Task on Closed Won, the first assertion fails: expected 1, actual 2. You now know, before activation, that the flow and the trigger overlap. The fix is one of two edits: retire the Task logic in the trigger, or add an entry condition to the flow. Edit, save, run again. Each round is a second, not a quarter of an hour, and no shared sandbox was touched.

When the flow is ready, the same test becomes a gate: renmy deploy runs the local gates, your tests among them, before anything reaches the org. It is in the Free tier.

Testing a Salesforce Flow without a terminal

Three other faces sit on the same runtime.

The Dev UI. renmy dev starts a browser-based test runner: a page where you pick a test, click run, and read the result, plus a schema browser and a coverage explorer. One command to start it; everything after is clicking.

VS Code. The VS Code extension puts a run button above every test and shows the result inline.

IntelliJ IDEA. The JetBrains plugin, Renmy Runtime - Salesforce IDE, does the same inside IntelliJ IDEA, Community edition included. The JetBrains plugin also opens a flow as a graph (View Flow), so you can read its elements and decisions beside the test that exercises it.

What it does not do

• It executes the logic of a screen flow. It does not render the screens. Decisions, assignments, lookups, record creates and updates in a screen flow run. Nobody clicks through the flow on your laptop; what the user sees (labels, help text, conditional visibility, layout) is checked in a sandbox, with a user.
• It is not Salesforce. It reproduces the platform’s rules closely enough that the four suites in the benchmark pass identically in both places, but the honest statement is the parity record, not a percentage. If a flow uses something the runtime does not cover yet, that is where you find out.
• It does not replace review in a sandbox. Permissions, page layouts, what the sales rep actually sees, user acceptance: still an org, still humans.

Do I still need a sandbox?

Yes. The sandbox is where you activate the flow, where a user clicks through it, where permissions and layouts are checked, where the business signs off. What changes is what happens before that: the twenty rounds of “does the flow do the right thing to the records, with the triggers in the loop” move to a laptop, cost a second each, and leave the sandbox clean for the review it is good at.

Try it

# macOS or Linux: open Terminal, paste the line, press Enter
curl -fsSL https://renmy.net/install.sh | sh

# Windows: open PowerShell, paste the line, press Enter
irm https://renmy.net/install.ps1 | iex

# Go to the project folder (ask your developer for the path), then run every test
cd your-sfdx-project
renmy test "*"

# Or start the browser face
renmy dev

The quickstart walks through the first run in under five minutes. Issues, docs and released binaries are on GitHub; for IntelliJ IDEA, the plugin is Renmy Runtime - Salesforce IDE. The Free tier covers unlimited local test runs on one machine, no account, no card.

Frequently asked questions

Can I test a Salesforce Flow without a sandbox?

Yes, for what the flow does to records. renmy runtime executes autolaunched, record-triggered and screen flows on your own computer against an embedded database, together with the Apex triggers on the same object, so a test can create a record, let the flow react, and check the outcome in milliseconds. A sandbox is still where the flow is activated and where users click through it.

Does renmy runtime show me a screen flow the way a user sees it?

No. It executes the logic of a screen flow: decisions, assignments, lookups and record changes. It does not render the screens, so layout, labels, help text and conditional visibility are checked in a sandbox with a user, not locally.

Do I need to know Apex to test a flow locally?

Not to run one. The test that exercises a flow is a short Apex class that creates a record, changes it and counts the result; a developer colleague writes it and an admin can read it as an acceptance criterion. Running it is one command, renmy test, or one click in the Dev UI, VS Code or IntelliJ IDEA.

Does the flow run in the same order as in Salesforce, with my Apex triggers?

Order of execution with triggers and flows is part of what renmy runtime reproduces: the flow and the Apex triggers on the same object run in one transaction, in the order the platform defines, with governor limits enforced. The parity record at renmy.net/parity lists what matches and what does not.

What does it cost?

Nothing for an individual: the Free tier includes unlimited local test runs, flows included, on one machine, with no account and no card. Pro and Team add watch mode, debugger stepping, the daemon and CI runs, and both are free during the public beta.