Testing a trigger without bothering customers

How to prove a trigger works before it can reach a customer, using a tag, a test address or a sandbox.

How to prove a trigger works before it can reach a customer, using a tag, a test address or a sandbox.

The safest order

1. Build it with a test condition. Add a condition requiring a tag such as test-rule, so it only fires on tickets you tag by hand.
2. Create a ticket from an address you control and add the tag.
3. Watch what happens. Check the ticket events and your test inbox.
4. Test the negative case. A ticket that should not match, to confirm it does not.
5. Remove the test condition and let it run for real.

Step five is the one people forget, and a rule that silently never fires because the test tag is still required is a common find in an old configuration.

Use a sandbox for anything large

Where a change affects routing or sends to many people, a sandbox is the right place. Copy the configuration, test there, then deploy. On plans with configuration deployment that is a supported path rather than a manual rebuild.

Testing notifications properly

Create the ticket from a real external address, ideally on a different mail provider. What arrives in that inbox is what your customer gets, including how placeholders resolved and whether it landed in spam.

Testing with an internal address hides both of those.

See also

• Creating a sandbox environment
• Why my trigger did not fire
• What to test in a sandbox before you go live