Before You Turn On an AI Agent in Salesforce, You Need to Know What Data You Have

Every "Agentforce readiness checklist" published this year opens with some version of the same two items: know what sensitive data lives in your org, and know who — or what — currently has access to it. The reasoning is straightforward. An agent that can read a Case description or a Contact record can read whatever's sitting in it, including whatever nobody meant to put there. Before an agent gets pointed at your data, both of those questions need real answers, not a guess.

Most orgs don't have either answer on hand. Not because the questions are hard — because nobody's had a reason to ask them until now.

Question one: what's actually in there

Support reps paste things into free-text fields. Sales reps paste things into Opportunity descriptions. A custom object built for one project two years ago has a text field nobody's looked at since. Finding out whether any of that contains a Social Security number, a credit card number, or another identifier means checking field by field, object by object — which is exactly the kind of check that doesn't happen until a compliance team asks for it directly.

PII and Sensitive Data Detector, part of Power User Toolkit, is a policy-based scanner built for that check: pick an object, pick the fields, pick the pattern types — email, phone, SSN, passport, credit card, driver's license — and run it as a background batch job. Every match gets logged individually: which record, which field, which pattern triggered it. Worth being direct about what this is and isn't: it's pattern matching against field values, not AI, and not a certified compliance tool. A tightly formatted string of digits can trip a credit card pattern without being one. It's a fast way to find where sensitive-looking data is concentrated — a starting point for the review, not the review itself.

Question two: who can already reach it

Finding the data is half the answer. The other half is knowing who — and by extension, what — can already touch it. If a field turns out to hold something sensitive, the next question is immediate: which profiles, permission sets, and permission set groups have read or edit access right now?

Fields Access Explorer, part of Power User Toolkit, answers that directly: pick an object, pick a field, and see every profile, permission set, and permission set group with access to it, broken out by read and edit. That's the access side of the same checklist item — not "we believe access is limited," but the actual list.

Why this is boring, on purpose

None of this is new functionality built for the AI moment. It's the same policy-based scanner and the same field-level lookup Power User Toolkit has had — repurposed here because the "readiness" conversation everyone's suddenly having turns out to need exactly this kind of unglamorous audit work, done before the interesting part starts. The org that can answer "what sensitive data do we have and who can reach it" in an afternoon is in a materially different position than the org still guessing when the question gets asked in a security review.

If offboarding is what put data exposure on your radar instead, see Before You Deactivate a Salesforce User, Find Out What They Own. For the full breakdown of the scanning policy itself, see How to Find PII Hiding in a Salesforce Org Without Writing a Single SOQL Query and Who Can Actually See That Field?. Or start at the Power User Toolkit overview.

Get Power User Toolkit on Salesforce AppExchange →