The Krom Automation simulator lets you test a workflow completely before it goes live. It runs every step of your workflow using real data from your site, but with no side effects. No emails are sent. No posts are created. No API calls go out. No user records are changed.

You get a full picture of what your workflow would do, without touching anything real.

Why you should always simulate first #

Merge tags look correct in the editor, but it’s only at execution time that you find out whether a user actually had a first name, whether a post had a category, or whether an order included the field you expected.

Running the simulator before activating gives you that execution-time view without affecting any real users or data. It catches problems that aren’t visible in the canvas editor: empty merge tags, missing required fields, conditions that take the wrong branch, and action configurations that would fail against real data.

Make it a habit to simulate every new workflow and every significant edit before the workflow goes live.

How to run a simulation #

Open your workflow on the canvas. Click the Simulate button in the top toolbar.

Krom Automation runs through the entire workflow from trigger to final action. It uses real data from your site to populate merge tags and evaluate conditions. You’ll see the results appear directly on the canvas, with each node annotated to show its status and output.

Reading the simulation results #

After the simulation runs, each node on the canvas shows a status indicator.

Green (passed): The step ran successfully. The action would have completed without errors using the data provided.

Red (failed): The step encountered a problem. Click the node to see the error detail: what field caused the failure, what value was present, and what the expected format was.

Yellow (skipped): The step was skipped because a condition routed the workflow down a different branch. This is expected behaviour for condition nodes.

Click any node after simulation to open its result panel. The panel shows:

• The input data the step received
• How each merge tag resolved (you can see exactly what {{first_name}} or {{order.total}} became)
• The output the action would have produced
• Any error or warning messages

This is the same level of detail you’d see in the execution log after a real run, which makes the simulator useful for both testing and understanding how the workflow behaves with specific data.

What the simulator tests #

The simulator tests everything it can without creating real side effects.

Merge tag resolution

Every {{tag_name}} placeholder is resolved using real data from your site. You’ll see the actual values, including empty strings for tags where the data wasn’t available.

Condition evaluation

Each condition node evaluates its test against the real resolved data and shows which branch it would have taken, Yes or No.

Action field validation

Each action checks whether required fields are populated, whether values are in the correct format, and whether the configuration is complete.

Step sequencing

The simulation runs steps in order, so the output of one step is available as input to the next. If you’re using {{http_response.json.fieldname}} from an HTTP Request action in a later Send Email action, the simulator shows whether that reference would have worked.

What the simulator does not test #

Because the simulator avoids side effects, some things can’t be fully validated without a real execution.

External API connectivity. The HTTP Request action and any Pro integration actions (Mailchimp, Slack, etc.) are simulated locally. The simulator validates the configuration and merge tag resolution but doesn’t make the actual outbound call. Whether the external service accepts the request, returns the expected response, or throws an error can only be confirmed with a real execution.

Email deliverability. The Send Email action shows what the email would have contained, but doesn’t test whether your SMTP configuration successfully delivers email to the recipient’s inbox.

WooCommerce coupon creation. Actions that write to the database (Create Coupon, Update Post, Add Post Meta, etc.) are skipped in simulation mode.

The right approach is to simulate first to catch obvious issues, then activate the workflow and check the execution log after the first real trigger fire to confirm everything worked end to end.

Fixing issues found in simulation #

If a node shows a failure or an unexpected result in simulation, click it to read the detail, then fix the issue in the node’s configuration panel.

Common issues and their fixes:

Merge tag resolved to empty. The trigger data didn’t include that field for the test data used. Check whether the field is available from the trigger type you’re using (see the Merge Tags reference), and consider adding a condition to handle cases where the value might be empty.

Required field missing. A required action field was left blank. Fill in the field or use a merge tag that will always have a value.

Condition took wrong branch. Check the operator and value in the condition configuration. The simulation shows exactly what value was tested, so compare it against your expected value carefully.

Action configuration error. The action settings have an invalid combination. Read the error message in the simulation result panel for specifics.

After fixing, click Simulate again to re-run. Repeat until all nodes show green or the skipped/yellow status you’d expect from condition branches.

Simulating after edits #

Any time you make a significant change to an active workflow, disable it first, make your changes, simulate again, then re-enable it.

The simulator always reflects the current saved state of the workflow. If you make changes and simulate without saving, the simulation will run against the last saved version, not your new edits. Wait for the save indicator to confirm your changes are saved before simulating.