Testing Actions

Use debug logs to verify every Action behaves exactly as intended before it reaches real users.

Overview

Testing in Delphi is a two-layer process:

  1. Trigger validation – confirming the correct event fires when the right condition occurs.

  2. Action validation – confirming the downstream task (message, tag update, property change, API call, etc.) completes on-schedule and 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 your actions live on your users! Test them on yourself first by intelligently setting tags, as described in step 2 below.

Test your Actions and open the Occurrences logs if you're wondering...

  • Why didn't my Action fire?

  • Where do I see if a Trigger actually ran?

  • How can I confirm a delayed message will send?

  • How do I safely test without spamming real users?


✏️ How to Test an Action

1

Set up save your Flow.

Configure your Delphi flow, including the necessary triggers and actions.

Every change to a Trigger or Action must be saved before it can fire in test mode.

2

Isolate yourself with a User Tag filter (optional but smart)

  • Tag your own account (e.g., "Testing-Team"). See here for more information on how to tag your account, which you can easily do via the Audience tab.

  • In the Trigger’s Filters panel, choose that tag in the User Tag dropdown.

  • Result: only users with that tag (you) can fire the Trigger—live customers stay untouched.

3

Trigger it on purpose.

Interact with your Delphi exactly as a real user would (or ask a teammate to) to see if your trigger fires as intended.

4

Reload the Flow builder.

This refreshes the live logs.

5

Check Trigger Occurrences (triggers sidebar, bottom).

  • New row present? The Trigger fired!

  • Missing? Your condition didn't match — adjust the logic and retest.

6

Check Action Occurrences (actions sidebar, 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.) → Verify the message actually reached the user inbox.

7

Iterate

Edit, save, and repeat until both logs show the expected entries with no errors.


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 to catch edge cases.

  • Test the negative path. Try inputs that shouldn’t fire the Trigger to confirm it stays silent.

FAQs / Troubleshooting

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