Boolean Operators are simple in concept and easy to get wrong in practice. The patterns below cover the surfaces where Salesforce admins and developers spend most of their time.
- Write down the business rule in plain English
Before opening the formula editor, write the rule out: Only when X and either Y or Z but not W. The plain English version is the contract; the formula is the translation.
- Translate to the right surface syntax
Validation rule formulas use AND(), OR(), NOT(). Flow decisions use All/Any/Custom Logic. SOQL uses infix AND/OR/NOT. Apex uses &&/||/!. The semantic rule is the same; the syntax varies.
- Add parentheses for any non-trivial expression
Whenever AND and OR mix in the same expression, group with parentheses. Operator precedence works but is the source of most reading-bugs.
- Handle NULL explicitly
When a referenced field can be blank, combine ISBLANK or null checks with the Boolean Operators. Three-valued logic silently breaks formulas that assume NULL is false.
- Test against representative records
Boolean Operators are easy to get logically wrong. Test the rule against records that should match and records that should not. The test plan catches the parentheses bug that pure inspection misses.
- Missing parentheses change meaning silently. AND(A, OR(B, C)) differs from OR(AND(A, B), C); always group complex logic.
- Default filter-row AND in reports is the most common report-builder mistake. Set Custom Filter Logic when the rule actually requires OR.
- NULL behaves as three-valued logic. AND(true, null) is null, not true; reliance on Boolean-only thinking produces wrong answers.
- Apex && short-circuits, but formula AND() evaluates both arguments. Performance differences matter on heavy formulas with side effects.