With the Summer ’26 release, Salesforce is piloting FORMULA() in SOQL WHERE clauses, enabling you to filter rows using compiled formula expressions instead of adding one-off formula fields or post-processing in Apex. This helps developers reduce schema clutter, simplify queries, and write less “query everything, filter later” code, particularly for ISVs working across customer schemas.
In this post, you’ll learn the basic syntax and mental model, typical use cases (including e‑commerce examples), and pilot gates and current constraints, so you can try it safely in a sandbox.
The pilot is open to any Salesforce customer — contact your Salesforce Account Executive or Customer Success Manager to request access.
Why use FORMULA() in SOQL WHERE?
When a filter depends on something that you calculate from fields, such as margin, revenue per head, days idle, or days late to ship, the usual choices are: add a formula field, maintain a duplicate rule in Apex, or query too many rows and throw away what you do not need.
FORMULA('…') in WHERE is for the case where the rule belongs with the query: you describe the computed condition once, the platform evaluates it as part of filtering, and callers (Apex, APIs, downstream jobs) get a smaller, already qualified result set. This is especially valuable when you can not or do not want to change the data model for every subscriber org, a common scenario for ISVs or developers who want to keep operational segmentation logic visible in SOQL instead of buried in loops.
For example, say you’re working with an Order__c object and need to find every order where profit (revenue minus cost) exceeds $150. Without FORMULA(), the rule lives in Apex after a broader query; with FORMULA(), the rule moves into the WHERE clause itself.
For example, say you’re working with an Order__c object and need to find every order where profit (revenue minus cost) exceeds $150. Without FORMULA(), the rule lives in Apex after a broader query; with FORMULA(), the rule moves into the WHERE clause itself.
The formula expression supports addition and subtraction (+ and -). Expressions can evaluate to DOUBLE, INTEGER, DATETIME, DATE & CURRENCY.
In practice:
INTEGERbehaves likeDOUBLEDATEbehaves likeDATETIME
So the rest of this post focuses on the three illustrative types: DOUBLE, DATETIME, and CURRENCY.
This pattern fits Apex and SOQL developers, ISV teams shipping logic across subscriber orgs where schema changes are hard, and anyone trying to move off the “query a large candidate set, filter in code” approach.
Beyond fitting that audience, FORMULA() in WHERE matters today because it:
- Eliminates unnecessary formula fields
- Reduces Apex complexity
- Improves performance by filtering at the query level
- Is especially valuable for ISVs who can’t modify customer schemas
Syntax: FORMULA() in WHERE
Today, FORMULA() in SOQL is available as a pilot capability: it is only supported in the WHERE clause (not HAVING).
The general shape is:
WHERE FORMULA('…') <operator> <literal>
The string is a formula expression evaluated for each row as part of filtering.
Example: E-commerce order management
Imagine that you’re building an order analytics dashboard for a growing e-commerce platform.
Your custom Order__c object tracks:
Revenue__c(Currency): Total order valueCost__c(Currency): Fulfillment costOrderDate__c(Date): When customer placed orderShipDate__c(Date): When order shippedStatus__c(Text): Order status
Previously, filtering orders by calculated metrics meant either:
- Creating formula fields like
Profit__c,ShippingDelay__c,ProfitMargin__c - Querying all orders and filtering in Apex loops
Let’s see how FORMULA() eliminates both.
The screenshot below shows a Sample Order__c records table that includes seven orders (ORD-001 through ORD-007) with Revenue, Cost, OrderDate, ShipDate, and Status columns used throughout the FORMULA() examples.
Three key use cases
For our e-commerce example, FORMULA() is particularly helpful in the following three use cases:
- Find high-profit orders using currency arithmetic.
- Detect late shipments using datetime arithmetic.
- Filter by premium order criteria using combined conditions.
1. Find high-profit orders (CURRENCY arithmetic)
Our business requirement for this first use case is to identify orders with profit > $250 for priority fulfillment review.
The old way
The new way
The following screenshot shows a SOQL query using the FORMULA() function to filter orders by profit: SELECT Id, Name, Revenue__c, Cost__c FROM Order__c WHERE Status__c equals “Shipped” AND FORMULA('Revenue__c - Cost__c') is greater than 250.Query results show three records: ORD-001 with 500 revenue and 200 cost, ORD-003 with 800 revenue and 300 cost, and ORD-005 with 1200 revenue and 400 cost.
2. Detect late shipments (DATETIME arithmetic)
Our business requirement here is to find orders that shipped more than three days after order date for SLA analysis.
The screenshot below shows a SOQL query using the FORMULA() function to calculate shipping delays: SELECT Id, Name, OrderDate__c, ShipDate__c FROM Order__c WHERE FORMULA('ShipDate__c minus OrderDate__c') greater than three. Query results display two records: ORD-002 ordered April 5 and shipped April 12, and ORD-005 ordered April 15 and shipped April 25, both exceeding the three-day shipping threshold.
3. Premium order criteria (combined conditions)
Our business requirement for the third use case is to find “premium” orders: high revenue (> $600) AND fast shipping (≤ 2 days).
The screenshot below shows a SOQL query combining standard field filter with the FORMULA() function: SELECT Id, Name, Revenue__c, OrderDate__c, ShipDate__c FROM Order__c WHERE Revenue__c is greater than 600 AND FORMULA('ShipDate__c minus OrderDate__c') is less than or equal to two. Query results show two records: ORD-003 with 800 revenue, ordered April 10 and shipped April 11, and ORD-007 with 650 revenue, ordered April 20 and shipped April 21, with both records meeting the high-revenue and fast-shipping criteria.
Conclusion
By applying the ideas in this post, you can express computed filters directly in SOQL. FORMULA() in WHERE turns the question from “what rows might be relevant?” into “what rows already match my computed rule?” with less schema churn. This tends to shrink Apex branching, reduce one-off formula fields for query-only rules, and make the business condition readable next to the SELECT, which helps both integrations and teams reviewing SOQL in code review and operations.
Beyond individual queries, the same pattern reinforces a broader habit: keep data access and the rule that defines “the right rows” together, so batch jobs, services, and packaged logic stay easier to maintain, especially when subscriber org schemas are not yours to reshape at will. As always, treat what you validate in a non-production org as the contract for syntax, supported types, and supported operators.
We would love your feedback on the capabilities of this pilot, and your comments will influence the GA release. Please post your questions and/or feedback on the Pilot to the Salesforce Developers Trailblazer Community. Just let us know!
Resources
- Pilot enrollment: Contact your Salesforce Account Executive or Customer Success Manager to request access to the SOQL
FORMULA()pilot - Trailhead: SOQL for Admins – Create SOQL Queries to get data from your Salesforce org
About the author
Dikshita Patel is a Software Engineer on Salesforce’s Enterprise API team, where she builds Platform APIs allowing developers, partners, and customers to query and access Salesforce data without using the Salesforce user interface. You can follow and connect with her on LinkedIn.