Salesforce Formula Operators & Functions: The Ones You’ll Actually Use
Salesforce catalogs more than 90 formula functions, but a small, predictable set covers nearly every formula field, validation rule, and flow condition you’ll ever write.
Most production Salesforce formulas draw from a small core: IF() and CASE() for branching, AND()/OR()/NOT() (or their && / || symbol equivalents) for logic, ISBLANK() and BLANKVALUE() for null handling, the & operator or CONCATENATE() for text, and TEXT() to convert non-text values. Everything else in the function reference is situational.
Why a Small Set of Functions Covers Most Formulas
The official Salesforce formula operators and functions reference lists dozens of functions spread across math, logical, text, date/time, summary, and advanced categories — and, unless a function’s documentation says otherwise, every one of them works the same way in a formula field, a validation rule, or an approval process criteria formula. That consistency is useful, but it also makes the reference feel bigger than it needs to be for day-to-day work.
In practice, admins configuring formula fields, building validation rules, or writing flow formula resources reuse the same handful of building blocks: something to branch on a condition, something to test whether a value exists, something to combine text, and something to convert one data type into another. The rest of the catalog — date math, VLOOKUP, regular expressions, geolocation — gets pulled in only when the requirement calls for it.
This brief focuses on that core set and the distinctions that trip people up. For the full mechanics of building formula fields — the formula editor, syntax checking, and field-level considerations — see the complete guide to Salesforce formula fields.
Logical Operators and Functions: IF, CASE, AND/OR/NOT
IF(logical_test, value_if_true, value_if_false) handles a single two-way branch — the default choice when a formula needs to return one of two outcomes based on one condition.
Once a formula needs more than two outcomes, CASE() is usually more readable than nesting several IF() statements. Its syntax is CASE(expression, value1, result1, value2, result2, ..., else_result): Salesforce compares expression against each value in order and returns the matching result, falling back to else_result if nothing matches — and a blank field also falls through to else_result.
CASE() only performs exact-match comparisons — it cannot evaluate ranges or inequalities. A formula that needs to test “greater than” or “between” two numbers still needs nested IF() statements; CASE() is for matching a field against a fixed list of discrete values, such as a picklist.
AND(), OR(), and NOT() combine or negate boolean conditions, and Salesforce also supports the symbol equivalents && for AND and || for OR. Both forms evaluate identically — the choice is usually about formula length and readability, not behavior, and validation rules with several compound conditions often favor the symbols to keep the expression shorter. Trailhead’s Use Logic in Formulas module walks through both forms with worked examples.
Null-Handling: ISBLANK, ISNULL, and BLANKVALUE
ISBLANK(expression) returns TRUE when a field has no value. Critically, it supports text fields as well as number, date, and other field types. ISNULL() looks similar but does not reliably evaluate text fields — Salesforce keeps it for backward compatibility, but ISBLANK() is the safer general-purpose choice, including on formulas that mix field types.
The ISBLANK() vs. ISNULL() distinction — text-field support — is one of the most commonly tested formula details across the admin and app-builder tracks. When in doubt, or when the formula could ever touch a text field, use ISBLANK().
BLANKVALUE(expression, substitute_expression) goes a step further: instead of just testing for a blank, it returns a fallback value in its place, which is useful for formulas that display a default label when a related field hasn’t been populated yet.
Number, currency, and percent fields referenced in a formula carry their own blank-handling setting in the formula editor: Treat blank fields as zeros or Treat blank fields as blanks. If a formula is set to treat blanks as blanks and it performs arithmetic on a field that’s genuinely empty, the whole result can return blank instead of a number — a frequent cause of formula fields that look “broken” on records with incomplete data.
Text Operators: & vs. CONCATENATE(), Plus TEXT()
The & operator is the shorthand way to join text values — FirstName & " " & LastName, for example. CONCATENATE() is the function form of the same operation and takes the same text operands as arguments; the two are interchangeable, and which one you reach for is mostly a matter of formula style.
Both only accept text operands directly. To fold a number, date, currency, or single-value picklist into a concatenated string, convert it first with TEXT(value). TEXT() is supported for picklists specifically inside formula fields, validation rules, and several automation contexts — but not for multi-select picklists, where ISPICKVAL() or a CASE() statement is the correct tool instead.
| Operator / Function | Category | Typical Use Case |
|---|---|---|
IF() | Logical | Single two-way branch (default vs. override values) |
CASE() | Logical | Exact-match branching on a picklist or fixed value set |
AND() / && | Logical | Compound “all must be true” validation rule criteria |
OR() / || | Logical | Compound “any can be true” validation rule criteria |
NOT() | Logical | Negating a boolean condition |
ISBLANK() | Null-handling | Required-field checks across text and non-text fields |
BLANKVALUE() | Null-handling | Fallback text when a field is empty |
& / CONCATENATE() | Text | Joining text values (e.g., name or address fields) |
TEXT() | Text | Converting a number, date, or picklist to text for concatenation |
ROUND() | Math | Rounding a calculated currency or percentage value |
TODAY() | Date/Time | Date-based calculations (age, day counts, SLAs) |
When You’ll Need the Rest
Outside this core set, the functions worth knowing exist for narrower jobs: date math like ADDMONTHS() and DATE() for anniversary or SLA calculations, math functions like MOD() and ABS() for numeric edge cases, and VLOOKUP() for pulling a value from another object — but only inside validation rules, where it’s supported. Summary functions such as PARENTGROUPVAL() live in a different world entirely: they only work inside summary, matrix, and joined reports, not on records directly.
None of these require memorizing syntax up front. The pattern that matters is recognizing which category a requirement falls into — branching, null-checking, text assembly, or type conversion — and reaching for the function built for that job rather than reinventing it with nested nested logic.
High-Yield Facts
- ISBLANK() vs. ISNULL(): only
ISBLANK()reliably evaluates text fields;ISNULL()is kept for backward compatibility. - CASE() is exact-match only: it cannot test ranges or inequalities — use nested
IF()for those. - && and || are symbol equivalents of
AND()andOR()— identical behavior, shorter syntax. - Blank-handling setting: number/currency/percent fields in a formula can be set to treat blanks as zero or as blank — this changes whether the whole formula result can go blank.
Test Your Knowledge
Practice scenario questions on formula logic, validation rules, and the trap concepts exams love to test.
Practice Scenario Questions on FormulasVerified against the official Salesforce Summer ’26 Formula Operators and Functions reference and Help & Training documentation. Function behavior is generally consistent across releases, but always confirm edge-case behavior against the current release notes before relying on it in production. Study smarter at CertifySF.com.