Conditions

Filters were the bouncer at the door - broad checks about where and who. Conditions are the detailed inspection that happens next.

This is where you ask specific questions about what actually happened: does the message contain this word? Does this person have that role? Is this channel named something in particular?

Your goal with conditions is simple: make sure only the events you actually care about reach your actions.

1. The condition collection

Conditions don't sit loose in your feature - they live inside a condition collection.

Each collection contains four things:

Part	What it's for
My Values	Values you work out once and reuse. Covered on its own page
Conditions	The checks themselves, optionally grouped
If met actions	Actions that run when the checks pass
Otherwise actions	Actions that run when the checks fail

The most basic setup is: add your conditions, and leave everything else untouched. The defaults do the sensible thing - if the conditions pass, your feature carries on to its actions; if they don't, it stops.

That covers most features. The "If met / Otherwise" parts are there for when you want something more interesting, and they're explained in section 6.

You can have more than one collection. They're checked in order, top to bottom. For a first feature, one is plenty.

2. Every condition must pass

By default, when you add conditions, all of them have to pass before the event moves on to your actions. One failure and the feature stops there.

If a condition runs into an error - for example it checks a message that isn't there - it counts as not passed, and the reason is written to your feature's log.

3. AND and OR - the connector

Conditions are joined by a connector.

It's set to AND by default, and clicking it switches it to OR.

The difference is the whole game:

Connector	Passes when
AND	Every condition passes. All of them, no exceptions.
OR	At least one condition passes. The rest can fail.

AND makes your feature pickier. Each condition you add narrows it further.

OR makes it more accepting. Each condition you add is another way in.

AND example

Message contains "invoice" AND Message has an attachment

This only fires for messages that have both - the word and a file. A message saying "Here's the invoice" with nothing attached doesn't pass. Neither does a random screenshot with no text.

OR example

Message contains "invoice" OR Message has an attachment

This fires if either is true. You usually want AND in such case.

The connector applies to the whole group, not to one pair of conditions. Switching one connector switches them all in that group. If you need some conditions joined by AND and others by OR, that's what groups are for.

4. Groups

A group is a set of conditions with its own connector. You can have up to two groups per collection.

That gives you three connectors to set:

• The connector inside group 1

• The connector inside group 2

• The connector between the two groups

This is what lets you build things a single flat list can't express.

Why you need them

Say you want: messages about deals, but only in the deals channels.

Written as one flat list, it's impossible - you'd need "OR" between the deal words and "AND" between the words and the channels, and a flat list only has one connector.

With groups it's straightforward:

Group 1 (OR) Message contains "sale" OR Message contains "discount"

— AND —

Group 2 (OR) Channel is #deals OR Channel is #promos

Read it out loud: "(sale or discount) and (deals or promos)." A "sale" message in #general doesn't pass. A "hello" message in #deals doesn't pass. Only a deal word in a deal channel gets through.

Another example

"Tell me about messages that mention me from friends, and about anything marked urgent regardless of who sent it."

Group 1 (AND) Message mentions me AND Message is from a user on my whitelist

— OR —

Group 2 (AND) Message contains "urgent"

Read it out loud: "(mentions me and is from a friend) or (contains urgent)."

The trick for getting it right

Say your rule out loud in plain English first, then put the brackets where you naturally pause. Whatever's inside a bracket becomes a group, and the word at the pause becomes the connector between them.

• "(A or B) and C" → group 1 holds A and B joined by OR; group 2 holds C; between them, AND

• "A and (B or C)" → group 1 holds A; group 2 holds B and C joined by OR; between them, AND

5. What happens when conditions pass

Nothing dramatic - the event moves on to the next collection, and once all the collections are done, to your feature's final actions.

That's the whole basic flow:

Event → Filters → Conditions → Actions

If you never touch If met / Otherwise, that's all conditions ever do: let events through, or stop them.

6. Advanced - If met / Otherwise

Here's where a feature stops being a straight line.

By default, when your conditions aren't met, the feature just stops. Nothing runs. That's usually what you want.

But each collection can also carry its own actions, which run right there, before the feature's final actions:

• If met actions run when the collection passes

• Otherwise actions run when the collection fails

And each side has a setting for what happens afterwards.

The most important rule here: the action block always runs. If the collection passes, its "If met" actions run - full stop. The flow setting only decides what happens after those actions have finished. It never cancels them.

After "If met", you can choose:

Option	What happens next
Continue (default)	Move on to the next collection, as normal
Continue to final actions	Skip any remaining collections and jump straight to the feature's final actions
Stop	End the feature here. The final actions do not run

After "Otherwise", you can choose:

Option	What happens next
Stop (default)	End the feature here. The final actions do not run
Continue	Move on to the next collection anyway

Example 1 - a fallback message

"Only let approved people use this, and tell everyone else no."

Collection 1 Condition: user is on my approved list If met: (nothing) → Continue Otherwise: reply "Sorry, you're not on the list" → Stop

Final actions: do the actual thing

Approved people sail past the collection and reach the final actions. Everyone else gets the reply and stops. Without the "Otherwise" block they'd just get silence.

Example 2 - a command router

This is the pattern that makes multiple collections worth using.

Collection 1 Condition: message is exactly !weather If met: send the weather → Stop Otherwise: → Continue

Collection 2 Condition: message is exactly !time If met: send the time → Stop Otherwise: → Stop

One feature, two commands. Each collection checks for its own command, does its job, and stops so the next one never runs. The last "Otherwise → Stop" catches everything that matched neither.

Note that "Otherwise → Continue" in collection 1 is doing real work: it's what lets a !time message get past the weather check to reach collection 2. With the default (Stop), collection 2 would never be reached.

Example 3 - a shortcut for VIPs

Collection 1 Condition: user is on my VIP list If met: send a personal greeting → Continue to final actions Otherwise: → Continue

Collection 2 Conditions: the normal checks everyone else has to pass If met: → Continue Otherwise: → Stop

Final actions: log it to my private channel

VIPs get their greeting and jump straight to the logging, skipping the checks they don't need to pass. Everyone else goes through collection 2 the normal way. Both paths end at the same final actions, so the logging happens either way.

That's the difference between Stop and Continue to final actions: Stop ends everything, while Continue to final actions skips the remaining checks but still does the work at the end.

7. Two things to know

If met / Otherwise actions count as a run. As soon as one of those blocks actually has actions in it and gets executed, it counts against your execution limits, the same as a normal run would. A collection that passes but has an empty "If met" block doesn't count for anything on its own.

My Values are ready before the checks run. Any My Values in a collection are worked out first, before its conditions are evaluated - and they're worked out whether the collection ends up passing or failing. So your conditions, your "If met" actions and your "Otherwise" actions can all use them. They get their own page.