Operator
An operator in Salesforce is a symbol or keyword that defines how values are combined, compared, or evaluated inside expressions.
Definition
An operator in Salesforce is a symbol or keyword that defines how values are combined, compared, or evaluated inside expressions. Operators appear everywhere users build conditions or calculations: formula fields, validation rules, workflow criteria, Flow conditions, SOQL WHERE clauses, report filters, and SAQL queries in CRM Analytics. The exact syntax varies by context, but the categories stay consistent: math operators (+, -, *, /), comparison operators (=, !=, <, >, <=, >=), logical operators (AND, OR, NOT), string operators (& for concat), and the more specialized SOQL operators (LIKE, IN, INCLUDES).
Mastering operators is essential for anyone writing Salesforce automation. A misplaced equals sign in a validation rule blocks every record from saving. An ambiguous AND vs OR in a Flow condition routes users down the wrong branch. SOQL LIKE without proper wildcard placement returns zero rows. The platform exposes operators through pickers and editors that hide some of the syntax, but understanding the underlying language pays off whenever the picker cannot express what you need.
How operators work across Salesforce formulas, queries, and filters
Comparison operators in formulas and validation rules
Six core comparison operators exist: equal (=), not equal (!= or <>), less than (<), greater than (>), less than or equal (<=), greater than or equal (>=). All six work on numbers, dates, and datetime fields. Text fields can be compared with = and != but not with order operators (<, >). Picklist fields compare against literal text values; record types and lookup fields compare against IDs. The most common bug: using ! by itself instead of != produces a syntax error that the editor sometimes hides.
Logical operators: AND, OR, NOT
Validation rules and formulas use AND(condition1, condition2, ...), OR(condition1, condition2, ...), and NOT(condition) as functions. Flow conditions use the same logic but expressed through a UI with AND/OR dropdowns. SOQL uses inline AND, OR, NOT keywords with the same precedence as standard SQL (NOT binds tighter than AND, AND binds tighter than OR). Always use parentheses to make precedence explicit: AND(OR(a, b), c) is unambiguous; a OR b AND c is not.
String concatenation and text operators
Salesforce formulas use & for string concatenation: "Hello, " & FirstName & "!" returns "Hello, John!". The CONCATENATE function does the same thing in a wordier form. Apex uses + for concatenation. SOQL has no string concatenation operator; concatenation happens in the calling code. The LIKE operator in SOQL uses % as a wildcard for any sequence and _ for a single character; LIKE is case-insensitive.
Set membership: IN, NOT IN, INCLUDES, EXCLUDES
SOQL has IN and NOT IN for checking membership against a list: WHERE Status IN ("Open", "Pending", "Escalated"). For multi-select picklists, Salesforce uses INCLUDES and EXCLUDES because multi-select values are stored as semicolon-delimited strings: WHERE Industries INCLUDES ("Finance"). Formula fields use the CONTAINS function for similar semantics. Report filters expose IN as the equals operator with a comma-separated list, which can confuse new admins.
Math operators and the order of operations
Standard math: +, -, *, /, and ^ for exponentiation. Salesforce honors mathematical precedence: exponentiation first, then multiplication and division, then addition and subtraction. Use parentheses for any non-trivial expression. The most common mistake in currency calculations: forgetting that integer division in Apex truncates (5 / 2 returns 2, not 2.5). Cast to Decimal explicitly when dividing.
Special operators and edge cases
Several Salesforce-specific operators deserve attention. ISBLANK and ISNULL check for empty values, with slightly different semantics for text fields (ISBLANK treats empty strings as blank; ISNULL does not). PRIORVALUE returns the field value before a save, useful in validation rules that check whether a field changed. The colon operator in SOQL binds Apex variables: WHERE Id = :myId. The dot operator navigates relationships: SELECT Account.Name FROM Contact. Each has subtle gotchas; read the documentation when in doubt.
How to choose the right operator for a formula or query
Choosing the right operator means matching the data type, the context (formula vs SOQL vs Flow), and the semantics you actually need. Walk through the decision systematically.
- Identify the context
Formula field, validation rule, workflow rule, Flow condition, SOQL query, report filter, or SAQL? Each context has its own operator vocabulary; pick the right one before writing the expression.
- Identify the data type
Number, text, date, datetime, picklist, multi-select picklist, ID, boolean? Operators that work for numbers (<, >) often do not work for text. Multi-select picklists need INCLUDES, not =.
- Pick the operator that matches semantics
Are you comparing equality, ordering, set membership, pattern, or blankness? Equality uses =, ordering uses < or >, set membership uses IN, pattern uses LIKE, blankness uses ISBLANK.
- Wrap with parentheses for precedence
Mixed AND/OR conditions are ambiguous without parentheses. Always group explicitly. AND(OR(a, b), c) reads correctly; a OR b AND c is fragile.
- Test against edge cases
Null values, empty strings, dates at month boundaries, multi-select picklists with no selections, and negative numbers all expose operator bugs. Build test scenarios that hit each.
Compare two values for exact match. Default operator for most string and ID comparisons.
Compare numeric or date values. Does not work for text in most contexts.
Match a substring or wildcard pattern. LIKE in SOQL; CONTAINS in formulas.
Check if a value is in a list. IN for single-value fields; INCLUDES for multi-select picklists.
Combine conditions. Use parentheses to make precedence explicit.
Test for empty values. ISBLANK is the safer choice for text fields.
- Equals vs assignment is a classic bug. In formulas and SOQL, = is comparison. In Apex, = is assignment and == is comparison. Mixing them up causes silent errors.
- Multi-select picklists do not compare with =. Use INCLUDES and EXCLUDES, even though Salesforce sometimes lets = silently pass and return nothing.
- LIKE in SOQL is case-insensitive but column collation can change behavior. Test pattern queries in the actual context the production code uses.
- Operator precedence in formulas is not the same as in SQL or Apex. AND binds tighter than OR in formulas; in some contexts (Flow conditions), the engine evaluates conditions in source order. When in doubt, parenthesize.
Trust & references
Cross-checked against the following references.
- Formula Operators and FunctionsSalesforce Help
- SOQL Condition ExpressionsSalesforce Developers
Straight from the source - Salesforce's reference material on Operator.
- Formula Operators and Functions A-ZSalesforce Help
- Apex Expressions and OperatorsSalesforce Developers
Hands-on resources to go deeper on Operator.
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. What is an Operator?
Q2. Where are operators used?
Q3. What's a common operator pitfall?
Discussion
Loading discussion…