Live data access is no longer an account-wide on/off switch. Account admins now choose exactly which people can have the agent query which orgs — so a consultant can query a sandbox without touching production.
Why we changed it
Until now, live data access was a single switch on your account. Turning it on let every member of your account have the agent query every connected org. That was too blunt for how consulting teams actually work. You told us two things repeatedly: some orgs are fine to query and others are not, and not everyone on the team should be querying records regardless of the org.
An account-wide switch forced a bad trade — leave it off and lose the feature entirely, or turn it on and accept a wider blast radius than you were comfortable signing off on.
We also removed the step where dx0 had to enable the feature for you before you could use it. It created support tickets without adding safety. The per-person, per-org grants are what actually contain the risk, so the account owner can now turn the feature on themselves.
How it works now
Three things must all be true before the agent will run a live query:
- The account owner has turned data access on. Account Settings → Data Access, confirmed by typing
I allow the AI agent to read redacted CRM data. This switch alone grants nobody anything. - An account admin has granted that specific person access to that specific org. Open the org under Connected Orgs and use the new Data Access tab. One person, one org at a time.
- The person is still a member of the workspace the org belongs to. This is checked at query time, not when the grant was made.
If any condition fails, the agent refuses the query and tells the person which one it was and who can fix it. It still answers questions about the org's configuration — metadata, dependencies, automation, field usage — and it will write the SOQL for them to run themselves in the Query tab.
Setting it up
The account owner enables the switch once. After that, account admins do the granting from each org's Data Access tab: pick a workspace member from the dropdown, click Grant Access. The tab lists everyone who currently has access, who granted it, and when. Anyone in the workspace can see that list; only account admins and the account owner can change it.
Every grant sends a confirmation email to the admin who made it, naming the person and the org, as a written record.
What you need to do after this release
If your account already had data access on, the agent will stop running live queries until admins grant access per org. The account-level switch stays on, but it no longer authorizes anyone by itself. Nothing is lost and nothing is broken — this is the new model taking effect — but plan for an admin to spend a few minutes granting access on the orgs your team queries day to day.
If you asked us to enable data access and were waiting on us, you no longer need to. The owner can turn it on from Account Settings today.
Gotchas worth knowing
Queries run with the org's connection, not the person's Salesforce permissions. Whoever connected the org determines what can be read. Someone you grant access to can read anything that connection can read, even records they could not see signed in to Salesforce themselves. This matters most on production orgs connected with an admin user. The Data Access tab names the connecting user so you can check before granting.
Grants do not travel between orgs. Granting someone access to a sandbox gives them nothing on production. This is the point of the change, but it also means there is no bulk grant — each org is a deliberate decision.
Turning the account switch off stops everything immediately, and grants survive. Existing grants are kept, not deleted. Turn the switch back on and everyone who had access has it again. Treat the switch as an emergency stop, not a way to clear the slate.
Removing someone from a workspace cuts off their queries right away, but the grant row remains. Because membership is checked at query time, a removed person cannot query even though their name may still appear on the list. If you add them back to the workspace, their access returns without an admin re-granting it. If that is not what you want, remove the grant explicitly.
The person you grant access to is not emailed. Only the acting admin gets the confirmation. Tell them directly, or they will not know their next data question will now be answered from live records.
Workspace admins cannot grant data access. Only account admins and the account owner can. This is intentional: the grant is an account-level trust decision, not a workspace one.
PII redaction and read-only access are unchanged. Fields that look like personal data — emails, phone numbers, addresses, names — are replaced with REDACTED before the agent sees anything, and the agent can never modify your data. This release changes who can query, not what the agent sees or does.