monday.com No Dry-Run Mode for Automations

You need to test an automation before letting it run on live data. Click a button, see what WOULD happen (which email would send, which statuses would change, which boards would update), but don’t actually DO any of it. A dry-run mode. A preview. A sandbox.

monday.com has no such feature. When you test an automation, it fires for real — emails go to real people, statuses change on live boards, cross-board items get created, and you’re left manually undoing everything if the test wasn’t what you expected.

monday.com doesn’t document an email test mode either, and the workflow builder’s Run now test is a live run: board actions still run live. Change a status during testing? It changes for real. Create an item on another board? It creates for real. There is no rollback, no undo, no “this was just a test” safety net.

This article explains why monday.com’s lack of dry-run testing is a critical gap, what partial workarounds exist, and how to test safely today.

The Problem: Testing Fires Real Actions

monday.com automations execute immediately when their trigger fires. There is no “simulation mode” where you can see what would happen without actually doing it.

What This Means in Practice

Scenario 1: Testing an email automation

• You set up an automation: “When status changes to ‘Approved’, send email to client”
• You change an item’s status to “Approved” to test
• The email sends to the real client immediately
• You realize the email template had a typo
• You cannot unsend the email
• The client received a broken email

Scenario 2: Testing a cross-board automation

• You set up: “When button is clicked, create item on Delivery Board”
• You click the button to test
• A real item is created on the Delivery Board
• You realize the column mappings were wrong
• You have to manually delete the test item
• If you test 5 times, you create 5 duplicate items

Scenario 3: Testing a status change automation

• You set up: “When status changes to ‘Complete’, move item to ‘Archive’ group”
• You change an item’s status to “Complete” to test
• The item moves to the Archive group
• Your team sees it in the archive and thinks the project is actually complete
• You have to move it back manually and explain it was just a test

Community Evidence

From a forum thread titled “‘Test Automation’ Function” — 9 replies spanning June 2022 to August 2025 (3+ years, no resolution):

“It would be helpful to be able to test the notification…without having to wait until Friday” — peter.vardy, June 9, 2022

Described pain of managing 20+ action automations without test capability. — psperry, June 9, 2022

“It’s really very difficult to test anything because one has to wait for 1 hour to test a schedule based automation after each change made.” — vparassidis (Vera), July 25, 2023

Asked for status update after 2+ years. — connectrtem, February 14, 2025

Posted tumbleweed emoji (suggesting abandonment after 3+ years). — dk_NFroehlich, August 26, 2025

monday.com official response: NONE in 3+ years.

What Users Need vs. What monday.com Offers

What Users Need

What monday.com Offers

From the official automation documentation:

No test mode, sandbox, preview, or dry run for board automations.

The workflow builder guide does suggest using Run now to test workflow actions before publishing, then checking Run history (monday.com Help Center) — but Run now is a live run, not a simulation.

Community Evidence: 3+ Years of Feature Requests

Thread 1: “Test Automation” Function (3+ years unresolved)

Already covered above. No monday.com staff response in over 3 years.

Thread 2: Sandbox for Admins

From a November 2023 forum thread titled “Sandbox for Admins”:

“I would like to be able to have a workspace that is fully functional but does not take actions such as notifying people, etc.” — HAMondayAdmin (Andrea), October 31, 2023

monday.com staff (BiancaT) responded:

“I understand where you’re coming from and happy to take this feedback to the relevant team.”

Offered to convert to a feature request. No implementation.

Thread 3: Best Practices for Duplicate Boards for Testing

From a January 2024 forum thread titled “Best Practices for creating a duplicate board for testing changes”:

“I have a need to create a ‘Sandbox’ or copy of my current environment. This will allow me to test out automations prior to rolling them out in production.” — sharonmartinko, January 18, 2024

“Did you ever figure this out? Currently, I am manually duplicating the boards as well to test :s” — dan13l, March 2, 2025

monday.com official response: NONE. Over a year later, users are still manually duplicating boards for testing.

Thread 4: Developer Sandbox

From a November 2021 forum thread titled “Developer Sandbox”:

“I need to be able to test that my integration works with all the enterprise features.” — works, November 9, 2021

monday.com staff (AlexSavchuk) provided a developer account signup link but confirmed:

“It won’t include some of the Enterprise-only access features, like item viewing permissions.”

