Conditions in automations: AND and OR in practice

You create an automation to move a card when a field is updated. It works. But you soon notice it fires in cases it shouldn't: the field was filled in, but other critical information was missing. Or the rule should apply to two different request profiles, and you ended up creating two separate automations to do the same job.

Multiple conditions exist exactly to close this gap. By the end of this article, you'll know when to use AND (more conditions in the same group) and when to use OR (different condition groups), and how to apply each logic to real approval and notification processes.

📖 What you'll understand here:

Why a simple automation sometimes isn't enough

An automation with no condition is an unconditional instruction: whenever X happens, do Y. For many cases, that solves it. But when the process has business rules, an automation with no condition becomes noise.

Think of a purchasing process. You want to automatically move a request to the management approval phase, but only when the amount exceeds a specific limit. Without a condition, every request goes to management approval, regardless of amount. The manager gets irrelevant notifications and starts ignoring them.

The same happens with segmented notifications: if you want to alert different teams depending on the type of request, a single rule with no condition will notify everyone all the time.

AND and OR in the context of the process

The distinction between AND and OR in Pipefy isn't abstract boolean logic. It's the difference between two types of business rule.

AND: my rule requires everything to happen at the same time

You add more conditions inside the same group. The automation only fires when the card meets all of them simultaneously.

Example: automatically approve a purchase request only when the amount is under $5,000 AND the supplier is already registered. If either of the two conditions isn't true, the automation doesn't run. This avoids approving requests from unregistered suppliers, even if they're within the amount limit.

OR: it's enough for one case to be true

You create separate condition groups. The automation fires if the card meets at least one of the groups.

Example: notify the compliance team when the request is high value OR when the supplier is international. These are two different risk profiles. Either one, on its own, already justifies the notification.

Example 1: conditional approval by amount and profile

Reference process: Purchase Request.

The finance team wants a two tier approval flow:

• Requests under $5,000 from already registered suppliers: automatic approval by the analyst.
• Requests over $5,000 or from unregistered suppliers: forward to manager approval.

For the first case: event "a field is updated" on the amount field. In the same condition group, add: amount under 5,000 AND supplier equal to "registered". Action: move the card to the "Analyst approval" phase.

For the second case: create a second automation. Group 1: amount over 5,000. Group 2 (separate): supplier equal to "not registered". Action: move the card to "Management approval" and notify the manager by email.

The result: the volume of management approvals drops because the screening happens automatically. The manager only receives what genuinely needs their attention.

Example 2: notifications segmented by request profile

Reference process: Employee onboarding.

The HR team wants each area to receive notifications only about what falls under its responsibility:

• IT: when the card enters the "Access" phase and the "role" field equals "developer" OR "systems analyst".
• Facilities: when the card enters the "Access" phase and the "work mode" field equals "on site".

For IT: event "card enters a phase" (Access). Group 1: role equal to "developer". Group 2 (separate): role equal to "systems analyst". Action: notify the IT team's channel.

For Facilities: same phase, single group with the condition "work mode equal to on site". Action: notify Facilities.

What this solves: each team stops receiving alerts that aren't under its purview. Trust in notifications increases because they arrive with context.

How to debug conditions that don't fire as expected

When an automation with conditions doesn't run, the three most common problems are:

The referenced field wasn't filled in yet when the trigger fired

If the event is "card enters a phase" but the field is filled in afterward, the condition has already been evaluated as false. Solution: change the event to "a field is updated" on the relevant field.

The condition uses "equals" but the value has spelling variation

"Developer" and "developer" may not be equivalent depending on the field type. Prefer selection fields (select, radio) over free text fields when you need to use conditions.

The condition groups are inverted

You set up AND where you wanted OR, or vice versa. Before saving, read it out loud: "should the automation fire when A and B happen together, or when A or B happen separately?"