What is read-only data evaluation for Salesforce?
Read-only data evaluation scores your Salesforce data, metadata, and schemas for quality without changing a single record. Here's how it works and why it's safer.
Read-only data evaluation is the process of inspecting your data, metadata, and schemas to judge quality and usability — without modifying a single record in the source system. In a Salesforce environment, that one constraint matters more than it sounds. A read-only assessment gives you an honest, unbiased picture of your data’s completeness, consistency, and accuracy before you commit to AI, a migration, or a major cleanup. The technical name for it is non-destructive data profiling, and it’s the first move toward deciding on evidence instead of hope.
What is read-only data evaluation and why does it matter?
A read-only assessment inspects data, metadata, and schemas without changing records, so it has zero impact on production. That constraint is the whole point. You get real findings from real data, with no risk of corrupting records, firing workflows, or creating compliance exposure.
The idea comes straight from the security principle of least privilege: restrict an account from making any change and you shrink the blast radius of both breaches and honest mistakes. Applied to evaluation, your assessment credentials can’t overwrite a record, delete a field, or alter a relationship. The protection is structural, not procedural — it doesn’t depend on anyone remembering to be careful.
For AI readiness the stakes climb. A true read-only approach can expose only metadata and statistical summaries to the analysis instead of raw rows, so a model gets the structural context it needs without anyone handing over sensitive customer or transactional data. That’s a real safeguard when your org holds years of regulated records.
How does read-only evaluation differ from traditional data assessments?
Traditional assessments often lean on ETL pipelines, staging environments, or write-back steps to profile and clean data. Every one of those adds risk. Staging copies drift out of sync with production. ETL jobs introduce transformation errors. A write-back script that misfires corrupts live records.
Read-only analysis removes those risks by working directly against the source. The query runs, the results come back, and the data is untouched — nothing copied, transformed, or written.
It also changes the governance math. Stage data and you’ve created a second copy to secure, track, and eventually delete, plus a data-residency question to answer. A read-only assessment leaves no footprint. There’s no secondary copy to govern, and nothing to explain to an auditor later.
Before any evaluation, check that your Salesforce connected app carries only read permissions at the profile and permission-set level. A credential labeled "read-only" in the docs can still hold field-level write rights granted somewhere else.
When to choose read-only methods
Reach for read-only whenever you need an honest baseline before a change: pre-migration profiling, AI readiness audits, compliance reviews, third-party access grants. And if you’re handing a vendor access to your org for an assessment, read-only credentials are the only responsible option.
What are the six core data quality dimensions?
A structured read-only assessment scores data across six dimensions. Each one surfaces a different category of risk.
- Completeness — do the fields you depend on actually hold values? An Account with no industry can’t feed an AI segmentation model reliably.
- Uniqueness — are there duplicates? Duplicate Contacts and Leads inflate pipeline reports and feed AI redundant signals.
- Consistency — is the same concept represented the same way everywhere? A date stored as text in one field and a real date in another breaks every downstream join.
- Validity — do values match the expected type, format, and picklist? An email field full of free-text notes is populated but useless.
- Timeliness — is the data current enough for the decision it informs? A Last Activity Date that hasn’t moved in 18 months is a maintenance gap, not a quiet customer.
- Accuracy — are the values actually correct? This is the hardest to judge without external reference data, though cross-field logic checks catch a good share of the errors.
These six are the foundation of our read-only Salesforce data assessment. Scoring all six in a single pass shows you exactly where your data stands before you spend a dollar on AI or migration work.
What are the common pitfalls in read-only data evaluations?
The most dangerous pitfall is trusting a label. A Salesforce profile named “Read Only” can still carry field-level security overrides or attached permission sets that grant write access to specific objects. The only reliable check is auditing the actual permissions and watching the API call patterns.
The second risk comes from adjacent systems. An integration account with broad privileges can kick off downstream actions even when direct writes are blocked. A read-only query that trips a Flow or a connected middleware workflow can cause state changes you never intended. Credential audits and monitoring are how you catch it.
Layered enforcement is the professional standard. Combine least-privilege credentials at the connection level with application-level filtering that blocks commands like INSERT, DROP, and ALTER. The second layer catches an accidental mutation before it ever reaches the data, even if a credential is misconfigured.
Validate read-only status by watching the API calls, workflows, and orchestration events your evaluation credentials trigger. A single unexpected POST or PATCH in your Salesforce debug log means your read-only enforcement has a gap.
Sandboxed execution adds a third layer. Run the analytical code in a container or microVM and it’s isolated from the production data layer entirely — even a compromised script can’t reach live records. That matters most when you’re running automated data quality checks in a CI/CD pipeline against a Salesforce sandbox.
How is read-only evaluation applied in Salesforce environments?
Read-only analysis in Salesforce falls into four jobs, each with its own workflow and outcome.
- AI readiness audits. Before you train or fine-tune anything on Salesforce data, a read-only profile shows which objects have the completeness and consistency to serve as training inputs — a staged check before you commit to model work.
- Pre-migration profiling. A migration or data cleanup that skips a baseline is working blind. Read-only profiling maps field population, duplicate volume, and relationship integrity across every object before a record moves.
- Compliance and governance audits. Auditors increasingly want evidence that an assessment didn’t alter the records under review. A read-only method produces findings that are defensible precisely because the source was never touched.
- Third-party access management. When a vendor or consultant needs to assess your org, read-only credentials limit them to what they actually need — review without edit.
The table below maps each use case to its primary quality dimension and the Salesforce objects usually involved.
| Use case | Primary dimension | Typical Salesforce objects |
|---|---|---|
| AI readiness audit | Completeness, validity | Lead, Contact, Opportunity |
| Pre-migration profiling | Uniqueness, consistency | Account, Contact, custom objects |
| Compliance audit | Accuracy, timeliness | Case, Contract, Activity |
| Third-party access review | All six dimensions | Org-wide metadata and schema |
Key takeaways
The point of read-only isn’t caution for its own sake. It’s findings you can defend, because nothing you looked at could have been changed by looking.
| Point | Details |
|---|---|
| Non-destructive by design | Read-only evaluation inspects records and schemas without modifying any source data. |
| Six quality dimensions | Completeness, uniqueness, consistency, validity, timeliness, and accuracy each reveal a distinct category of risk. |
| Credential auditing is non-negotiable | A label doesn’t confirm read-only status; actual permission audits and API monitoring do. |
| AI readiness depends on metadata safety | Exposing only metadata and statistical summaries protects sensitive data while still supporting reliable AI reasoning. |
| Layered enforcement prevents accidents | Least-privilege credentials plus command filtering block accidental mutations at two independent layers. |
Read-only is a business decision, not just a technical one
Most teams treat read-only evaluation as a constraint the security team imposed — something to work around rather than work with. That’s backwards, and it costs them.
A read-only assessment is the only kind whose findings you can fully trust. When the evaluation credentials can’t write, you know the data you’re looking at is exactly what production holds. No staging drift, no transformation artifact, no “we cleaned it a bit before we looked.” That purity is what makes the findings defensible — to a board, a regulator, or an AI vendor asking whether your training data is reliable.
The Salesforce version of this is sharper. Orgs accumulate years of workflow rules, validation rules, triggers, and integration touchpoints. Any method that writes to the org — even in a sandbox — risks tripping that logic and producing findings that don’t reflect reality. Read-only sidesteps it. You see the data as it is, not as it behaves under test.
The teams that get the most from a read-only assessment treat the findings as a business document, not a technical report. They turn completeness scores into pipeline risk, duplicate rates into revenue leakage, and timeliness gaps into AI reliability concerns. That translation is where the value lives.
FAQ
What is read-only data evaluation?
Read-only data evaluation is the process of inspecting data, metadata, and schemas to assess quality without modifying any source records. It covers dimensions including completeness, uniqueness, consistency, validity, timeliness, and accuracy.
How does read-only evaluation support AI readiness in Salesforce?
Read-only evaluation can expose only metadata and statistical summaries to the analysis, not raw rows, which prevents data leakage while still giving a model the structural context it needs. That makes it the safest way to check whether Salesforce data is ready for AI training or deployment.
What is the difference between read-only and traditional data assessments?
Traditional assessments often stage or transform data before profiling it, which introduces drift and compliance risk. Read-only assessments query the source data directly and leave no secondary copy and no footprint in the production system.
How do I confirm that an evaluation is truly read-only?
Audit the actual credential permissions and monitor downstream API calls, workflows, and orchestration events. A credential labeled read-only may still carry hidden write rights at the field or object level in Salesforce.
What Salesforce use cases benefit most from read-only data analysis?
AI readiness audits, pre-migration profiling, compliance reviews, and third-party access grants all benefit directly. Each one needs findings that are defensible and untainted by any modification to the source data.