Conditions in a view: all and any

Views, triggers and automations all use two condition blocks. Understanding how they combine prevents most rules that never fire.

Views, triggers and automations all use two condition blocks. Understanding how they combine prevents most rules that never fire.

The two blocks

• Meet all of the following. Every condition here must be true. These narrow.
• Meet any of the following. At least one must be true. These widen.

Use both and the ticket must satisfy all of the first block and at least one of the second.

The mistake that produces an empty view

Putting alternatives in the all block. "Status is Open" and "Status is Pending" both in the all block asks for a ticket that is simultaneously Open and Pending, which no ticket is. It belongs in the any block.

The reverse mistake is subtler: putting a genuine requirement in the any block, where a single other match lets tickets through that you meant to exclude.

Grouping several alternatives

There is only one any block, so two independent sets of alternatives cannot be expressed directly. When you need that, the usual answer is a tag: a trigger sets the tag when the first set of conditions is met, and the view or rule then simply checks for the tag. Less elegant, but readable months later, which matters more.

Test with the preview

Views preview live tickets before you save. Use it. Conditions that read correctly in English regularly do not mean what you assumed, and the preview is the fastest way to find that out.

See also

• My view shows no tickets: what to check
• Building conditions: all, any, and the trap in between
• What tags are and what you use them for