Boolean Operators
Boolean operators are the logical connectives AND, OR, and NOT that join two or more conditions into a single true-or-false expression.
Definition
Boolean operators are the logical connectives AND, OR, and NOT that join two or more conditions into a single true-or-false expression. In Salesforce they sit at the heart of almost every place the platform tests a condition: validation rule formulas, formula fields, Flow decision elements, report and list view filters, SOQL WHERE clauses, SOSL searches, and approval process entry criteria. The meaning matches ordinary Boolean algebra. AND is true only when every joined condition is true. OR is true when at least one condition is true. NOT flips a true to false and a false to true.
The reason these three small words matter so much is that they turn a flat list of conditions into an actual business rule. "Stage equals Closed Won and Amount is greater than 100000" is two checks joined by AND. "Industry is Healthcare or Industry is Life Sciences" is two checks joined by OR. The catch in Salesforce is that each surface writes the same logic with different syntax. Formulas use function calls like AND() and OR(). SOQL and Flow use the words spelled out. Apex uses the symbols && and ||. The logic is identical, but the grammar shifts, so knowing the operator across every tool is a foundational admin and developer skill.
Where AND, OR, and NOT show up across Salesforce
Formula syntax: AND(), OR(), NOT()
Validation rules and formula fields wrap Boolean operators as functions rather than writing them between conditions. You call AND(logical1, logical2, ...) which returns true only when every argument is true. OR(logical1, logical2, ...) returns true when at least one argument is true. NOT(logical) returns the opposite of whatever it receives. Salesforce also supports the symbol shortcuts && for AND and || for OR, so AND(A, B) and A && B do the same thing. Most teams keep one style per formula for readability. A real validation rule might read AND(ISPICKVAL(StageName, "Closed Won"), Amount > 100000) to block a high-value win that is missing required data. You nest functions to build any shape of logic: AND(OR(A, B), NOT(C)) is perfectly legal. Because the function form puts the operator first and the conditions inside parentheses, the grouping is explicit and hard to misread. That clarity is one quiet advantage of the formula syntax over the spelled-out style used elsewhere. The official Formula Operators and Functions reference lists every operator and its return behavior.
SOQL WHERE clauses and Apex code
SOQL writes the operators as words inside the WHERE clause, the same way classic SQL does. A query like SELECT Id FROM Account WHERE Industry = 'Technology' AND AnnualRevenue > 1000000 keeps only the rows that pass both tests. OR widens the result set, and NOT excludes matches. The Salesforce SOQL reference is explicit on one rule: you must add parentheses whenever you mix AND and OR in the same WHERE clause, because the platform will not guess your intended grouping. Apex, the platform's programming language, uses the C-style symbols instead: && means AND, || means OR, and ! means NOT. So if (isClosed && amount > 100000) in Apex expresses the same idea as the SOQL words. Apex also short-circuits, meaning && stops at the first false and || stops at the first true, which can save an expensive method call on the right side. The two surfaces look different on the page, yet they evaluate logic in exactly the same order once you account for precedence and grouping.
Flow decision elements
Flow gives admins a point-and-click way to combine conditions without typing a formula. Inside a Decision element, or any element that filters records, you pick a Condition Requirements setting. All Conditions Are Met joins every row with AND. Any Condition Is Met joins them with OR. Custom Condition Logic lets you type a free-form expression that references each condition by its row number, such as 1 AND (2 OR 3). That third option is how declarative builders express anything more complex than pure AND or pure OR. The row numbers map to the conditions listed above the logic box, so condition 1 is the first row, condition 2 the second, and so on. Record-triggered flows reuse the same model for their entry conditions, and screen components reuse it for conditional visibility. Getting comfortable with Custom Condition Logic is what separates a Flow that almost works from one that fires on exactly the right records. The Salesforce Help topic on defining conditions in a Decision element walks through each setting.
Report and list view filters
Reports and list views combine their filter rows with AND by default. Add three filters and a record must satisfy all three to appear. That default is fine until your rule actually needs an OR, and this is one of the most common places admins get a surprising result. Reports expose a Filter Logic field where you can override the default with a custom expression using the same row-number style as Flow, for example 1 AND (2 OR 3). You can also use NOT to exclude a block of conditions. A report that should show open opportunities in either of two regions needs OR, and without setting the filter logic it silently returns nothing because the rows are still being joined by AND. List views support filter logic in the same way on most objects. The practical habit is simple: the moment a report rule contains the word "or" in plain English, open the Filter Logic field and write the grouping out by hand rather than trusting the default.
Searches with SOSL
Salesforce Object Search Language, or SOSL, runs text searches across multiple objects, and its FIND clause accepts Boolean operators too. A query like FIND {Acme AND Corp} returns records that contain both words, while FIND {Acme OR Corp} returns records with either. SOSL also supports AND NOT to exclude a term. Quoted phrases bind together as a unit, and parentheses group terms for anything non-trivial. The Salesforce reference shows complex examples such as searching for ("Bob" AND "Jones") OR ("Sally" AND "Smith") to match either full name. The grouping rules matter here as much as in SOQL: without parentheses, a mix of AND and OR can match far more or far less than you expect. Global search in the Salesforce UI sits on top of this engine, so the same logical thinking helps when you are building search-driven features or troubleshooting why a search returns the wrong set of records. The behavior is consistent with the rest of the platform: combine carefully and group explicitly.
Three-valued logic and NULL
The single biggest source of Boolean surprises in Salesforce is how empty fields behave. Many surfaces treat a blank field as neither true nor false, a third state often called null or unknown. This mirrors the three-valued logic of SQL. In a formula, AND(true, null) evaluates to null rather than true, OR(true, null) is true, and NOT(null) stays null. The practical effect is that a formula written as if a missing value were simply false can quietly return the wrong answer. The fix is to test for emptiness directly. Wrap the field in ISBLANK() or ISNULL() so the formula has a real true-or-false to work with, for example AND(NOT(ISBLANK(Email)), Amount > 0). In SOQL, a field that is null is excluded by an equality test, which can drop rows you expected to see. Whenever a field can legitimately be empty, plan for the null case explicitly instead of assuming the comparison falls through to false. This one habit prevents a large share of "the rule looks right but does the wrong thing" bugs.
Parentheses, precedence, and common mistakes
Operator precedence decides what happens when you do not add parentheses, and relying on it is the most common reading bug in Salesforce logic. In most languages NOT binds tightest, then AND, then OR, so A OR B AND C is read as A OR (B AND C), not (A OR B) AND C. Those two readings can produce completely different results on the same data. The safe rule is to add parentheses any time AND and OR appear together, which both SOQL and the formula reference effectively require. Three mistakes recur. First, missing parentheses change meaning silently and nobody notices until a wrong record slips through. Second, mixing AND and OR without grouping produces logic that no longer matches the plain-English intent. Third, leaning on the default AND join in reports when the rule actually needs OR returns an empty or wrong result set. The cure for all three is the same: write the rule in plain words first, group it explicitly, then test it against records that should match and records that should not.
Trust & references
Cross-checked against the following references.
- Logical Operators (SOQL and SOSL Reference)Salesforce
- All Formula Operators and FunctionsSalesforce
Straight from the source - Salesforce's reference material on Boolean Operators.
Hands-on resources to go deeper on Boolean Operators.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Which three connectives are the main Boolean Operators in Salesforce?
Q2. How does a Flow Decision combine Boolean logic like condition 1 AND (2 OR 3)?
Q3. Why must Boolean Operators be paired with ISBLANK or null checks when fields can be empty?
Discussion
Loading discussion…