Salesforce Pilots FORMULA() in SOQL WHERE Clauses

Published 11/06/2026 & Updated 24/07/2026 · By James Winter

---

SOQL has always been good at filtering on stored field values, but less helpful when the condition itself is a calculation. Profit is revenue minus cost. Shipping delay is ship date minus order date. Until now, filtering on those results usually meant adding a formula field or retrieving a wider set of records and calculating the answer in Apex.

Salesforce is testing a different approach in Summer ‘26. FORMULA() in SOQL is a pilot function that places a quoted arithmetic expression inside a WHERE comparison, allowing the platform to filter on the calculated result.

That is an interesting direction for SOQL, particularly for query-specific rules and packaged applications that cannot freely change a subscriber’s schema. It is also early. The public contract is currently limited to a Summer ‘26 release note and a Salesforce Enterprise API team announcement, so this post focuses on what Salesforce has actually documented and what still needs testing.

Pilot means opt-in and subject to change

FORMULA() in WHERE is not generally available. Salesforce says the pilot applies to all editions, but enrolment is required and pilot terms apply. Contact your Salesforce account team or Customer Success Manager, use a non-production org, and avoid making a business-critical design depend on the current syntax.

📰 What Salesforce Announced

The useful part of this pilot is its query-specific placement: the calculation stays with the query that needs it. Salesforce describes the expression as being evaluated as part of filtering, so callers can receive records that already satisfy the calculated condition.

The published syntax is:

WHERE FORMULA('<arithmetic expression>') <comparison operator> <literal>

Salesforce currently documents addition and subtraction (+ and -) with these result types:

Result type	Published pilot behaviour
DOUBLE	Supported as a numeric result
INTEGER	Treated like DOUBLE
CURRENCY	Supported as a currency result
DATETIME	Supported for date/time arithmetic
DATE	Treated like DATETIME

The official examples demonstrate > and <= comparisons and combine a computed condition with an ordinary field filter using AND.

This is not the full formula language

Only + and - are documented. Do not assume support for multiplication, division, TODAY(), other formula functions, or text and Boolean results. The pilot is also WHERE only, not SELECT or HAVING, so the calculated value cannot be returned as a selected column.

🧩 Why Developers Might Care

When a filter depends on a calculated value, the established options each carry a trade-off:

• Create a formula field: reusable and dependable, but unnecessary metadata if only one query needs the result.
• Filter in Apex: flexible, but the query retrieves records that code may immediately discard.
• Filter downstream: moves the calculation to an integration or analytics process and transfers a wider dataset.

FORMULA() targets cases where the calculation belongs only to data retrieval. It could reduce one-off fields, keep filter logic visible in code review, and remove some post-query loops. This is particularly relevant for ISVs and integration developers working with schemas they do not control.

Fewer returned rows does not prove a faster query

Filtering inside SOQL can reduce records returned to Apex or an API client. Salesforce has not published an indexing, selectivity, or query-optimiser contract for the pilot, however. Measure timing and Query Plans with representative data before describing a FORMULA() query as a performance improvement.

🛒 Reproducing the Example in a Sandbox

Salesforce’s announcement uses an e-commerce order scenario. A custom object named Order__c can collide with Salesforce’s standard Order object, so this version uses the deliberately test-specific API name Formula_Test_Order__c.

Create the tutorial object without the naming collision

In Object Manager, create Formula Test Order with plural label Formula Test Orders and object name Formula_Test_Order (Salesforce adds __c). Set the Record Name to auto number, use display format ORD-{000}, and start at 1.

Add these custom fields:

Field	Type	Purpose
Revenue__c	Currency	Total order value
Cost__c	Currency	Fulfilment cost
OrderDate__c	Date	Date the customer placed the order
ShipDate__c	Date	Date the order shipped
Status__c	Text	Current order status

Then create the seven records used by the published examples:

Order	Revenue	Cost	OrderDate	ShipDate	Status
ORD-001	500	200	01 Apr	02 Apr	Shipped
ORD-002	400	250	05 Apr	12 Apr	Shipped
ORD-003	800	300	10 Apr	11 Apr	Shipped
ORD-004	300	150	12 Apr	14 Apr	Delivered
ORD-005	1200	400	15 Apr	25 Apr	Shipped
ORD-006	550	420	18 Apr	20 Apr	Delivered
ORD-007	650	450	20 Apr	21 Apr	Shipped

These records assume one currency, populated input fields, and date-only values. Nulls, multiple currencies, and DateTime boundaries belong in a separate edge-case test.

💰 Filter on Currency Arithmetic

To find shipped orders with profit greater than 250:

SELECT Id, Name, Revenue__c, Cost__c
FROM Formula_Test_Order__c
WHERE Status__c = 'Shipped'
AND FORMULA('Revenue__c - Cost__c') > 250

Against the sample data, this returns ORD-001, ORD-003, and ORD-005. Without the pilot, the same rule needs a formula field or a calculation after querying candidate records.

🚚 Filter on Date Arithmetic

To find orders that shipped more than three days after the order date:

