Test an automation before you rely on it

Every rule on Automations — in the sidebar under Insights — carries four buttons on its row: Disable, Test, Edit, and Delete. This article is about the second one. If you have not built a rule yet, start with create your first automation.

CalsoThe Test button on an automation row

⤢

What the Test button sends

A test does not use one of your real bookings. Calso invents one — a client called Jane Doe, a session starting 24 hours from now — and runs your rule against it. Every curly-brace variable in your subject and body is filled in from that sample, so you read a finished message rather than a preview full of placeholders.

Because the sample client's address is your own, the test email arrives in your inbox addressed to Jane Doe. That is expected, and it is the point — you get to read your own wording without spending a real client's patience on a draft.

Run a test

1. Check the badge next to the rule reads Active

   Open Automations under Insights and find the rule in the list. The badge beside its name reads either Active or Inactive, and only an active rule can be tested — press Test on an inactive one and the line beneath the list comes back in red with Test failed: Enable this automation before testing it — only active automations fire. Press Enable on the row and the badge flips to Active.

2. Press Test on that row

   Test is the second of the four buttons on the right of the row. On a Send SMS rule a phone box sits just before it, reading Your mobile, e.g. +1 416 555 0134 — type the number you want the test text to reach. Press Test once; it dims for a moment while Calso builds the sample booking and runs your rule.

3. Read the line beneath the list

   The result appears as a single line under the whole list of automations, not next to the row you pressed. Test automation fired successfully. in green means Calso ran the rule, and on a text rule the same line names the number instead — Test automation fired — SMS sent to +14165550134. Test failed: in red, followed by a short explanation, means it could not: a rule left Inactive, a phone number Calso cannot read, a text your plan or your notification settings do not allow, a rule deleted in another tab, or a paused workspace.

4. Check your own inbox

   Give it a minute, then look in the inbox for the address on your Calso account — or at the handset you named, if you tested a text rule. The message arrives under the same sender as your real client email, with your subject line, your body text, and the sample details filled in. Read it the way a client would, then reopen the rule with Edit to fix anything that reads badly and save with Update.

What the success line actually means

Test automation fired successfully. confirms that Calso found your rule and ran it. For an email it says nothing about delivery — that happens after the line is written, so treat it as "the rule ran" and treat the message landing in your inbox as the real proof. Automation email counts as marketing and a test honours that like any other send: if the address on your account has used the unsubscribe link in one of your own emails, the test is skipped along with everything else. A text rule tells you a little more, because Calso runs the plan, allowance and switch checks before it fires anything — so a line naming the number means the rule ran and none of those turned it away. Delivery still happens after the line is written, so the handset is the proof, exactly as the inbox is for an email.

One press tests every rule on that trigger

A test runs by trigger rather than by row. Press Test on a Booking Confirmed rule and every active Booking Confirmed rule in your workspace runs against the same sample booking — so if you have three of them, you get three emails. Rules on other triggers are left alone.

The Event type filter (optional) still applies. The sample booking borrows the event type of whichever rule you pressed, so rules set to All event types always join in, while a rule narrowed to a different event type sits the test out.

What a passing test does not prove

Three things about the live send are absent from a test, and each one is worth checking another way.

• That the trigger will ever fire. A test runs the action; it never proves the trigger. Booking Confirmed stays quiet on a card-paid session and on one waiting for your approval, and Booking Completed waits until you press Mark as Completed yourself. Automation triggers and actions covers exactly what starts each one.
• Package rules. A test hands your rule a booking and package details, so a Package Purchased, Package Expiring, or Package Exhausted rule set to Send Email appears to work. In real use those three triggers carry no booking and therefore nobody to write to. Use Send Webhook on package triggers — automation triggers and actions covers which pairings carry a client.
• Variables on two triggers. {eventTitle} and {hostName} are filled in during any test, but come through empty on the Booking Completed and No Show triggers in real use. Write those two rules so they still read properly without either word — using variables in automation messages shows how.

Testing a text or a webhook rule

A Send SMS rule tests properly, as long as you say where the text should go. Calso holds no phone number for you, so the box beside Test starts empty every time: type your own mobile, either in full as +1 416 555 0134 or as a ten-digit North American number — spaces, dashes and brackets are all fine — and press Test. The text lands on that handset with the sample details filled in.

A text test runs the same checks a live send runs, and says so in plain words rather than failing quietly. If texts are not part of your plan you get Test failed: SMS is not included in your current plan.; if you have used the month's allowance, You have reached this month's SMS limit for your plan. The automation will resume next month.; and if the switch is off, a line telling you to turn on Enable SMS reminders for clients in Settings → Notifications. That makes a text test the quickest way to check the whole path is open before a client depends on it — then read the message on the handset to be sure it arrived.

A Send Webhook rule is just as real: Calso posts to the URL you saved, with the sample booking in the payload if Include booking data in payload is ticked. Whatever is listening there receives a booking for Jane Doe that never happened, so point the test at a practice endpoint if a live one would create records you then have to clean up.

Once a rule reads the way you want it to, leave it Active and let the next real booking do the rest. To change which of your routine emails go out at all — confirmations, reminders, the ones that come to you — that is a different screen: choose which emails you and your clients receive.