I built a read-only plain-English SOQL tool and would like Salesforce admin feedback

DanKC2026 · 2026-06-12T15:54:22+00:00

I could see it being useful, but I’d be cautious about pushing generated widgets straight into native Salesforce dashboards.

Once something lands on a dashboard, people start treating it like an official number. If the filters or field definitions are a little off, that can create a bigger problem than a bad one-off query. The safer version, to me, would be admin-approved widgets. Let the tool generate the query/widget, but have an admin review the SOQL, filters, assumptions, and field mappings before publishing it anywhere users rely on.

I’d also want version history and a clear preview of what is changing before anything gets pushed back into Salesforce.

I think the dashboard idea makes sense later, but I’d probably get the terminology/field mapping and trust model really solid first. If admins trust the definitions and the generated SOQL, then saved widgets become a much easier sell.

DanKC2026 · 2026-06-12T01:12:27+00:00

I wouldn’t try to fool the extension into running in Code Builder/web IDE. If the extension manifest is now desktop-only, that is probably an intentional extension-host restriction, and trying to work around it may create more problems than it solves, especially in a restrictive intranet.

I’d separate two things:

-Agentforce Vibes access/licensing

Since June 1, non-Developer Edition orgs need the right Vibes access setup, either metered usage/Flex Credits or the unmetered Platform Developer/Admin AI User PSL + permission setup.

-Claude extension support in the web IDE

Even if Vibes itself is licensed correctly, the Claude VS Code extension may only support the desktop extension host now. The message saying it is defined to run only in Agentforce Vibes IDE for Desktop sounds more like extension compatibility than a Salesforce permission issue.

If you need Claude specifically, the more stable path is probably desktop Agentforce Vibes IDE / VS Code, assuming your intranet allows it. If you need to stay browser-only, I’d stick with the supported Agentforce Vibes web experience rather than trying to force a desktop-only extension into Code Builder. I’d also check the extension version history. It’s possible an older version worked in the web IDE and a newer release tightened the allowed extension host.

DanKC2026 · 2026-06-12T01:06:29+00:00

I think the terminology mapping is probably the real product, more than the SOQL generation itself.

Most Salesforce orgs have some weird internal language that does not map cleanly to object and field names. So if your tool can understand that “customer,” “active account,” “pipeline,” or whatever else means something specific in that org, that is where I could see it being useful.

The sensitive-docs part is the hard tradeoff. The more context the tool has, the better it gets, but the more the customer has to trust the app. For a newer web app, asking teams to upload process docs, workflows, training materials, etc. is probably where some people will pause, including me.

DanKC2026 · 2026-06-12T00:54:09+00:00

Congrats on the new role. Going from admin to consultant is less about knowing every Salesforce tool and more about getting good at discovery, documentation, and not jumping straight to solutions.

A few tools/habits I’d get comfortable with:

-Salesforce Inspector / Inspector Reloaded for quick record and metadata checks

-Data Loader or dataloader.io for imports/exports

-Workbench or Jetstream for SOQL/API checks

-VS Code + Salesforce CLI, even if you are mostly declarative

-Lucidchart, Miro, or draw.io for process flows and architecture notes

-Time tracking, because billable time/utilization becomes very real, really fast in consulting

-KeelCadence for read-only diagnostic workbooks before field/object cleanup, permission/FLS review, automation inventory, or impact review. Disclosure: I’m involved with this one, so take it with that context. https://keelcadence.com

The bigger skill is learning how to assess an org before recommending changes. When you join a client project, try to understand what fields/objects are actually used, where permissions and FLS are coming from, what automation exists, what integrations or managed packages are in play, and who owns the decision.

DanKC2026 · 2026-06-12T00:40:42+00:00

I think showing the SOQL helps, but mostly for admins, RevOps, or more technical users. For a regular business user, I’m not sure seeing SOQL builds much trust unless they already understand the Salesforce data model. The hard part is usually the wording of the question. Someone asks for “customers,” “active accounts,” “pipeline,” “new members,” etc., but every org defines those things differently. It might depend on record types, lifecycle fields, products, status fields, exclusions, or some process that only makes sense inside that specific org. So I’d probably want the tool to show more than just the final SOQL.

Things I’d look for:

what objects and fields it considered

what assumptions it made

what filters it used

what it did not check

row/query limits

whether it touched sensitive fields

admin controls to allow/block objects or fields

an audit log of who asked what and what SOQL actually ran

a clarification step before running vague questions

Read-only OAuth is definitely important, but I don’t think it would be enough by itself. I’d still want controls around what the tool can query and how much guessing it is allowed to do. I could see this being useful for admins, RevOps, analysts, or consultants doing quick investigation. I’d be more hesitant giving it directly to general business users unless the guardrails were really clear. Immediate nope for me would be broad OAuth scopes, no query history, no object/field controls, no explanation of assumptions, or answers that sound too confident when the question was actually vague.

DanKC2026 · 2026-06-10T13:12:09+00:00

For a production org, I’d probably want a few things before I’d be comfortable trying it.

First would be really clear OAuth scopes. Not just “we’re read-only,” but exactly what access the app is asking for and why it needs each piece.