SELECT Id, Name, OrderDate__c, ShipDate__c
FROM Formula_Test_Order__c
WHERE FORMULA('ShipDate__c - OrderDate__c') > 3

This returns ORD-002 and ORD-005. Salesforce uses the comparison to represent days, but has not documented fractional-day, time-zone, or daylight-saving behaviour for DateTime subtraction.

🔗 Combine Computed and Standard Conditions

To find orders with revenue above 600 that shipped within two days:

SELECT Id, Name, Revenue__c, OrderDate__c, ShipDate__c
FROM Formula_Test_Order__c
WHERE Revenue__c > 600
AND FORMULA('ShipDate__c - OrderDate__c') <= 2

This returns ORD-003 and ORD-007, demonstrating that the computed condition can sit beside an ordinary filter.

🧭 Where It Could Fit

The feature is not a replacement for formula fields. The important design question is whether the calculated value belongs in the data model or only in one query.

Approach	Best fit	Watch for
Formula field	The value is reused in reports, list views, page layouts, validation, or automation.	Adds metadata and becomes a maintained business definition.
FORMULA() in WHERE	The arithmetic is query-specific, fits the documented pilot scope, and the org is enrolled.	Pilot change risk and undocumented edge cases.
Apex or downstream filtering	The rule requires richer logic or the pilot is unavailable.	More records may cross the query boundary.

For durable SOQL design, the existing guides on filtering with WHERE, advanced filter logic, and query performance remain the stable foundation.

⚠️ What the Public Material Does Not Yet Answer

As at 24 July 2026, Salesforce has published enough to try the feature, but not enough to treat every formula-field assumption as valid in SOQL:

Area	Published	Still needs pilot testing
Placement	WHERE only, not HAVING	Other clauses and tooling support
Arithmetic	Addition and subtraction	Functions, multiplication, division, and nested complexity
Result types	DOUBLE, INTEGER, CURRENCY, DATE, DATETIME	Null propagation and mixed-type coercion
Dates	DATE behaves like DATETIME; the example subtracts dates as days	Fractional days, time zones, daylight saving, and precision
Currency	Currency expressions are supported	Multi-currency conversion and rounding
Query operations	Apex and API callers can receive filtered rows	Bind variables inside expressions, relationship references, indexing, and Query Plan behaviour

Treat anything in the right-hand column as a test question, not a platform promise. Recheck the release note and developer announcement after every Salesforce release.

💭 My Take: Promising, with Potential to Expand

My view is that FORMULA() is a genuinely useful and potentially very exciting addition to SOQL. Keeping a small, query-specific calculation inside WHERE solves a real problem: it can avoid creating a formula field solely to support one query, or retrieving rows only to discard them in Apex.

The pilot already addresses useful cases, but I would not redesign an established production solution around it yet. That caution comes from its pilot status, undocumented query-planning behaviour, and the open questions above, not from a lack of value in what it can do today.

If Salesforce expands the feature in future, one possibility could be returning a calculated value from SELECT, such as a profit or age value alongside the underlying fields. This might reduce repeated calculations in Apex and API consumers without requiring every temporary value to become part of the object schema. Salesforce has not announced this capability, but it is an interesting direction the feature could take.

Separate promise from roadmap

The pilot looks promising because it addresses a genuine use case. Evaluate what Salesforce supports today, and treat possible SELECT support or broader formula syntax as future possibilities until Salesforce documents them.

🧪 A Sensible Pilot Evaluation

The goal of a pilot test is to produce evidence that can survive a release change, rather than a single successful query in Developer Console.

1. Request enrolment and confirm the pilot terms with your Salesforce contact.

2. Reproduce the published examples in a non-production org before extending the syntax.

3. Add edge cases for nulls, negative values, mixed numeric types, multiple currencies, and DateTime boundaries.

4. Test realistic volume and compare Query Plans, timings, and returned-row counts with the existing implementation.

5. Use the real execution context so record and field access match the eventual Apex or API caller.

6. Document the environment and exact query when sharing feedback in the Salesforce Developers Trailblazer Community.

Keep the expression static rather than building it from user-controlled input. If dynamic SOQL is unavoidable, apply the usual injection controls and retain the security practices used for any SOQL query.

---

🏁 Conclusion

I think FORMULA() has a genuine place in SOQL: small, query-local calculations that do not deserve permanent metadata. The pilot already demonstrates that value, and I am interested to see how Salesforce expands the idea.

It will be interesting to see whether the feature eventually grows to include calculated values in SELECT, but that possibility should not be confused with the published pilot. For now, this is a feature to evaluate, not a settled SOQL pattern. Keep production designs on documented capabilities and treat pilot results as provisional evidence.

---

📚 Resources

Calculate Values in a SOQL WHERE Clause (Pilot) The official Summer '26 release note covering availability, enrolment, and pilot terms.

Simplify Your SOQL Queries Using SOQL FORMULA() in WHERE The Salesforce Enterprise API team's syntax, type, and worked-example announcement.

Retrieve Query Plans Salesforce guidance on inspecting query operations and relative cost.

Trailhead: SOQL for Admins Hands-on practice with SOQL fundamentals and filtering.

---