SOQL Selectivity and Pre-Flight Validation: Catching Bad Queries Before They Run

SOQL Selectivity Explained

What SOQL selectivity means

Selectivity is how well a SOQL query narrows the records Salesforce has to scan before returning a result. A selective query hits an index and touches a small, relevant slice of a table. A non-selective query forces Salesforce to scan a much larger portion of the object's records, even when the final result set is small.

On a small object, the difference is invisible. On a large object, an unselective query is where slow reports, timeout errors, and governor limit exceptions start.

That gap between "works fine today" and "times out tomorrow" is exactly why selectivity is so easy to overlook. A query written against an object with a few thousand records behaves identically whether it is selective or not, so there is no visible signal telling the person who wrote it that anything needs attention. The problem is dormant until record volume changes the arithmetic underneath it.

Why non-selective queries are so easy to write by accident

Most non-selective queries are not written by anyone trying to write a bad query. They come from ordinary, reasonable-looking SOQL: a filter on a field that is not indexed, a leading wildcard in a LIKE clause, a negative filter such as a not-equals check, or a query built early in an object's life that never got revisited as record volume grew.

  • Filtering on an unindexed custom field
  • A LIKE '%value%' filter with a leading wildcard
  • Negative conditions (!=, NOT IN) that cannot use most indexes efficiently
  • OR conditions that mix an indexed and an unindexed filter
  • Queries that were selective at 10,000 records and are not at 2 million

None of these look wrong when you write them. They only become a problem once the object grows, which is exactly why they tend to surface as an incident rather than get caught in review.

Manual code review does not reliably catch this class of problem either, because selectivity is a property of the query relative to the object's current data volume and index configuration, not something visible from reading the SOQL syntax alone. Two admins can look at the same query, on the same day, and reach different conclusions about whether it is safe, simply because neither has an easy way to check it against Salesforce's actual selectivity thresholds without running it.

What pre-flight validation checks before a query runs

Pre-flight validation is exactly what it sounds like: the query gets checked against Salesforce's selectivity rules before it executes against real data, not after it times out or trips a governor limit. Cirra AI's Data Skills capability runs this analysis, checking a SOQL query for common selectivity risks like the ones above and flagging where a query is likely to be non-selective before it is ever run against production.

This turns a problem that used to show up as a support ticket, a slow report, or a failed batch job into something caught at the point of writing the query. An admin describing what they want in plain language gets the query back with the selectivity risk already flagged, rather than finding out when the report times out.

How this shows up in day-to-day admin work

This capability is most useful in exactly the situations where SOQL problems tend to hide: a new report built against a growing object, a validation rule or flow that queries a related object under the hood, or an integration that pulls a filtered list on a schedule. Each of these can run fine for months and then fail once record volume crosses a threshold nobody was watching for.

Because the check runs before execution, it works the same way whether the person asking is a Salesforce admin who already knows what selectivity means, or a RevOps manager who just wants their report to stop timing out and does not need to learn the underlying reason.

The timing is what makes this different from most performance troubleshooting. Fixing a slow report after it has already shipped means someone has to notice the slowness, trace it back to the underlying query, and rebuild the filter logic, often under pressure once a business process is already affected. Catching the same issue at the point of writing the query removes that entire chain of events, because the flagged risk and the fix happen in the same conversation.

Where this fits in the bigger picture

None of this requires an admin to learn query optimization as a separate discipline. The point of pre-flight validation is that the underlying selectivity rules stay in the tool, not in the admin's head, which is also what makes it useful to people who have never had a reason to learn what an index does in the first place.

Query performance is one part of a Salesforce org's overall health, alongside metadata structure, automation, and permissions. Cirra AI's Data Skills sit next to its other metadata capabilities, so the same conversation that flags a non-selective query can also look at the object's indexes, the flow that triggers it, or the report definition that is timing out. The MCP setup guide covers how to connect an AI client to your org if you have not done that yet.

Frequently asked questions

What is SOQL selectivity?

It describes how narrowly a SOQL query filters records before Salesforce has to scan them. A selective query uses an index to touch a small slice of the object; a non-selective query forces a much broader scan.

Why does an unselective query matter if the result set is small?

Salesforce evaluates selectivity based on how the query narrows the scan, not just the size of the final result. A query can return five records and still force Salesforce to scan millions to find them.

What does pre-flight validation actually check?

It reviews a SOQL query against known selectivity risks (unindexed filters, leading wildcards, negative conditions, and similar patterns) before the query runs against real data.

Does this replace a developer reviewing complex queries?

No. It catches the common, well-understood selectivity patterns automatically, which covers most day-to-day admin and reporting work; genuinely complex query design still benefits from developer review.

Want to see a query flagged before it ever hits production? Start a free trial and run one of your own reports through Cirra AI.

Share the Post:

Related Posts