Salesforce Data Detect: finding the sensitive data hiding in your text fields before an agent reads it

Every org has a graveyard of sensitive data sitting in the wrong place. A Social Security number typed into a case description because the intake form didn’t have a field for it. A passport number pasted into a chatter post. A full card number in a “notes” field an admin created in 2019 and nobody has looked at since. It was invisible and mostly harmless as long as the only way to read it was one record at a time. Then you decided to ground an agent on your data (point a retriever at those free-text fields, let a conversational layer synthesize across them) and suddenly “invisible sensitive data in a description field” became “sensitive data an AI will happily surface to whoever asks.”

You cannot protect, mask, or delete what you can’t find. Data Detect is the tool for finding it: a scanner that reads the free-text fields across your org, matches their contents against patterns for the kinds of sensitive data you care about, and tells you exactly which records and fields are carrying it. It’s the fourth pillar of Salesforce Shield, and it’s the step most teams skip on the way to an AI deployment. Right up until an access review or a right-to-be-forgotten request forces the question “where does this data live?” and nobody can answer it. This is the working guide: what Data Detect reads, how to run it, how to get the results out at scale, and the one limitation that reframes the whole tool.

What it is, and where it sits in Shield

Salesforce Shield is a bundle of four capabilities: Platform Encryption, Event Monitoring, Field Audit Trail, and Data Detect. If you license Shield, you have all four. Data Detect isn’t a separate purchase. Teams that bought Shield for encryption or event monitoring often don’t realize the discovery tool is already sitting in their org, unused.

Data Detect answers a narrower and more fundamental question than the rest of Shield. Encryption protects data you’ve decided is sensitive. Field Audit Trail tracks how it changed. Data Detect finds the sensitive data you didn’t know was there, the stuff that never made it into a governance decision because nobody knew it existed. It’s the reconnaissance step that makes the other three useful: you can’t sensibly choose what to encrypt or audit until you know what you have and where.

The connection to your AI and Data 360 work is direct. Data quality for AI is usually framed as completeness and accuracy. Is the field populated, is it right. Data Detect adds the security dimension of the same question: is this field carrying something an agent should never surface, a segment should never activate on, or a warehouse should never receive over a zero-copy share? You ground agents on your best data. Data Detect makes sure “your best data” isn’t full of unprotected PII.

Exactly which fields it reads, and which it doesn’t

This is the detail that determines whether Data Detect will find your problem. It scans text-bearing fields: Text, Text Area, Long Text Area, Rich Text, and Text (Encrypted) fields, across both standard and custom objects, including fields that already have Shield Platform Encryption applied. That last point matters: Data Detect can look inside encrypted fields to classify them, so applying encryption doesn’t blind the scanner to what’s there.

The corollary is what it doesn’t scan, and it’s a real limitation to plan around. Data Detect is built for free text, because free text is where sensitive data ends up unexpectedly: the description, the note, the comment. It is not a scanner for every field type in the platform. A phone number in a Phone field or a date in a Date field is structured and typed on purpose; the danger Data Detect targets is the SSN that shouldn’t be in a text field at all. Scope your expectations accordingly: this finds the leak in the free-text fields, not a total inventory of every typed field in the schema.

Within those text fields, detection is pattern-based. Data Detect ships with a substantial set of prebuilt detectors: on the order of twenty distinct sensitive-data categories covering the usual suspects: credit card numbers, Social Security numbers, passport numbers, and health-related information among them. For anything org-specific, you add your own regular expressions: employee IDs, member numbers, an internal account format, a national ID pattern for a country the prebuilt set doesn’t cover. Each policy supports up to ten custom regex patterns, so you’re composing a targeted scan, not running one giant catch-all.

Building a policy that finds something useful

A Data Detect scan is defined by a policy: which objects and fields to scan, and which categories and patterns to look for. The design goal is precision: a policy scoped to the objects and categories you care about returns a result set a human can act on, where a scan of “everything for everything” returns noise.

The moves that make a policy useful:

