Let dx0 Query Live CRM Data

Give specific people the ability to have the dx0 agent answer questions from live Salesforce records in specific orgs, with PII redacted automatically. Use this when a consultant needs real data to answer a question, not just metadata.

What this gives you

By default the dx0 agent reasons about your org's configuration: metadata, dependencies, automation, field usage. It can write SOQL, but it will not run it.

Data access lets the agent run that SOQL itself, read-only, and answer from the results. "How many Accounts still have a value in this field before we delete it?" becomes an answer instead of a query you paste into the chat UI.

Access is granted one person and one org at a time. A consultant can query a client sandbox without being able to touch production, and a teammate on a different engagement gets nothing.

The three conditions

The agent runs a live query only when all three are true:

1. The account switch is on. The account owner turns it on under Account Settings → Data Access, confirming by typing I allow the AI agent to read redacted CRM data. This authorizes nobody on its own — it opens the door to granting.
2. That person has a grant on that org. An account admin grants it from the org's Data Access tab under Connected Orgs. No grant means no queries, which is the default for every org.
3. That person is still in the org's workspace. Checked at query time, so losing workspace membership cuts off queries immediately.

When any condition is unmet, the agent says so, names who can fix it, and offers the SOQL for the person to run themselves.

Granting access

Open the org, go to Data Access, pick a workspace member from the dropdown, click Grant Access. The tab shows everyone with access, who granted it, and when. Every member of the workspace can see that list; only account admins and the account owner can change it.

The admin who grants access gets a confirmation email naming the person and the org. The grantee is not notified — tell them yourself, since their next data question will behave differently.
Removing access is the same tab. It takes effect on the next query.

What the agent can and cannot do

It runs SELECT only. It cannot insert, update, delete, or change configuration. Fields that look like personal data — emails, phone numbers, addresses, names — are replaced with REDACTED before the results reach the agent, so it reasons about shape, counts, and patterns rather than reading your client's contact list.
Queries run through the connection the org was set up with, not the grantee's own Salesforce user. Whoever connected the org sets the ceiling on what can be read.

Deciding who to grant

Grant on sandboxes freely, on production deliberately. The distinction the model is built around is the org, so use it.
Check the connecting user before granting on production. If the org was connected with a System Administrator, everyone you grant can read everything that user can read. The Data Access tab names that user for exactly this reason.

Grant to the people doing analysis, not the whole team. Data questions cluster on one or two people per engagement. A short list is easier to defend in a client security review than a long one.
Revisit grants when an engagement ends. Nothing expires on its own.

Turning it off

The account owner can disable the account switch at any time, which stops live queries everywhere immediately. Grants are kept, so re-enabling restores the previous state rather than clearing it. Use the switch as a stop button; use the per-org tab for lasting changes.

Practical scenarios

• Scoping a field deletion. Before dropping a custom field, ask how many records still populate it and when it was last written. Metadata tells you where the field is referenced; data tells you whether anyone actually uses it.
• Validating a migration in a sandbox. After a data load, ask the agent to compare record counts by RecordType or check for rows that failed to map, without leaving dx0 to build the queries.
• Investigating an automation that misfires. Pair the dependency view of a flow with counts of the records it should have touched, and find the gap between what the automation targets and what exists.
• Answering a client question mid-call. "Roughly how many open Opportunities are older than two years?" is a five-second question when the agent can query, and a follow-up email when it cannot.
• Keeping production read-only during discovery. Grant sandbox access to the whole delivery team and production access to the lead only, so exploratory work has no path to client production data.

Updated on: 10/08/2026