Even the developer sandbox is incomplete — it doesn’t support testing Enterprise features.

The monday.com Partial Solution (Run Now)

monday.com doesn’t document an email test mode: no help-centre or admin page describes redirecting automation emails to a test address. The closest native tool is the workflow builder’s Run now.

How It Works

What This Solves

• Lets you check a workflow end to end before you publish it
• Shows where it failed without guessing

What It DOESN’T Solve

Problem 1: Everything still runs live

Run now is a live run, not a simulation. If your workflow:

• Sends emails → still happens
• Changes status columns → still happens
• Creates items on other boards → still happens
• Moves items to groups → still happens
• Updates date columns → still happens

You see the result, but the emails and board changes are real.

Keeping Test Emails Away from Real Recipients

Until monday.com adds a preview, a short routine keeps test emails away from clients:

Board actions in the test still run for real, so keep them on test items too.

The Gmail and Outlook integrations send to an Email column or a text column, and a text column can hold several addresses. Put your own address in the test item’s email column, so the email lands in your inbox instead of the client’s. Emails sent to a team or to the board’s subscribers still reach them, so pause those automations while you test.

Testing Automation Emails: No Preview, No Test Send

monday.com email automations have no testing capabilities. You cannot preview emails before sending, you cannot send test emails, and you cannot redirect emails to a test address during development.

When you configure an email automation in monday.com, the email body takes placeholders for dynamic column values like {Client Name} and {Event Date}, picked from a list; the New Automation Builder also supports HTML formatting in the body (monday.com Help Center).

What you cannot do:

• Preview how the email will look with real data before sending
• Send a test email to yourself with sample data
• Verify that dynamic column values resolve correctly
• Check for typos, formatting issues, or broken merge fields
• See what happens when a referenced column is empty
• Redirect all outgoing emails to a test address during testing

Your only testing option: Trigger the automation with real monday.com items and see what happens.

This affects every email automation use case where testing is important — which is to say, all of them:

• Client-facing communications (can’t afford mistakes)
• Vendor notifications (broken emails damage relationships)
• Payment and invoice emails (financial data must be accurate)
• Form request emails (broken links render workflows useless)
• Time-sensitive notifications (can’t wait until production to discover errors)

The lack of email preview and test mode creates real risk: you either test cautiously (manually triggering with dummy data and risking real sends) or you skip testing and discover errors after recipients complain.

Mass Email Has a Test Send; Automations Don’t

monday.com’s Mass Email feature (part of the CRM product, separate from automations) includes a test email function. (monday.com Help Center) Before sending a bulk email campaign, you can send a test copy to yourself to verify formatting and content.

However, Mass Email is not part of the automation system. (monday.com Help Center) Mass Email is designed for manual bulk marketing sends — newsletters, announcements, campaigns. It does not support:

• Triggered emails based on status changes
• Button-click-initiated emails
• Item-created or item-updated emails
• Conditional emails based on column values

If you’re using email automations (the vast majority of monday.com workflows), you do not have access to the Mass Email test functionality. The two systems are separate. monday campaigns, a separate product, does run workflow-triggered campaigns and has its own test button (monday.com Help Center).

Column Values Show Only in the Sent Email

monday.com’s builder inserts column values from a picker rather than typed names, so a misspelled placeholder is unlikely. What you can’t check without sending is how the inserted values read in the finished email.

Without preview, you discover a problem only after the email has been sent — potentially to dozens or hundreds of recipients.

Empty Columns: You Find Out When It Sends

What happens when you reference a column that’s empty on a particular item? Does the email:

• Show the placeholder as literal text?
• Show a blank space?
• Show “(empty)” or some default text?
• Fail to send entirely?

You won’t know until you trigger the automation with an item that has an empty column. Without preview, there’s no way to test edge cases before going live.

Where BoardBridge Fits

BoardBridge by TaskRhino — Form & Workflow Automation for monday.com — sends button-click emails: an email goes out when someone clicks the button on an item. You can click it on a test item addressed to yourself before using it on real items. BoardBridge emails also support rich HTML with merged column values and CC and BCC. Ask us about previewing and testing BoardBridge emails for your setup.

Native Tools That Make Testing Safer

1. Run History and Analytics

