How to Find PII Hiding in a Salesforce Org Without Writing a Single SOQL Query
- Architect
- 23 hours ago
- 3 min read
A compliance team asks whether any custom object contains Social Security numbers. Or a security review wants to know if support reps have been pasting credit card numbers into a case description field where they don't belong. Either way, you're now the person who has to find PII in Salesforce fields that were never designed to be checked for it — and Salesforce doesn't ship a report for "does this data look sensitive."
The manual version of this is a string of LIKE queries, one field at a time, against objects you're mostly guessing about. It's slow, it's easy to miss a field, and it doesn't scale past a handful of objects.
A policy builder instead of a query
PII and Sensitive Data Detector, part of Power User Toolkit, is the dashboard for a policy-based scanning engine. From it, a tile opens Policy Configurator, a four-step wizard that replaces the manual query entirely:
Pick an object. The list is pulled from what the System Administrator profile can actually read, so you're choosing from real, accessible objects instead of guessing at API names.
Pick the fields to scan. Text, text area, number, and date fields are fair game.
Pick the pattern types. Email, phone, SSN, passport, credit card, or driver's license — check as many as apply.
Preview and save the policy with a name, and it's ready to run.
What it actually checks for
This isn't a US-only tool. The SSN, passport, and driver's license checks run against country-specific formats covering roughly the world's 40-50 largest economies, not just the nine-digit US pattern. Credit card detection covers 19 card brands — Visa, MasterCard, Amex, Discover, JCB, UnionPay, and more — and those patterns live in custom metadata, so an admin can add or adjust a brand's format without a code deployment.
Running the scan
Save the policy, then run it as a background batch job. You can add a date filter — scan only records modified in a given window — and set a batch size, so a scan against a five-million-row object doesn't run the same way as one against a five-thousand-row custom object. If a scan is misconfigured or just taking too long, cancel it without waiting for it to finish.
Every match gets logged individually: which record, which field, which pattern type triggered the hit. That log is searchable, so instead of a pass/fail answer you get a worklist — the exact records and fields worth a closer look.
One honest caveat: this is pattern matching, not a certified compliance tool. A tightly-formatted string of digits can trip a credit card or national ID pattern without actually being one. Treat the results as a fast way to find where sensitive-looking data is concentrated, then have a human confirm before you act on any single record.
Why this beats the manual approach
The real value isn't any single scan — it's that the policy is reusable. Once it's built, running it again next quarter, or against a newly added object, is a few clicks instead of rebuilding a query from scratch. For a security or data governance team doing this work repeatedly, that's the difference between a one-off audit and an actual process.
If offboarding is what put PII on your radar in the first place, see Before You Deactivate a Salesforce User, Find Out What They Own — the other half of a clean offboarding process. For the full toolkit, start at the Power User Toolkit overview.
Comments