SOQL Without Writing Code: Let Your AI Query

You can get real answers out of your Salesforce org today, using SOQL, without writing code. Not through a report builder, not by exporting to a spreadsheet, and not by filing a ticket with someone who knows the query language. You ask your AI a question in plain English, it writes the SOQL, and you read the query it wrote before you trust the number it returns.

That last clause is the whole post. The skill that matters in 2026 is not writing SOQL — that is a solved, commoditized job. The skill that matters is reading SOQL well enough to know whether the query answered the question you actually asked. This tutorial teaches that, end to end, in about fifteen minutes of reading.

What SOQL actually is

SOQL is the Salesforce Object Query Language. Per Salesforce’s own SOQL reference, it is “similar to the SELECT statement in the widely used Structured Query Language (SQL) but is designed specifically for Salesforce data.” It is how every serious read of your org happens underneath — the API, Apex, the CLI, and most of the tooling you already use.

It is also deliberately narrower than SQL. The same reference is explicit that you cannot perform arbitrary joins, cannot use wildcards in field lists, and cannot use calculation expressions. There is no SELECT * in Salesforce. You must name every field you want.

That single restriction is why SOQL blocks non-developers. To write a query, you have to already know the API names of the fields — Amount, CloseDate, StageName, Custom_Thing__c — and those names are not what the page in front of you displays. The label says “Deal Size.” The field is Amount. The gap between what you see and what you must type is the entire barrier, and it is exactly the kind of gap a language model closes without effort.

The rule: don’t write it, read it

Here is the position this post takes, plainly. Delegating the writing of a query is fine and always has been — a developer writing it for you was never a guarantee of correctness either. Delegating the reading is where people get hurt.

A wrong SOQL query does not error. It returns a confident, well-formatted, completely plausible number. Nobody gets an exception. You get 47 when the answer was 312, and you take that 47 into a pipeline review. Reading the query is the only check that catches this, and it takes about ten seconds once you know the five parts.

Step 1 — Connect your AI to the org

Before any of this works, your AI needs an authenticated connection to Salesforce that can run queries. That is a setup step in its own right, and we covered it in detail in connecting Claude to your Salesforce org the safe way — JWT auth, an External Client App, and a connection your AI reaches over MCP rather than something running out of a browser tab.

One thing worth deciding up front: give this connection read access only to start. In Sentinel, that is a read key, and you can issue as many as you want — write access is the thing that is deliberately restricted to one holder at a time. Querying is the correct on-ramp precisely because a read cannot change anything.

Step 2 — Ask in business language, not field names

The instinct is to try to speak Salesforce. Resist it. You will guess the field names wrong and constrain the AI to your bad guess.

Ask the way you would ask a competent analyst:

“How many open opportunities do we have that were created in the last 30 days, and what’s the total value?”

Not “query Opportunity where IsClosed = false.” Let the AI resolve the vocabulary. A model with a live connection to your org can inspect the schema and find that your team renamed the stage picklist, or that “value” lives in a custom currency field rather than Amount. Your job is to be precise about the question — “open” meaning what, exactly? “Created” or “closing”? — not about the syntax.

Step 3 — Read the query it wrote

Here is what comes back for that question:

SELECT Id, Name, Amount, StageName, CloseDate
FROM Opportunity
WHERE IsClosed = false
  AND CreatedDate = LAST_N_DAYS:30
ORDER BY Amount DESC
LIMIT 200

Five parts, every time, in this order:

SELECT — the fields coming back. If a field you need to see isn’t listed here, it isn’t in the result, no matter what the summary says.

FROM — the one object being queried. Singular. If you asked a question that spans Accounts and Opportunities, look closely at which one is in the FROM, because that determines what a “row” means.

WHERE — the filters. This is where nearly every wrong answer lives. Read it as English: “is not closed, and was created in the last 30 days.” Does that match your question?

ORDER BY — the sort. Cosmetic for a count, load-bearing when someone is about to work the top of the list.

LIMIT — the cap. Critically important, and covered below.

Notice LAST_N_DAYS:30. SOQL has built-in date literals — TODAY, THIS_MONTH, LAST_N_DAYS:n — which are far more reliable than a hard-coded date, because they don’t silently rot the next time someone runs the query.

Step 4 — The four things that actually go wrong

Run this checklist against every query before you act on the result.

1. The LIMIT is lying to you. If the query says LIMIT 200 and you asked “how many,” a count of 200 might mean “exactly 200” or might mean “at least 200, truncated.” These are wildly different facts. For a count, you want an aggregate (below), not a capped list. Salesforce also enforces per-transaction governor limits on how much a single execution can retrieve, so a big query can hit a ceiling that has nothing to do with your data.

2. The WHERE clause answered a neighboring question. CreatedDate versus CloseDate versus LastModifiedDate are three different questions that all sound like “recent.” Read the field name, not the vibe.