Scope to the objects where the risk lives. Cases, Leads, custom intake objects, activity records, the places where humans type free text about people. Scanning objects that only hold structured, system-generated data wastes the scan.
Choose the categories that map to your obligations. If you’re worried about PCI, target card numbers. If it’s healthcare, target the health and identifier categories. If it’s a specific compliance regime, add the regex for its identifiers. Don’t enable every detector reflexively; each one you add is more results to triage.
Exclude fields you’ve already classified. Once you’ve reviewed a field and set its data-sensitivity classification, you can exclude already-classified fields from future scans so each run focuses on the unknown. This is what turns Data Detect from a one-time panic scan into a repeatable hygiene process. You’re always scanning the un-triaged surface.

A custom regex for an org-specific identifier, say an employee ID like EMP- followed by six digits, is exactly the kind of pattern the prebuilt set will never catch:

# Custom pattern: internal employee ID (e.g. EMP-004821)
\bEMP-\d{6}\b

Add that to a policy scoped to your case and note objects, and you’ll find every place a support rep pasted an employee identifier into a customer-facing text field where it doesn’t belong.

Getting the results out: the 200-row UI, the CSV, and the SOQL escape hatch

Running the scan is the easy part. Working the results at real volume is where teams get stuck, because the UI has a deliberately low ceiling and the escape hatch isn’t obvious.

Data Detect surfaces results at three scales, and you pick based on how much it found:

In the UI: up to 200 results per field. Fine for a quick look (is this field a problem, yes or no) and for spot-checking. Useless for remediation across a large table, because a description field on a million-row Case object with a real problem has far more than 200 hits.
CSV export: up to 10 million results. The workhorse for most remediation. Export the hits, hand the file to whoever owns the cleanup, and work through it. Ten million rows covers the overwhelming majority of real orgs.
SOQL: beyond 10 million. For the large result set, the scan results are queryable, so you pull them programmatically via the Developer Console or an API tool rather than through an export button. This is the path for enterprise-scale data and for wiring the results into an automated remediation pipeline.

The scan results include the specific Record IDs and the fields where sensitive data was found, which is what makes automated remediation possible at all. A result set that just said “this field type sometimes has PII” would be useless; a result set that says “these 40,000 record IDs have a card number in this specific field” is a work queue. If you’re comfortable querying Data 360 and the platform from Apex, the SOQL path lets you feed that queue straight into a batch job.

The limitation that reframes the whole tool: it classifies, it doesn’t clean up

Here’s the fact that changes how you plan a Data Detect project: it finds and classifies sensitive data; it does not remediate it. You end a scan knowing precisely which records and fields hold PII, and the PII is still sitting there, exactly as exposed as before you ran the scan. Data Detect is the diagnosis, not the treatment.

That’s not a flaw, but it’s a planning trap if you don’t expect it. “Run Data Detect” is not a remediation task; it’s step one of a remediation project whose real work comes after. What you do with the findings is a separate set of decisions, each with its own tool:

Reclassify the field. Update its data-sensitivity level and compliance categorization so the platform, and everyone building on it, knows the field is sensitive. This feeds directly into Transaction Security and encryption policy decisions.
Encrypt it. If sensitive data legitimately belongs in that field, apply Shield Platform Encryption so it’s protected at rest going forward.
Lock it down. Tighten field-level security so the field isn’t broadly readable, which, critically, is also what stops an agent grounded on that object from reading it, since the agent inherits the access model.
Mask it in sandboxes. Sensitive data found in production is sensitive data that gets copied to every sandbox. Data Mask is how you make sure it doesn’t leak into test orgs and developer environments.
Delete it. Sometimes the right answer is that the data should never have been there and needs to be removed, which connects to your right-to-be-forgotten and retention processes.

The point is that Data Detect’s output is an input. Budget for the remediation, not just the scan, or you’ll finish the project with a very precise map of your exposure and nothing done about it.

Why this is the step before you ground an agent

