Skip to main content
An automation has three independent gates. They are edited in different places, they run at different moments, and they do different things when someone fails them. Confusing them is the most common reason an automation sends to the wrong people or sends nothing at all.
A profile filter never removes anyone. An exit rule always does. If you want someone gone, write an exit rule, not a profile filter.

​
Gate 1: trigger filters

Trigger filters ask about the properties of the event itself, not about the person. They live on the trigger, under Only when, inside the Set up trigger panel. This is how you build “an order over 500” or “a 1 to 3 star review” at the point of entry, without a separate automation per case. Which properties you can filter on depends on the trigger:
Order amount, currency and source. Available on Placed order, Paid order, Fulfilled order, Order cancelled, Order refunded, Added to cart and Checkout started.
Rating, has photo, has video, published, verified buyer, product, and question or answer. This is what lets you send a thank you to a 4 to 5 star review and a service recovery message to a 1 to 3 star one.
Points, tier, reason, reminder stage, referral type and the loyalty app the event came from.
Any property you send on the event. Senderz does not need to know the property in advance.
Some triggers carry no filterable properties. When that is the case the panel says so rather than showing you an empty picker.

​
Every trigger carries its own filter

An automation can have several triggers on one entry point. They are combined with OR: the contact enters when any of them fires. Each trigger keeps its own separate Only when conditions. So one automation can enter on “Placed order over 500” and on “Submitted a review with 5 stars”, and the two sets of conditions never interfere. Within a single trigger, all its conditions must match. There is no OR inside one trigger’s filter.

​
Gate 2: profile filters

Profile filters ask about the person. They are edited in the Set up trigger panel under Profile filters, and the automation inspector links across to the same place. Leave them empty and everyone who fires the trigger enters.
Profile filters are checked twice, and merchants routinely miss the second check. A contact who no longer matches when a message step comes up does not get removed. That single step is skipped and they carry on to the next one.

​
Where the second check happens

The re-check runs before every step that does something to a contact or to the outside world: Email, SMS, WhatsApp, Push, Update in list, Update user properties, Grant points, Internal team notification and Webhook. It does not run before Wait, Conditional split or A/B test. Control flow always continues. This is what makes “only message people who are still subscribed” safe to write as a profile filter. Someone who unsubscribes on day two of a five day automation quietly stops receiving the remaining messages instead of failing silently at the provider.

​
What you can filter on

The condition picker is organised by category: Random sample is a fixed bucket per profile, not a fresh coin flip on each evaluation. A contact who is in your 10 percent sample stays in it.

​
How conditions combine

Conditions inside one box are combined with OR. Boxes are combined with AND. So two boxes each holding two conditions read as “(A or B) and (C or D)”. Alongside the filter you can pick saved segments under In segments. A contact must match the filter and be in at least one of the chosen segments. You can pick up to 20 segments.

​
The live count

As you edit, Senderz shows a running estimate under the filter: approximately N profiles match. It updates a moment after you stop typing. Read it as a sanity check on the filter, not as a forecast of how many people will enter. It counts everyone in the workspace who matches right now. Who actually enters still depends on the trigger firing for them.

​
Gate 3: exit rules

Exit rules remove a contact from the automation. Once they leave, they stop where they are and receive nothing else from it. They are evaluated before every step, and separately by a sweep that runs every 2 minutes across contacts parked in a Wait. That second pass is the important one: a contact who becomes eligible to leave in the middle of a three day wait is gone within about two minutes, not three days later. Exit rules are checked in order, and the first match wins.

​
Unsubscribes and spam complaints are always on

These two are not toggles. They cannot be switched off, and they are no longer shown as rows in the Exit rules card. In their place the card carries a single line:
Unsubscribes and spam complaints always stop marketing sends across the whole workspace, so they are not per-automation rules. A transactional automation is the one exception.
Why it works this way. Continuing to message someone who opted out or reported you as spam is a compliance failure, not a preference. Making it configurable per automation would mean one badly set automation could keep sending after a withdrawal. Israeli law requires an opt-out to be honoured, so this sits above the automation. Two details worth knowing:
  • The unsubscribe exit fires when the contact opts out of email or SMS, whichever channel this automation happens to use.
  • The spam complaint exit fires when they mark any of your messages as spam.

​
The transactional exception

An automation whose trigger is marked This is a transactional automation carries operational mail such as order updates, receipts and shipping notices. Those messages are not marketing, so:
  • The unsubscribe exit is skipped. A customer who opted out of marketing still gets told their order shipped.
  • The spam complaint exit still applies. That is an abuse signal, not a marketing preference.
Turning the transactional flag on is restricted to a workspace owner or admin and is confirmed with a legal warning. Turning it off is open to anyone who can edit the automation. Marking an advertising automation as transactional breaks Israeli anti-spam law.

​
Time in the flow

“After 30 days in flow” no longer exists. The old fixed 30 day toggle was retired and deliberately not carried over. If you had it on, it is off now and nothing has been draining out of your automations because of it. Use the rule below instead.
Time in the flow is an optional rule that removes a contact a set time after they entered.
  • It is off by default on every automation, old and new.
  • Units are hours, days or weeks.
  • The value can be 1 to 365 of that unit. It defaults to 30 days when you switch it on.
This removes contacts who are still waiting on a later step. If your automation has a 14 day wait and you set the exit to 7 days, nobody ever reaches the step after that wait. Keep the window longer than the automation’s own waits.

​
Custom exit filter and exit segments