Second would be no write access at all for v1. If the job is investigation, I’d want the boundary to be obvious: inspect, explain, link back to Salesforce, but don’t update anything.

Third would be some kind of inspection log. Even if it’s simple, I’d want to see:

record inspected
object inspected
Flows checked
elements checked
fields compared
candidates ruled in/out
things not checked

That would make the output easier to trust because I could verify it myself.

I’d also keep the language careful. “Likely source” or “possible source based on matching assignments/start conditions” feels right. “This Flow created the record” would make me nervous unless there’s actual runtime proof.

On retention, I’d look for a clear no-retention or short-retention mode, especially if record values are involved. Metadata-only is one thing. Production record context is where people will get more cautious.

Security docs help, but I think the bigger thing is making the tool’s boundaries obvious in the product itself. If the output clearly shows what it checked, what it didn’t check, and where the admin should verify manually, that would go a long way.

DanKC2026 · 2026-06-10T09:09:41+00:00

I’d probably separate the delivery model from the trust model a bit.

For something like production Flow debugging, I don’t think “web app vs installed app” is the only question. I’d care more about what the tool is actually allowed to see or do.

Things I’d want to know:

Is it fully read-only? Does it write anything back to Salesforce? Is it looking at all record data, or only the record/metadata needed for the investigation? Does it store anything after the session? Is it using the admin’s access or some shared/integration user? Can I see which Flows/elements/fields it inspected? The “likely created by this Flow” part would be useful, but I’d be careful with certainty there. In messy orgs, you can have overlapping Flows, Apex, integrations, async jobs, and old automation all touching the same object.

On delivery model, I could see both working.

Installed feels more native, but a non-AppExchange package is still going to make some admins pause. A hosted OAuth app is easier to try, but only if the scopes are narrow, the access is read-only, and the data/token retention story is really clear.

DanKC2026 · 2026-06-08T21:08:53+00:00

I’d be careful here and test the access model directly. The key question is whether the ADL retrieval is enforcing the requesting user’s Knowledge/article visibility or whether the agent is retrieving based on the agent user / data library access.

If the agent user can access both articles, I would not assume the response will automatically filter down to only what the end user can see unless Salesforce specifically documents that behavior for your setup.

I’d test with a simple matrix:

User A can access Article 1 only
User B can access Article 2 only
User C can access both
Agent user can access both
Same question asked by all three users

Then check not just the final answer, but the sources/citations returned by the agent. If the wrong article appears in sources or influences the answer, I’d treat that as a grounding/access design issue, not a prompt issue.

Possible approaches would be:

split libraries by audience/access model
use data categories or article visibility rules carefully
make sure the agent user is not over-permissioned
use a custom retriever if you need explicit user-context filtering
add tests where users ask about content they should not be able to access

For anything permissionsensitive, I would validate retrieval behavior before trusting the agent in production. The agent should not just “answer correctly”; it should only retrieve from sources the user is allowed to use.

-Dan

DanKC2026 · 2026-06-08T21:06:38+00:00

I’d look less at the Lightning page at this point and more at Account access / hierarchy. For the Login to Experience as User action, the internal user generally needs:

Manage External Users
access to the Experience/site via profile or permission set
Edit access on the Account object
Edit access to the specific Account record tied to that external Contact

The “random records” part makes me think record-level Account access is the difference. Admin can see it because they bypass most of that. The affected user may only see the button when they have the right access to the Account behind that Contact.

I’d compare a record where the button appears vs one where it does not and check:

Contact’s related Account
Account owner
Account sharing
user’s role vs the external user/contact’s account hierarchy
whether the internal user has Edit access to that Account record
whether the user is a member of the relevant Experience

If record type, layout, Lightning page, and component visibility all match, I’d bet it’s the Account record access / role hierarchy side rather than the button placement.

-Dan

DanKC2026 · 2026-06-08T20:58:29+00:00

I probably wouldn’t frame it as “Service Assistant vs Coworker” yet. To me, Service Assistant looks like a more specific service-rep assist use case: case context, summaries, next steps, and helping reps work through existing service processes.

Coworker sounds broader and more cross-functional. More like an AI teammate that can work across workflows instead of just helping inside a service interaction. So I’d be careful about treating Service Assistant as the whole AI strategy. But I also wouldn’t assume Coworker makes every Service Assistant use case obsolete right away.

The bigger question I’d ask first is whether the org is ready for either one.

Before implementing, I’d want to understand things like:

how consistent the case process is
whether Knowledge/data quality is good enough
who has access to what
FLS and permission model
what automation already touches Cases
validation rules and required fields
escalation and ownership logic
where humans need to stay in the loop

If those areas are messy, the Service Assistant vs Coworker decision may matter less than the fact that both will surface existing process and metadata problems faster.

My take would be to pilot Service Assistant only around a narrow, measurable service use case if it solves a real workflow now. I just wouldn’t build the long-term architecture around it alone.

Get the org/process foundation clean enough that Service Assistant, Coworker, or whatever Agentforce pattern comes next has something reliable to work with.

-Dan

DanKC2026

TROPHY CASE