Tie it back to where we started. The Einstein Trust Layer masks PII in prompts and responses at inference time, which is real protection, but it’s protection at the edge, applied to what flows through the model. It doesn’t tell you what’s sitting in your fields, and it can’t make a good decision about a field you never classified. Trust Layer masking and field-level access control both work better when the data underneath is classified correctly, and Data Detect is how the classification gets grounded in what’s there rather than what someone assumed.

The sequence that keeps an AI rollout honest: find the sensitive data (Data Detect), classify it (sensitivity levels and compliance categorization), control it (encryption, FLS, masking, deletion), then ground the agent on what’s left. Do it in that order and the agent is reading a data set you’ve vetted. Skip the first step and you’re trusting that none of your free-text fields hold anything an agent shouldn’t surface, a bet that gets more expensive the moment a conversational layer makes every field trivially askable.

Takeaways

Data Detect is the discovery pillar of Shield. Included when you license Shield, and the tool that finds the sensitive data your other governance decisions depend on knowing about.
It reads free-text fields: Text, Text Area, Long Text Area, Rich Text, and Text (Encrypted), across standard and custom objects, including already-encrypted fields. It’s built for the PII that ends up in text unexpectedly, not a total field inventory.
Detection is pattern-based: roughly twenty prebuilt categories plus up to ten custom regex patterns per policy for org-specific identifiers.
Get results out at the right scale: 200 per field in the UI for spot checks, CSV up to 10 million for most remediation, SOQL beyond that for enterprise volume and automated pipelines.
It classifies but doesn’t remediate. The scan hands you record IDs and fields; the real work (reclassify, encrypt, restrict, mask, or delete) comes after. Budget for it.
Run it before you ground an agent. Find, classify, and control sensitive data first, so what you ground on is a data set you’ve vetted.

Finding your sensitive data isn’t glamorous, and it isn’t the part of an AI project anyone puts on a slide. But it’s the difference between an agent grounded on data you understand and an agent grounded on data you’re hoping is clean. Data Detect turns “I think our fields are fine” into a list of record IDs, and a list you can act on beats a hope you can’t.

Understanding the basics

What is Salesforce Data Detect?

Data Detect is a Salesforce Shield capability that scans free-text fields across your org to find sensitive data (things like Social Security numbers, credit card numbers, passport numbers, and health information) and reports exactly which records and fields contain it. It uses prebuilt detection categories plus custom regular expressions, and it’s included when you license Shield alongside Platform Encryption, Event Monitoring, and Field Audit Trail. Its job is discovery and classification: telling you where sensitive data lives so you can decide how to protect it.

Which fields does Data Detect scan?

It scans text-bearing fields: Text, Text Area, Long Text Area, Rich Text, and Text (Encrypted), across both standard and custom objects, including fields that already have Shield Platform Encryption applied. It’s designed for free text, where sensitive data tends to appear unexpectedly, rather than as a scanner for every typed field in your schema. Structured, purpose-built fields (like a Phone or Date field) aren’t its target; the free-text description that holds an SSN is.

Does Data Detect remove or protect the sensitive data it finds?

No. This is its most important limitation to plan around. Data Detect classifies but does not remediate, after a scan you know exactly which record IDs and fields hold sensitive data, but the data is still there. Remediation is a separate set of actions: update the field’s sensitivity classification and compliance categorization, apply Shield Platform Encryption, tighten field-level security, mask the data in sandboxes with Data Mask, or delete it. Treat the scan as step one of a remediation project, not the whole project.

How do I get Data Detect results for a very large object?

Data Detect surfaces up to 200 results per field in the UI, which is fine for spot checks. For remediation at scale, export a CSV of up to 10 million results. For result sets beyond 10 million, the scan results are queryable with SOQL through the Developer Console or an API tool, which is also the path for wiring the findings into an automated remediation pipeline. Because results include specific record IDs and field names, the SOQL output can feed directly into a batch job.

Planning to ground agents on your Salesforce and Data 360 data, and not sure what sensitive information is hiding in your free-text fields? Finding and classifying it first is exactly the groundwork that keeps an AI rollout out of trouble. Talk to us: a clean, classified data foundation is the difference between an agent you can trust and one you have to hope about.