dx0 now uses a stronger thinking model when it researches your systems, whether that’s your Salesforce org or software connected through GitHub, GitLab, or Bitbucket.

It traces automations, Apex, code, dependencies, and relationships with more care than before.

You can also choose how much thinking to spend on a conversation from the dropdown next to the composer:

• Fast — quicker answers for simple questions
• More thinking — a bit slower and more thorough (this is the default)
• Extra thinking — takes longer; best when the system is messy or the answer really matters

Pick it before you send the first message. That choice stays for the rest of the conversation, so later follow-ups keep the same depth.

Use More thinking or Extra thinking when you’re mapping an inherited Salesforce org, understanding an unfamiliar codebase, tracing dependencies across systems, checking what a change could affect, or asking something you really don’t want dx0 to miss.

Your Salesforce org was never the whole picture, and now dx0 isn't either. Managed package code, SFDX repositories, Heroku apps, internal tools: if it lives in one of these repos, dx0 can help your team understand it, no git access required.

We put this through its paces on our own stack first. Our support team now answers detailed product questions straight from dx0's own codebase, without pinging engineering. It's been a genuine step change in how fast we move.

Salesforce intelligence is still the core of what we do. This just means the picture doesn't stop at your org anymore.

We are excited to announce a new feature that enhances how you can connect your Salesforce org with dx0. In addition to the classic connected app, you now have the option to use an External Client App, delivered as the dx0 managed package installed directly in your Salesforce org.

Both connection methods offer unique benefits:

1. Connected App: This is the quickest setup option. There's nothing to install, allowing you to connect immediately.

2. External Client App: This option provides more security controls. Since the app is installed within your org, your administrators can manage it directly in Setup. They can control which users have access, set IP relaxation, and manage refresh-token and session policies. Uninstalling the package will immediately cut off dx0's access. This method also avoids the need for the "Approve Uninstalled Connected Apps" permission that might be required when dx0 hasn't been authorized in the org before.

Both methods provide dx0 with the same level of access, which remains read-only. The choice is about who controls the connection and how tightly, not about what dx0 can access.

We hope this new feature provides you with greater flexibility and control over your Salesforce connections with dx0.

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:

1. 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.
2. 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.
3. 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.

The org index has been updated to include the following types:

Entitlements

ReportTypes (requires enabling reports under Connected Orgs > Org > Settings)

Queues

DuplicateRules

OmniChannel

The agent can now answer any questions related to the above metadata, making the experience much more powerful! 

CPQ is one of the most powerful — and most feared — corners of the Salesforce platform. Between nested product rules, price rules, and bundle logic, even seasoned admins often can't say with confidence what a single change will break downstream.

With dx0, that changes. Now everyone in your org — not just your Salesforce architects — can see exactly how CPQ is configured and understand the ripple effects of any change before it hits your go-to-market engine.

No more guessing. No more "let's just test it in prod and hope."

Note: This requires "Agentic Data Access" to be enabled in your account. Reach out to help@happysoup.io for details. 

We just expanded the org index to include Profiles, Roles, and Dashboards — unlocking much richer answers about how access is really configured across your Salesforce org.

You can now ask dx0 questions like:

• Who can see or do what in this org?
• How is access structured across roles and profiles?
• Where are risky or inconsistent access patterns showing up?

One quick setup note

Dashboards are now supported, but they’re optional and need to be turned on in: Connected Orgs → Index Configuration (Include Reports and Dashboards).

Your Salesforce metadata only tells part of the story. Now dx0 understands your business context too.

With Context, you can bring the knowledge that lives in documents, spreadsheets, screenshots directly into every conversation.

You can now:

• Add Context Notes for acronyms, business rules, historical decisions, naming conventions, or reusable user story templates.
• Upload files such as user stories, requirements, CSVs, screenshots, and other supporting documents.
• Combine Salesforce metadata + business context + uploaded files in a single prompt for dramatically better answers.

Need to know whether a new set of requirements impacts a field? dx0 can analyze the requirements document against your Salesforce metadata. Want user stories generated in your company's standard format? Just add your template as Context and dx0 will follow it automatically.

And yes, attachments are finally here. Simply drag and drop your files into the conversation.

Watch the video below to see Context in action.

Your Salesforce reports have always been a bit of a blind spot. Not anymore.

You can now include Reports in your org index, which unlocks a whole new layer of visibility:

• Field usage, finally complete. See where a field is actually used in reports, not just in code and automation. No more "safe to delete?" guesswork.
• Ask the AI agent the real questions. "Which reports are duplicates?", "Can we consolidate these sales reports?", "What reports still reference this legacy field?" — the agent can now dig into your report definitions and answer.

A quick heads-up

Reports can number in the thousands and are heavy to retrieve, so we've kept this off by default to keep everyone's indexing fast and lean. When you're ready for the deeper view, flip it on:

Connected org → Details → Index Configuration → Include Reports

It'll be picked up on the next index refresh. Turn it off any time.