Below the time rule you get the same condition builder as the profile filters, plus a segment picker labelled Exit when in segment. These are combined with OR, and OR against each other. A contact leaves as soon as the custom filter matches or they are in any one of the chosen segments. This is the opposite of the profile filters, which narrow with AND. Leave both empty and there is no custom exit. The two locked consent rules still apply.

​
Event conditions

“What someone has done” conditions appear in profile filters, in exit rules, in conditional splits and in a message step’s additional filters. They have three parts beyond the event itself.

​
How often

at least once

The event happened. No number needed.

zero times

The event never happened in the window. This is how you write “has not purchased”.

equals / doesn't equal

An exact count.

is at least / is greater than / is less than / is at most

A threshold count.
“Zero times” ignores any number beside it. It asks whether the event happened at all, so a count would be a control that changes nothing. That is why the number box disappears when you pick it.

​
What gets counted

For Ordered a product you can choose what a count actually counts. The three modes answer genuinely different questions about the same basket: order lines is the default and is what every filter saved before this option existed still means. Only events that carry the underlying data offer the choice, so the control does not appear on events where it would silently do nothing.

​
Over what period

Months are calendar accurate. Three months back from 31 March is 28 or 29 February, not 90 days.

​
”Since starting this flow”

This timeframe is only available inside an automation. A segment will not accept it, because a segment has no enrollment to measure from. It is the correct way to write an exit rule like “has placed an order since entering this automation”, which is what makes an abandonment sequence stop for someone who actually buys.
It is meaningless in the entry profile filter. At the moment someone enters, nothing has happened since they entered, so a “did X since starting this flow” condition is always false at entry and a “did not do X” condition is always true. Use it in exit rules, in conditional splits and in a message step’s additional filters, where time has actually passed.
If the anchor cannot be resolved, the window collapses to “nothing has happened yet” rather than widening to all time. It fails closed on purpose. A rule that quietly means “ever” would exit people it should not.

​
Placing an order force-exits cart recovery

This one is built in and needs no configuration. When a completed order arrives from a connected store, Senderz immediately ends that contact’s active enrollments in every automation triggered by Added to cart or Checkout started. A customer who buys stops receiving abandonment reminders, even if they are mid-wait and even if you wrote no exit rule.
It only covers those two triggers. A Browse abandonment automation built on Viewed product is not covered, so add your own exit rule there, such as “Placed an order since starting this flow”.

​
Per-step filters

A message step can carry its own Additional filters, narrowing who receives that one message. SMS, WhatsApp and Push steps additionally offer Exclude segments, so you can hold a message back from anyone in a chosen segment. They behave exactly like profile filters: a contact who does not match has that step skipped and moves on to the next one. They never remove anyone. Use them for a difference that only applies to one message. Use profile filters when the condition applies to the whole automation.

​
Add past profiles

Once an automation is live you can start eligible existing profiles at the top of it. Open Add past profiles from the automation. Choose the scope:
1

Pick who to add

Profiles from the last 30 days, profiles from the last 90 days, profiles since a specific date, or everyone currently on the trigger’s list. Profiles already added by an earlier backfill are excluded.
2

Estimate

Senderz counts the eligible profiles first so you can see the size before committing. The count is rechecked when you confirm, and if it has moved you are asked to review it again.
3

Confirm

Added profiles enter at the first step and can receive real email or SMS. Profile filters and exit rules, consent and suppression, quiet hours and Shabbat safeguards, and Smart Sending all still apply to every message.

​
How backfill interacts with “since starting this flow”

A backfilled enrollment is anchored to when the original event actually happened, not to the moment you ran the backfill. This matters. If it were anchored to the backfill time, an exit rule reading “has placed an order since starting this flow” would find no orders for anyone, because none of them could have bought in the last few seconds. Every customer who already completed their purchase weeks ago would be pushed into an abandonment sequence and mailed about a cart they long since checked out. Two consequences to plan for:
  • Your “already converted” exit rules work on a backfill. You do not need a different rule for backfilled contacts.
  • A short “since starting this flow” window can exit backfilled contacts immediately. Someone whose original event is 60 days old is measured from 60 days ago, so a rule that looks at recent behaviour may match at once. That is usually what you want, but it means a backfill can add fewer people than the estimate suggested.
For Added to cart and Checkout started backfills, Senderz also drops any candidate whose order came after their abandonment before the backfill starts, so known buyers are filtered out up front.

​
Common setups

Trigger on Added to cart. Add an exit rule: Ordered a product, at least once, since starting this flow. The built-in force exit already covers orders that arrive through a connected store, and this rule covers everything else.
Do not filter this in the profile filters. Use a trigger filter on the order trigger: Only when order amount is at least your threshold. That way the contact never enters, rather than entering and skipping every step.
Build two automations, each triggered on Submitted a review with its own Only when rating condition: one for 4 and above, one for 3 and below. Two triggers on the same entry point will not work here, because both feed the same steps and nothing downstream can tell which one fired.
Add an exit rule using an exit segment such as your customers segment. Anyone who joins that segment leaves the automation within about two minutes, even while they are parked in a Wait.
Turn on Time in the flow and set it comfortably longer than the sum of the waits in the automation. It catches contacts stuck for reasons you did not anticipate without cutting anyone off mid-sequence.

Flows and automation

Triggers, steps, publishing and the execution model.

Segments

Build the saved audiences you pick in profile filters and exit segments.

Consent

What subscribed, unsubscribed and never subscribed mean, and how opt-outs are recorded.

Quiet hours and Shabbat

The send windows that still apply to every message an automation sends.