← All topics

Data Queries

Ask questions about the record data in a connected org. Every query needs your permission, the answer goes to your screen, and nothing is kept unless you save it.

What it does

OrgBolt reads org metadata all the time — objects, fields, flows, Apex, permission sets. That is the product, and it needs no permission from you. Record data is different. A data query is one SELECT statement that the AI runs against the record data in a connected org, and it runs only when you allow it.

Ask in plain language: "how many opportunities closed last month?", "show me the accounts with no owner". The AI writes the SOQL. You see the exact statement before anything runs, and the answer comes back either as a sentence in the chat or as a table on your screen.

OrgBolt adds no privilege of its own. The query runs as the Salesforce user who connected the org, so field-level security and sharing rules apply exactly as they do in the browser. A restricted user gets fewer results than a System Administrator asking the same question.

Where the results go

Two kinds of answer can come back, and they are treated differently.

  • A short aggregate — a count, a sum, at most about ten values — goes to the AI, which answers in a sentence. Those values are part of the chat, and the chat is saved.
  • Anything wider — a result set, or a grouped aggregate with more than ten groups — never reaches the AI. The record data is streamed to the browser tab you are sitting in and opens in the results viewer.

A query that returns a result set runs under a cap of 200 rows, and the viewer says so when the cap bit; an oversized response is refused outright rather than trimmed. In the viewer you can sort the table, read the raw CSV under Source, download it, or save it to the task. Sorting and downloading happen in your browser, so neither runs a second query.

An aggregate that groups by a field puts real record values in front of the AI. "SELECT Name, COUNT(Id) FROM Account GROUP BY Name" returns account names, and up to about ten of them can end up in the AI's reply and stay in the saved conversation. That is the width your permission buys.

What is kept and what is not

  • The task transcript keeps the SOQL, the column names, and the count of every query that ran. That record is what makes a standing permission safe to give — you can always read back what was asked.
  • The short aggregate values described above stay in the AI's reply, because the reply is saved with the task.
  • Record values from a wider result are kept nowhere: not in the database, not in the transcript, not in the AI's context. They live in one browser tab and nowhere else.

Reloading the page discards results the tab was holding. The transcript row then says the results are gone and offers to run the query again. That is the recovery path, and it is the only one — nobody can reproduce a result set after the fact, not you and not OrgBolt support. The statement is reproducible; the answer is not. A long session drops its oldest results after twenty queries, with the same outcome.

Saving a result set

"Save to task" in the results viewer is the one exception, and the only way record data is stored by OrgBolt. It writes the same CSV the download button writes, filed on the task under Documents with a Results badge. It opens in the same viewer as anything else saved to a task, and it is never sent to an org in a deploy.

The save uses the values already in your browser. It does not run the query again, so what you keep is what you looked at. Sorting the table first does not reorder the file — the file holds the results in the order Salesforce returned them.

A saved result set follows its task: deleting the task deletes it, and deleting your account purges it. You can also take one back on its own — open it and click Discard. The file is deleted outright, there is no undo, and the removal is written to the audit log the same way the save was.

Turning access off

Settings → Orgs lists every connected org with its current state — "Record data queries: Not allowed", or "Allowed — granted by ⟨name⟩ on ⟨date⟩" — and one button flips it. Any member of the workspace can allow or revoke; there is no separate permission for the permission.

A revoke takes effect on the next query, including one part-way through a task. It also closes any unused one-time allowance for that org, so off means off. What a revoke does not do is reach backwards: a result set already on your screen stays there, and one already saved to a task stays saved.

Permission attaches to the org connection, not to the person who gave it and not to the Salesforce login. Reconnecting an expired org keeps it. A Salesforce admin who revokes the connected app stops OrgBolt reaching that org at all, but does not clear this setting — the Revoke button is the only thing that does.

The audit trail

Every permission decision writes a row in OrgBolt's audit log, scoped to your workspace. Each row names who acted, when, from which IP address, with which browser (the user agent), and against which org.

  • Allowing an org — data_access.granted
  • Revoking it — data_access.revoked, which also carries when the permission started and who gave it
  • Allow once — data_access.allowed_once, carrying the statement it approved
  • Saving a result set — data_access.saved, carrying the statement, the count, and the filename
  • Discarding one — data_access.discarded, carrying the filename and the count, plus the statement and the org when the save is still in the log

Cancel writes nothing, because nothing was allowed and nothing ran — the blocked query is already in the transcript. A saved result set cannot exist without its audit row: if the log write fails, the saved file is removed and you are asked to try again.

Audit rows are kept for seven years and anonymized after account deletion. There is no self-serve view of the log today; email [email protected] if you need a copy for a review.

Common questions

Does the AI see my record data?
Only a short aggregate — at most about ten values — and a GROUP BY key is one of those values, so real field values can reach it that way. A wider result set is streamed to your browser and never enters the AI's context or OrgBolt's database.
Can I let one member query an org and not another?
No. Permission is per org, not per member. Any member of the workspace can turn it on or off, and the audit log says who did.
Why did the AI ask twice for the same thing?
An allowance covers one exact statement, once. If the AI rewrote its query, or the first attempt failed after the allowance was spent, the second attempt needs a fresh answer from you.
What does a data query cost?
A query runs inside an ordinary AI message and is metered like any other message. There is no separate charge for reading record data.