Each board automation keeps a Run History: click a run to see the item it ran on and who triggered it. The Analytics tab shows the last 10 days of successful, failed and in-progress runs, and how many actions the automation used (monday.com Help Center). For workflows, Run history shows whether each step completed and which block failed (monday.com Help Center).

Why this matters:

• You can review exactly what happened after a test run
• You can see which runs failed and on which item
• You can identify issues (e.g., “status updated but email failed”)

2. Turned-Off Automations (Manual Testing Control)

A monday.com automation can be turned off without deleting it, using the toggle next to it (monday.com Help Center).

Why this helps testing:

This lets you test the trigger without executing the actions.

3. Conditions That Stop Incomplete Runs

Workflows can check data before acting: “If column is empty” is one of the workflow builder’s conditions (monday.com Help Center), so a run can stop when required data is missing. See how to block an automation when a pre-condition isn’t met.

Why Full Dry-Run Is Hard to Implement

A full dry run is hard for any tool to build on top of monday.com.

The Technical Challenge

Dry-run mode requires:

1. Simulating API calls without executing them — monday.com’s API doesn’t support “preview mode”
2. Predicting side effects — if Action 1 creates an item, Action 2 needs the new item’s ID, but in dry-run that ID doesn’t exist yet
3. Maintaining a parallel state — the system needs to track “what would be” vs. “what is” for every column, item, and board
4. Rollback capability — if a test runs live, you need to undo every API call (status changes, item creation, etc.)

What to Focus On Instead

Rather than waiting for a dry run, reduce the need for one:

• Test items addressed to yourself (keep emails away from real people)
• Conditions that stop incomplete runs (block automations when required data is missing)
• Run History and Analytics (an audit trail of what happened)
• Duplicate checks (see preventing duplicate items when automations fire twice)

These minimize the NEED for dry-run testing by making automations more reliable and easier to debug.

Workarounds for Testing Board Actions

If you need to test board actions (status changes, item creation) without affecting production data, here are three workarounds:

Workaround 1: Duplicate Board for Testing

How it works:

Pros:

• Completely isolated from production
• Can test freely without risk

Cons:

• Custom automations with Gmail, Outlook or Slack blocks don’t copy (turned-on recipes do; see automations that don’t carry over to duplicated boards)
• Cross-board automations still point to production boards (you’d need to update every target board reference)
• Time-consuming setup

Workaround 2: Test Group on Production Board

How it works:

Pros:

• No board duplication needed
• Automations work as-is

Cons:

• Test items live alongside production items (risk of confusion)
• Manual cleanup required
• Cross-board automations still affect production boards

Workaround 3: Use Automation Logs to Audit

How it works:

Pros:

• No test environment needed
• Works with existing setup

Cons:

• Still fires live actions (not a true dry-run)
• Relies on quick manual undo
• 7-day undo window only

Workaround 4: Guard Live Automations With a Test Flag

Add a status column such as “Mode” with “Live” and “Test”, then add “and only if Mode is Live” to client-facing automations. Test items set to “Test” no longer trigger them. The same guard idea stops repeat runs; see how to prevent duplicate items in monday.com automations.

Workaround 5: Test Workspace or Developer Sandbox

Duplicating boards into a Test Workspace copies the turned-on recipes, but custom automations with integration blocks aren’t copied, and cross-board recipes in the copy may still point at the production boards. Check every target before the first test. A free developer (sandbox) account keeps tests apart from production data entirely, within its limits (10 seats, 1,000 items per product, 25,000 actions a month, not for production use).

A Seven-Step Testing Routine

How Make, Zapier and n8n Compare

Best practice across all platforms: Use dedicated test workspaces/environments for automation safety and testing. No platform has perfect isolation.

What This Means for Your Workflows

Dry-run testing remains an unsolved problem across automation platforms, monday.com included. The workaround is to reduce the need for testing: pre-condition checks stop automations when data is incomplete, test items addressed to yourself keep emails away from real people, and Run History shows what happened.

For teams building complex automations, the best practice is:

It’s not perfect, but it’s the most reliable approach available today.

BoardBridge — Form & Workflow Automation for monday.com sends emails from a button, with item column values merged in, CC/BCC, a custom sender name and reply-to. Want to test it safely on your boards? Ask us, or have our monday.com customization team set up a test routine with you.

Frequently Asked Questions