3. Deleted records. By default, SOQL excludes records in the recycle bin. If a query includes ALL ROWS, deleted and archived records are in your number. That is occasionally what you want and usually not.

4. Nulls silently drop rows. WHERE Amount > 0 excludes every opportunity where Amount is blank. If half your records have no amount set, your “total pipeline” just quietly lost half the pipeline. Ask the AI directly: “how many of these have a null Amount?”

Relationship queries look scary and aren’t

The one piece of SOQL syntax worth genuinely learning to read is relationships, because it is how you answer any question involving two objects. Salesforce’s relationship queries reference describes traversing “parent-to-child and child-to-parent relationships between objects to filter and return results” — with the standing caveat that you still cannot do arbitrary SQL joins. Traversals have to follow real relationships defined in your schema.

There are exactly two shapes.

Child to parent — dot notation:

SELECT Id, Name, Account.Name, Account.Industry
FROM Contact
WHERE Account.Industry = 'Real Estate'

Read the dots as “of the.” Account.Name is “the Name of the Account.” One row per Contact, with parent fields hanging off it.

Parent to child — a subquery in parentheses:

SELECT Id, Name,
  (SELECT Id, Amount FROM Opportunities WHERE IsClosed = false)
FROM Account

One row per Account, each carrying a nested list of its open opportunities. Note the plural — Opportunities, not Opportunity. Parent-to-child uses the relationship name, and getting that wrong is the single most common SOQL error your AI will hit and self-correct.

The reading test: what is one row? In the first query, one row is a Contact. In the second, one row is an Account. If you sum the wrong one, you double-count.

Aggregates: counting without an export

When the question is “how many” or “how much,” you do not want a list. You want the database to do the math:

SELECT StageName, COUNT(Id) dealCount, SUM(Amount) totalValue
FROM Opportunity
WHERE IsClosed = false
GROUP BY StageName
ORDER BY SUM(Amount) DESC

This returns one row per stage with a count and a sum — the pipeline-by-stage answer, computed in the org, no export, no spreadsheet, no pivot table. COUNT(), SUM(), AVG(), MIN(), and MAX() all work, and GROUP BY is where SOQL stops feeling like a lookup tool and starts feeling like analysis.

Ask for the aggregate explicitly: “give me a count and sum grouped by stage, not a list of records.” Models default to returning rows because rows are what most questions want.

Step 5 — Verify before you act

Three habits, in order of value.

Ask for the query, always. “Show me the SOQL you ran” should be reflex. If you can’t see it, you’re trusting a summary of a summary.

Sanity-check one record by hand. Take one Id from the result, open it in Salesforce, confirm it belongs. Ten seconds, catches most filter mistakes.

Ask the same question a second way. If the aggregate says 312 open deals and a SELECT COUNT() with a different filter framing says 312, you’re fine. If they disagree, one of your two questions was not the question you meant.

Why reads are the right place to start

Everything above is read-only, and that is the point. A query cannot break your org. It is the lowest-stakes possible way to find out whether an AI with a live connection is actually useful to you, before you let it write anything.

But reads are not only a training-wheels exercise — they are also how you verify writes. When your AI builds a custom object or ships an automation, the read-back query is the proof it worked. That pattern is exactly why RevOps teams sitting behind a developer backlog get value here fast: the same connection that answers “how many” also ships the fix, and the same connection verifies the fix landed.

On Sentinel specifically, that connection lives on a dedicated VM for your org, and every action against it lands in an audit log — including the reads. Write access is a single key held by one person’s AI at a time; read keys are unlimited, which is how a team develops against one org without stepping on each other. Deploys get a snapshot taken beforehand, so a change that turns out wrong is recoverable.

To be direct about what that does and doesn’t mean: Sentinel does not prevent your AI from running a bad query or shipping a regrettable change. It is not a guardrail system, and it isn’t sold as one. What it gives you is visibility and recovery — you can see exactly what was run and when, and you can undo what was deployed. That is the whole safety philosophy, and it applies to reads and writes alike.

What this doesn’t replace

Reports and dashboards still win for anything a non-technical team member needs to re-run weekly on their own. SOQL wins for the one-off question, the question with a weird filter, the question that spans objects awkwardly, and the question you need answered in the next ninety seconds. Use both.

And if a query returns something that surprises you, the answer is almost never “the AI hallucinated the number.” It is almost always that the WHERE clause is precisely correct about a slightly different question. Read it again as English. That’s the skill.

Start querying

You don’t need to learn SOQL. You need a live connection to your org, the habit of asking to see the query, and five minutes of practice reading SELECT / FROM / WHERE / ORDER BY / LIMIT. That’s the whole curriculum, and it’s the same curriculum whether you’re a business owner who has never seen code or an admin who has been meaning to learn this for three years.

Sentinel gives your AI that connection — a dedicated VM for your org, key-based access with reads separated from writes, and a log of everything that runs. It’s $2,500 one-time onboarding on your first Sentinel, plus $500/month per Sentinel.

Get a Sentinel and start asking your org questions