> ## Documentation Index
> Fetch the complete documentation index at: https://docs.senderz.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Who enters and who leaves
> The three separate gates on an automation: trigger filters on the event, profile filters on the person, and exit rules that remove someone mid-flow.
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.
| Gate | Asks about | Runs when | On a non-match |
| --------------- | ---------------------------- | ----------------------------------------------- | ---------------------------------------------- |
| Trigger filters | The event that just happened | Once, as the event arrives | The contact never enters |
| Profile filters | The person | At entry, then again before every action step | The step is **skipped**, the contact stays in |
| Exit rules | The person | Before every step, plus a sweep every 2 minutes | The contact **leaves** the automation for good |
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:
| Category | What it covers |
| ------------------------------- | ----------------------------------------- |
| Properties about someone | Name, email, tags, custom fields |
| Can or cannot receive marketing | Email, SMS, push or WhatsApp consent |
| What someone has done | Orders, product views, checkouts and more |
| Is in or not in a list | Membership of one of your lists |
| Predictive analytics | Purchase, churn and VIP likelihood |
| Country | The contact's country |
| Within the EU (GDPR) | Is or is not in an EU or EEA country |
| Random sample | A stable percentage of profiles |
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
The event happened. No number needed.
The event never happened in the window. This is how you write "has not
purchased".
An exact count.
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:
| Mode | A single order of 4 shirts and 1 hat counts as |
| --------------- | ---------------------------------------------- |
| **order lines** | 2 |
| **units** | 5 |
| **orders** | 1 |
**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
| Timeframe | Meaning |
| ---------------------------- | --------------------------------------------------------- |
| **over all time** | No time limit |
| **in the last** | A rolling window in hours, days, weeks or months |
| **before** | Everything up to a date |
| **after** | Everything from a date onward |
| **between dates** | A fixed range. An end date includes the whole of that day |
| **since starting this flow** | From the moment this contact entered this automation |
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:
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.
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.
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.
## Related
Triggers, steps, publishing and the execution model.
Build the saved audiences you pick in profile filters and exit segments.
What subscribed, unsubscribed and never subscribed mean, and how opt-outs
are recorded.
The send windows that still apply to every message an automation sends.