The Test Button: What a Rule Run on a Fake Client Really Does
Every firm that builds an automation rule feels the same hesitation before switching it on. The rule will send e-mails to customers, move deals and call a webhook — and a mistake will be repeated on every matching record. Firmspace puts a Test button next to each rule. It is useful, but it is not a sandbox, and the difference is worth two minutes.
What the button does. It sends one request with the rule’s id, and the CRM automation engine runs this rule’s action immediately, once, with a fixed sample event. The sample is always the same: a deal called Test deal, in Test stage, with a contact called Test Client, an empty id and an empty e-mail address, plus a sample task, message and sender. The test does not choose one of your records to act on. What happens next depends on the action.
Three actions fail by design, and the message explains why. Moving the deal fails because the sample has no real deal — the engine answers that this event has no deal to move. Adding a note fails for the same reason: there is nothing to attach it to. Sending an e-mail to the customer fails because the test client has no address. Set the recipient to the owner instead, and the letter is really sent to the owner. That is not a broken test; it is a test honestly saying that the rule depends on real data.
Three actions do run, for real. A notification appears for the whole firm, because the test fires the same notification the rule would fire. A task is created — a real task in the task list, with the rule’s text and the owner as the responsible person. A webhook is actually called: the request leaves your CRM and goes to the address from the rule, which must start with https and resolve to a public host. And the AI action calls the model and may perform one real write.
The disabled rule is a special case, and in a good way. The test route runs the rule directly, without asking whether it is switched on and without the stage filter. That means you can test a rule while it is still off — which is exactly when you want to test it. The real event flow is stricter: a disabled rule is skipped, and a rule bound to a stage fires only on that stage.
Where the result goes. Every run, test or real, writes one line to the rule log: the rule’s name, the date, success or error, and the message the action returned. The message is cut at 300 characters, and the log keeps the last 200 entries, so it is a journal, not an archive. The section that shows it is called Test Logs, but it records real runs as well — the name of the rule is the only thing that tells them apart.
Errors do not escape. The engine catches an action’s error, writes it to the log with the status error and returns a short message, which the interface shows as a toast. A failed test does not break the rule, does not touch other rules and does not stop the page. What it does mean is that the same action would probably fail in a real run too — the log line is the place to read why.
The AI action deserves its own paragraph, because a test of it is not free. The step receives the sample data, the firm’s instruction and the owner’s full tool set, and it may call at most one write tool — in an automated run there is nobody to confirm anything. It has four steps to think, every lookup and every write goes into the AI log, and it spends the firm’s daily AI quota exactly like a chat request. If the instruction is unclear, the correct behaviour is to do nothing and say so.
So a test of an AI action can create a real task, note or e-mail draft while you thought you were only rehearsing. Use that consciously: while a rule is being tested, instruct the AI to look things up and report, not to act, and add the write instruction when the rule is ready. If your plan no longer includes the autonomous AI step, the test says so instead of pretending that everything is fine.
The delay is ignored by the test. A rule set to wait one hour, one day or three days runs immediately when you click Test — the delay belongs to the event flow, not to the action. In a real run the event stores a job with a run time, and a later pass claims the job with a conditional update so that two tabs, two employees or two server instances cannot execute it twice. If the rule was deleted or switched off while the job waited, the job is skipped; if the deal left the stage the rule is bound to, the action is skipped and the log says so.
What a test cannot prove. It cannot prove that the customer’s address is correct, that the mailbox is connected, that the template variables look right with real data, or that the recipient reads German. It cannot prove that the rule will fire exactly once, because that is the job claim’s work, not the action’s. It proves that the action’s plumbing works: the notification is delivered, the task is created, the webhook answers with a status, the AI reaches its tools.
A safe rehearsal. Switch the action to a notification to yourself or to a webhook pointing at a test endpoint, run the test, read the log line, then put the real action back and test once more if the action allows it. For an e-mail rule, set the recipient to the owner first, check the rendered text, and only then choose the customer. Keep the rule switched off until the test reads the way you expect.
One more honest limit: the sample data is written in English. If your rule’s message is a German template, the substituted values will be the English sample ones — Test Client, Test deal — so judge the plumbing, not the wording. Wording is checked on a real record or in a preview of the template.
The Test button is worth having precisely because most automation mistakes are boring: a wrong recipient, an action that needs a record it never gets, a webhook that answers 500, an AI instruction that asks for something the tools cannot do. A test run finds those in seconds. It just does not promise that the customer will receive a perfect letter — that still needs a human, and Firmspace CRM keeps the rule log so that the human can see what actually ran.