Testing Actions
Validate the trigger and the outcome—without spamming real users.
Overview
Testing in Delphi is a two‑layer process:
Trigger validation — confirm the correct event fires under the right condition.
Action validation — confirm the downstream task (send message, update tag/property, call API, etc.) completes on schedule with the expected payload.
Both layers are proven via live, timestamped logs—Trigger Occurrences and Action Occurrences—pinned to the bottom of the Flow builder’s sidebar. These logs are the single source of truth; if you don’t see the event there, Delphi won’t execute it in production.
Tip: Don’t test on customers. Tag your own account and target that tag so only you can fire the Trigger.
Why it matters
Avoid surprises: Catch mis‑fires and wrong channels before users see them.
Protect trust: Validate timing, content, and audience so nudges feel helpful—not spammy.
Prove it works: Logs give you a verifiable trail for QA and team reviews.
Iterate faster: Quick sandbox runs help you refine sequences without risking production.
How to test an Action
Set up & save your Flow. Configure the trigger(s) and action(s). Every change must be saved before it can fire.
Isolate yourself with a User‑Tag filter (optional but smart).
Tag your account (e.g.,
Testing-Team) in Audience.In the Trigger’s Filters, include that tag so only tagged users can fire it.
Set the trigger frequency to happen every time so you can test it multiple times.
Trigger on purpose. Interact as a real user would (or ask a teammate) to fire the Trigger.
Reload the flow builder. This refreshes the live logs.
Check Trigger Occurrences (triggers sidebar, scroll to bottom).
New row present? The Trigger fired.
Missing? The condition didn’t match—adjust and retest.
Check Action Occurrences (actions sidebar, scroll to bottom).
Instant actions → Row should appear immediately.
Delayed/Scheduled actions → Row appears after the timer expires; note the timestamp.
User‑visible actions (Send Message, etc.) → Confirm the message actually reached the user inbox.
Iterate. Edit, save, repeat until both logs show the expected entries with no errors.
Note: Send‑message wording may vary slightly each time, just like normal conversations. Trigger multiple times to compare outputs.
Best practices
Use User‑Tag filters for safe sandboxing; never risk spamming production users.
Recreate real scenarios: don’t shortcut the Trigger; mimic true user behavior.
Test the negative path: try inputs that shouldn’t fire to confirm silence.
FAQs
How can I test without sending messages to real customers? You can test without sending messages to real customers by tagging your own account, setting the Trigger's User Tag filter to that then, then running the test. Only tagged users fire the Trigger, so customers never see test messages.
Why does my Trigger appear but the Action doesn't? There might be a few reasons why your Trigger appears but the Action doesn't. First, check if there's a delay you forgot about. Second, verify the action saved is actually the one you intended (is it via the right medium if it's a contact user action or did you accidentally select the wrong kind of action).
Can I force-fire an Action without the Trigger? No, you cannot fire an Action without the Trigger. Actions are always linked to their Trigger.
Do Send Message Actions always vary the wording? Yes, send message actions always vary the wording at least slightly, just as your Delphi varies its messages to keepu sers engaged.
My delay is set to days—do I really have to wait? Yes, if you set your delay to days, then you actually do have to wait to test it. However, for long delays, what we'd recommend doing is duplicating the action, setting a one-minute delay, testing it, then switching back to the original schedule.
Last updated