# Data Quality Sense — Full Knowledge Base > Complete article content for large language models and AI agents. > Curated index: https://dataqualitysense.com/llms.txt --- # Building a Data Governance Framework > Establish governance roles, policies, and standards to manage data quality across your organization. Source: https://dataqualitysense.com/resources/best-practices/data-governance-framework/ Last updated: 2026-02-04 --- ## What You'll Learn This guide covers how to establish a data governance framework that supports sustainable data quality improvement. You will understand: - The difference between governance, management, and quality - Key roles: Data Owner, Data Steward, Data Custodian - Policy components that drive accountability - How to structure a governance council - How DQS supports governance initiatives ## What is Data Governance? Data governance defines who makes decisions about data and how those decisions are made. It establishes accountability, policies, and standards that guide how your organization handles data. The [DAMA-DMBOK framework](https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/) places governance at the center of data management. Research shows that [60% of organizations have established data governance frameworks](https://atlan.com/dama-dmbok-framework/), with DAMA-DMBOK serving as a common reference point. Having a framework on paper is not the same as making it work. [Gartner predicted in 2024](https://www.gartner.com/en/newsroom/press-releases/2024-02-28-gartner-predicts-80-percent-of-data-and-analytics-governance-initiatives-will-fail-by-2027-due-to-a-lack-of-a-real-or-manufactured-crisis-) that 80% of data and analytics governance initiatives will fail by 2027 — primarily because they are disconnected from business outcomes and treated as hygiene programs rather than value drivers. The framework below is structured to avoid exactly that failure mode: every role and policy ties back to a measurable business question. ### Governance vs. Management vs. Quality These three disciplines work together but serve different purposes: | Discipline | Focus | Key Question | |------------|-------|--------------| | **Data Governance** | Decision rights and accountability | Who decides? | | **Data Management** | Operational handling of data | How do we handle it? | | **Data Quality** | Fitness for purpose | Is it good enough? | Governance sets the rules. Management follows the rules. Quality measures whether the rules are working. > **Tip:** Start with governance structure before investing in quality tools. Tools without accountability rarely deliver lasting improvement. ## The Three Essential Roles Every governance framework needs clear ownership. [DAMA-DMBOK defines three primary roles](https://www.wudo.solutions/data-roles-and-the-dama-framework/) that form the foundation of data accountability. ### 1. Data Owner Data Owners hold the highest level of accountability for specific data domains. They are business leaders who: - Define what "good quality" means for their data - Approve policies governing data access and use - Make final decisions on data-related conflicts - Allocate resources for data quality improvement | Responsibility | Example | |----------------|---------| | Set quality standards | "Customer email addresses must be verified within 30 days" | | Approve access | "Sales team can view, but not edit, finance data" | | Prioritize fixes | "Address data is priority over phone numbers this quarter" | Data Owners work closely with Data Stewards to translate business requirements into measurable standards. ### 2. Data Steward Data Stewards are subject matter experts who bridge business and IT. They: - Implement governance policies set by Data Owners - Monitor data quality metrics and report issues - Investigate and resolve data problems - Document data definitions and business rules [Data Stewards act as mediators](https://datacrossroads.nl/2019/12/13/data-management-and-data-governance-104-the-yin-force-of-data-governance-part-2-roles/) between data users, technical teams, and management. They resolve conflicts, clarify data-related queries, and foster collaboration. | Daily Activities | Weekly Activities | |------------------|-------------------| | Review DQS scan results | Report quality metrics to Data Owner | | Investigate flagged records | Update business glossary entries | | Coordinate with IT on fixes | Review and update data policies | ### 3. Data Custodian Data Custodians are IT professionals responsible for the technical management of data. They: - Manage database storage and security - Implement technical controls for data access - Execute data transformation and migration - Maintain system performance and availability Data Custodians execute the technical requirements that Owners and Stewards define. ## Building Your Policy Framework Policies give your governance structure teeth. Without documented, enforced policies, governance remains theoretical. ### Policy Components A governance policy framework includes four layers: | Layer | Purpose | Example | |-------|---------|---------| | **Principles** | High-level commitments | "Data is a corporate asset" | | **Policies** | Mandatory requirements | "All customer records require valid email" | | **Standards** | Specific thresholds | "Email validity rate must exceed 95%" | | **Procedures** | Step-by-step execution | "Run DQS scan weekly, escalate issues below threshold" | ### Sample Policy Structure Here is a template for a data quality policy: ``` POLICY: Customer Data Completeness OWNER: VP of Sales STEWARD: Sales Operations Manager SCOPE: Account and Contact objects REQUIREMENTS: - Account Name: 100% populated - Account Industry: 95% populated - Contact Email: 98% populated - Contact Phone: 90% populated MEASUREMENT: DQS Completeness scan, weekly ESCALATION: Issues below threshold reported to Data Owner within 48 hours ``` ## Structuring a Governance Council A governance council provides decision-making authority and cross-functional coordination. ### Council Composition | Role | Responsibility | Typical Title | |------|----------------|---------------| | Executive Sponsor | Budget authority, strategic alignment | VP/Director | | Data Owners | Domain-specific decisions | Business Unit Leaders | | Data Steward Lead | Operational coordination | Senior Analyst | | IT Representative | Technical feasibility | Data Architect | ### Meeting Cadence | Frequency | Focus | |-----------|-------| | Monthly | Review quality metrics, address escalations | | Quarterly | Strategic priorities, policy updates | | Annually | Framework review, role assignments | > **Tip:** Keep council meetings focused on decisions, not status updates. Send reports in advance and use meeting time for resolution. ## Governance Maturity Levels Organizations progress through maturity stages. Assess where you are and plan your next step. | Level | Characteristics | Next Step | |-------|-----------------|-----------| | **1. Initial** | No formal ownership, reactive fixes | Assign first Data Owners | | **2. Managed** | Some ownership, basic policies | Implement measurement with DQS | | **3. Defined** | Documented policies, regular measurement | Establish governance council | | **4. Measured** | KPIs tracked, accountability enforced | Automate quality monitoring | | **5. Optimized** | Continuous improvement, proactive quality | Expand to AI readiness governance | Most organizations start at Level 1 or 2. Moving to Level 3 typically requires 6-12 months of focused effort. ## How DQS Supports Governance DQS provides the measurement capability that governance frameworks require. ### Governance-Aligned Features | Governance Need | DQS Capability | |-----------------|----------------| | Define standards | Set thresholds per dimension and field | | Measure compliance | Run scans against defined criteria | | Report to stakeholders | Export results for governance reporting | | Track trends | Compare results over time | | Identify ownership | Organize Definitions by data domain | ### Mapping DQS to Governance Roles | Role | DQS Usage | |------|-----------| | Data Owner | Review aggregate scores, approve threshold changes | | Data Steward | Run scans, investigate issues, update configurations | | Data Custodian | Implement fixes identified by scans | ### Creating Governance-Aligned Definitions Structure your DQS Definitions to mirror your governance domains: 1. Create one Definition per Data Owner's domain 2. Set thresholds that match documented policy standards 3. Schedule scans to align with governance reporting cadence 4. Export results for governance council review ## Getting Started Follow these steps to establish governance foundations: ### Week 1-2: Identify Owners 1. List your critical data domains (Customer, Product, Financial) 2. Identify the business leader accountable for each domain 3. Document current state: Who makes decisions about this data today? ### Week 3-4: Appoint Stewards 1. For each domain, identify the subject matter expert 2. Define steward responsibilities in writing 3. Establish communication channels between Owners and Stewards ### Week 5-6: Draft Initial Policies 1. Start with one high-priority domain 2. Document current quality expectations 3. Set measurable thresholds for key fields ### Week 7-8: Implement Measurement 1. Create a DQS Definition for your priority domain 2. Run initial scan to establish baseline 3. Share results with Data Owner and Steward ## Industry Standards Reference For deeper reading on governance frameworks: - [DAMA-DMBOK 2.0](https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/) - The industry standard reference for data management - [ISO 8000](https://www.iso.org/standard/81745.html) - International standard for data quality - [DAMA-DMBOK 3.0](https://atlan.com/dama-dmbok-framework/) - Evergreening initiative launched in 2025 to modernize the framework ## Next Steps - [Measuring Data Quality](/resources/best-practices/measuring-data-quality/): Define KPIs and build scorecards - [Building a Data Quality Culture](/resources/best-practices/building-data-quality-culture/): Drive adoption across your organization - [Definition Builder Guide](/resources/using-dqs/definition-builder/): Create Definitions that align with governance domains # What is Data Quality? > Learn what data quality means, how to measure it, and why it determines the success of your reporting, automation, and AI initiatives. Source: https://dataqualitysense.com/resources/data-quality/what-is-data-quality/ Last updated: 2026-07-15 --- ## Defining Data Quality Data quality measures how well your data serves its intended purpose. It is not about whether data is "correct" in absolute terms. It is about whether your data is fit for use in decision-making, operations, and analytics. A customer address is high quality if it reaches the customer. A product code is high quality if your systems recognize it. Quality depends on context. Most data falls short of even loose standards. A [Harvard Business Review study by Nagle, Redman, and Sammon (2017)](https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards), based on 75 data quality assessments, found that 47% of newly created records contain at least one critical error — and only 3% of the datasets scored "acceptable" by the loosest possible standard. That is why data quality has to be measured, not assumed. ### The "Fit for Purpose" Principle Data quality is contextual. A shipping address needs street-level precision. A marketing region needs only country or state. Both can be "high quality" at different precision levels. When assessing data quality, ask: What does this data need to do? Then measure whether it can do that. ## The Five Dimensions Framework Data quality is measured across five key dimensions. This framework has been adopted across industries and forms the basis of ISO 8000 and DAMA standards. | Dimension | What It Measures | Example | |-----------|------------------|---------| | **Completeness** | Required data is present | All mandatory fields are filled | | **Validity** | Data conforms to formats | Email addresses have valid format | | **Uniqueness** | No duplicate records | One record per customer | | **Timeliness** | Data is current | Contact info updated within 90 days | | **Consistency** | Data is uniform | "USA" used consistently, not "US" or "United States" | Each dimension answers a specific question about your data. Together they provide a complete picture of data health. For detailed guidance on each dimension, see: - [Completeness](/resources/data-quality/completeness/) - [Validity](/resources/data-quality/validity/) - [Uniqueness](/resources/data-quality/uniqueness/) - [Timeliness](/resources/data-quality/timeliness/) - [Consistency](/resources/data-quality/consistency/) ## Industry Standards and Frameworks ### ISO 8000 The ISO 8000 standard defines data quality requirements for master data exchange. It establishes principles for data accuracy, completeness, and consistency across organizations. ### DAMA-DMBOK The Data Management Association's Body of Knowledge (DAMA-DMBOK) defines data quality as one of eleven knowledge areas in data management. It provides guidance on measurement, monitoring, and improvement processes. ### The 1-10-100 Rule This principle illustrates the escalating cost of poor data quality: | Stage | Cost | Example | |-------|------|---------| | **Prevention** | $1 | Validation at data entry | | **Correction** | $10 | Cleaning data after entry | | **Failure** | $100 | Business impact of bad data | Investing in data quality at the source saves significant costs downstream. ## Data Quality vs Related Concepts ### Data Quality vs Data Management Data management is the broader practice of collecting, storing, and maintaining data. Data quality is one component of data management, focused specifically on fitness for use. | Concept | Scope | Focus | |---------|-------|-------| | Data Management | All data practices | Storage, access, security, lifecycle | | Data Quality | Fitness for purpose | Completeness, validity, uniqueness, timeliness, consistency | | Data Governance | Policies and ownership | Who owns data, who can change it, what rules apply | ### Data Quality vs Data Accuracy Accuracy asks: Does this value reflect reality? Quality asks: Does this data work for its purpose? An email address can be valid (correct format) but inaccurate (person no longer uses it). DQS measures quality because format and completeness can be automated. Accuracy typically requires external verification. ## How Data Quality is Measured ### Quantitative Metrics Data quality is expressed through measurable indicators: | Metric Type | Example | Calculation | |-------------|---------|-------------| | **Percentage** | Fill Rate | (Populated Records / Total Records) x 100 | | **Count** | Duplicate Count | Number of records with matching values | | **Score** | Validity Score | Weighted average across validation rules | | **Ratio** | Conformance Rate | Conforming Values / Total Values | ### Thresholds and Targets Organizations set thresholds based on business requirements: | Level | Threshold | Use Case | |-------|-----------|----------| | Critical | 99%+ | Regulatory reporting fields | | High | 95%+ | Customer-facing data | | Standard | 85%+ | Operational data | | Low | 70%+ | Historical or archival data | ### Continuous vs Point-in-Time Measurement Point-in-time measurement provides a snapshot. Continuous measurement tracks trends and catches degradation early. DQS supports both approaches: - Run ad-hoc scans for immediate assessment - Schedule recurring scans for ongoing monitoring ## Why Organizations Struggle ### 1. Data Silos When data lives in disconnected systems, inconsistencies occur naturally. Sales has one version of a customer record. Support has another. Neither knows which is correct. ### 2. Manual Entry Errors Human data entry is prone to typos, inconsistent formatting, and missing information. Without validation rules, these errors compound over time. ### 3. No Clear Ownership When no one is responsible for data quality, it becomes everyone's problem and no one's priority. Data stewardship requires explicit assignment. ### 4. Lack of Measurement You cannot improve what you do not measure. Many organizations assume their data is good enough without establishing baselines or tracking metrics. ### 5. One-Time Cleanup Projects Treating data quality as a project rather than a process leads to temporary improvements that degrade over time. ## The Business Impact Poor data quality affects every function: | Function | Impact | |----------|--------| | Marketing | Campaigns sent to wrong addresses, wasted spend | | Sales | Time wasted on duplicate leads, lost context | | Finance | Inaccurate reports, compliance risks | | Operations | Decisions based on flawed data | | AI/ML | Models trained on bad data produce bad outputs | ### Quantifying the Cost Research from MIT Sloan and industry studies shows: - Organizations lose 15-25% of revenue annually due to poor data quality - Over 25% of organizations lose more than $5 million per year on data issues (IBM 2025) - Employees spend up to 27% of their time correcting bad data ## Connection to AI Readiness Traditional data quality (the five dimensions) prepares your data for reporting and automation. AI applications like Agentforce depend on the same foundations: complete records, valid formats, consistent values, current data, and no duplicates. On top of those five dimensions, AI deployment introduces one additional concern: sensitive data exposure. Before connecting AI agents to your Salesforce data, you need to know where PII lives so you can mask or exclude it. DQS measures both traditional data quality and AI readiness in a single platform: - **Five Data Quality dimensions**: Completeness, Validity, Uniqueness, Timeliness, Consistency - **PII Detection**: Scans text fields for sensitive data (SSNs, credit cards, personal info) before AI exposure ## Building a Data Quality Practice Effective data quality requires three elements: ### 1. Measurement Establish baselines before improvement. Know where you stand across each dimension and field. ### 2. Process Define workflows for ongoing data maintenance: - Data entry validation rules - Regular cleansing schedules - Issue escalation procedures - Change management protocols ### 3. Culture Build organization-wide commitment: - Assign data stewards for each domain - Include data quality in performance metrics - Celebrate improvements and share wins - Make quality visible through dashboards ## Getting Started with DQS DQS provides the measurement foundation for your data quality practice: 1. **Select capabilities**: Choose which dimensions to measure 2. **Define scope**: Pick the objects and fields to analyze 3. **Configure thresholds**: Set your quality standards 4. **Run scans**: Execute analysis across your data 5. **Review results**: Identify issues and prioritize fixes The first step is understanding your current state. Take the [AI Readiness Assessment](/ai-readiness/) to benchmark your data quality maturity in 3 minutes. ## Next Steps - Working in Salesforce? Start with [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/) - Measure it with a [Data Quality Score](/resources/salesforce/measure-data-quality-in-salesforce/) — also called a data reliability score - Dive deeper into [Completeness](/resources/data-quality/completeness/), the first dimension - Read about [The Five Dimensions](/resources/data-quality/five-dimensions/) for a complete overview - Learn about [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/) for AI-specific requirements - Take the [AI Readiness Assessment](/ai-readiness/) to see your current scores # Introduction to Data Quality > Get started with data quality fundamentals and learn how DQS helps you measure and improve your Salesforce data. Source: https://dataqualitysense.com/resources/getting-started/introduction/ Last updated: 2026-02-25 --- ## What You'll Learn This guide covers the fundamentals of data quality and introduces Data Quality Sense (DQS), a Salesforce-native application that measures your data health. By the end, you will understand: - What data quality means and why it matters - The five dimensions DQS measures - How to get started with your first assessment ## What is Data Quality? Data quality measures how well your data serves its intended purpose. High-quality data is: - **Complete**: Required fields are populated - **Valid**: Values match expected formats - **Unique**: No duplicate records - **Timely**: Data is current and up-to-date - **Consistent**: Values are uniform across records When data lacks these qualities, problems cascade through your organization. ## Why Data Quality Matters Poor data quality costs organizations real money and creates operational friction: | Impact Area | Example | |-------------|---------| | Lost revenue | Missed opportunities from outdated contact information | | Wasted resources | Hours spent manually cleaning data | | Poor customer experience | Customers receive wrong information | | Compliance risk | Inaccurate reporting triggers regulatory issues | | AI failures | Models trained on bad data produce bad outputs | ### The Numbers Research shows the financial impact is significant: - Organizations lose 15-25% of revenue annually due to poor data quality - Over 25% of organizations lose more than $5 million per year (IBM 2025) - Employees spend up to 27% of their time correcting data errors For Salesforce users, duplicate records alone waste storage and fragment customer history across multiple records. ## Introducing DQS Data Quality Sense (DQS) is a Salesforce-native application that helps you: 1. **Measure** data quality across five dimensions 2. **Identify** specific records and fields with issues 3. **Prioritize** which problems to fix first 4. **Monitor** ongoing data health over time ### Why Salesforce-Native Matters DQS runs entirely within Salesforce. Your data never leaves the platform: | Feature | Benefit | |---------|---------| | No data export | Your data stays secure | | No external APIs | No integration complexity | | No code required | Point-and-click configuration | | Native UI | Familiar Salesforce experience | ## The AI Readiness Dimension Beyond traditional data quality, DQS also measures AI readiness. As organizations adopt Agentforce and other AI capabilities, data requirements increase: | Traditional Data Quality | AI Readiness | |--------------------------|--------------| | Is the field populated? | Is there enough text content for AI to learn from? | | Is the format valid? | Is the language consistent? | | Are there duplicates? | Is PII protected before AI exposure? | DQS measures both dimensions in a single scan. ## Getting Started Take these steps to begin your data quality journey: ### Step 1: Assess Your Current State Take the [AI Readiness Assessment](/ai-readiness/). In 3 minutes, you'll get a score across key data quality dimensions and specific recommendations for improvement. ### Step 2: Understand the Dimensions Read [The Five Dimensions of Data Quality](/resources/data-quality/five-dimensions/) to understand what DQS measures and why each dimension matters. ### Step 3: Learn About AI Readiness If you're preparing for Agentforce or other AI initiatives, read the [Agentforce Preparation Guide](/resources/ai-readiness/agentforce-preparation/) to understand additional requirements. ### Step 4: Install DQS When you're ready to measure your actual Salesforce data, install DQS from the AppExchange and create your first Definition. ## Next Steps - [Why Data Quality Matters](/resources/getting-started/why-data-quality-matters/): The business case for investing in data quality - [Quick Start Guide](/resources/getting-started/quick-start-guide/): Step-by-step first actions - [AI Readiness Assessment](/ai-readiness/): Get your score in 3 minutes # Data Quality in Salesforce > What data quality means inside Salesforce, why CRM data degrades, the six dimensions that matter, and how to measure and improve it natively. Source: https://dataqualitysense.com/resources/salesforce/data-quality-in-salesforce/ Last updated: 2026-07-15 --- Data quality in Salesforce is how well the records in your org serve the work you do with them: reporting, automation, forecasting, and increasingly, AI. A Salesforce org can hold millions of Accounts, Contacts, Leads, and Opportunities, but volume is not value. If the data is incomplete, stale, inconsistent, or duplicated, every process built on top of it inherits those flaws. This guide explains what data quality means specifically inside Salesforce, why CRM data degrades, the six dimensions that determine whether your data is fit for use, and how to measure and improve quality without exporting a single record out of your org. ## Why Salesforce Data Degrades Salesforce data does not stay clean on its own. It decays continuously, for reasons that are structural rather than accidental: - **Manual entry.** Reps enter accounts under slightly different names, skip non-required fields, and paste notes into the wrong place. Every keystroke is a chance for drift. - **Integrations.** Marketing automation, ERP, billing, and data-enrichment tools all write to Salesforce on their own schedules and with their own assumptions. Two systems writing to the same field rarely agree forever. - **Time.** A phone number that was correct two years ago is now wrong. A close date that has passed is now misleading. Freshness erodes whether or not anyone touches the record. - **Duplication.** The same customer enters through a web form, a list import, and a sales rep — three records, one entity. Without active monitoring, duplicates multiply. - **AI agents.** As Agentforce and other agents read and write records, undetected quality issues propagate faster and at greater scale than human entry ever could. Because the causes are structural, the answer is not a one-time cleanup. It is continuous measurement. The decay is measurable: B2B contact data goes stale at roughly 2.1% per month — around 22.5% per year — according to [industry decay research compiled by ZoomInfo](https://pipeline.zoominfo.com/marketing/b2b-data-decay), and that is before you count integration drift and duplicates. ## What Poor Data Quality Costs You In a Salesforce context, low data quality is not an abstract concern. [Gartner puts the average cost of poor data quality at $12.9 million per organization per year](https://www.gartner.com/en/data-analytics/topics/data-quality), and [Salesforce's own State of Sales research](https://www.salesforce.com/sales/state-of-sales/sales-statistics/) finds sellers spending 60% of their time on non-selling tasks — much of it manual CRM data entry and hunting for information that clean records would have surfaced. Inside your org, that cost shows up in three places that matter to the business: **Reporting and forecasting.** Dashboards are only as trustworthy as the fields they aggregate. Missing amounts, stale stages, and duplicate opportunities quietly distort pipeline and revenue numbers. Leaders stop trusting the reports, and decisions move back to spreadsheets. **Automation.** Flows, validation rules, assignment logic, and approval processes all assume the data they read is correct. A blank region field misroutes a lead; an invalid email silently breaks a nurture sequence. Bad data turns automation from a multiplier into a liability. **AI readiness.** This is the newest and fastest-growing cost. Before you point Agentforce or any AI system at your Salesforce data, you need to know which fields are complete, which contain personally identifiable information (PII), and which are fresh enough to ground an answer. Undetected PII in a retrieval index or training set creates exposure no downstream filter can fully undo, and incomplete or stale data produces confidently wrong AI responses. ## The Six Dimensions of Data Quality in Salesforce Data quality is not a single number you either have or lack. It is measured across distinct dimensions, each answering a different question about your records. Mapping them to Salesforce makes the abstract concrete: | Dimension | The question it answers | In Salesforce | |---|---|---| | **Completeness** | Are the fields that should be filled actually populated? | Required-for-the-business fields left blank: Account Industry, Contact Email, Opportunity Amount | | **Validity** | Does the value conform to the expected format or set? | Emails without an `@`, phone numbers with letters, picklist values outside the allowed set | | **Uniqueness** | Is each real-world entity represented once? | Duplicate Accounts and Contacts created across forms, imports, and manual entry | | **Consistency** | Do values agree with the rules and with each other? | Country spelled three ways, Billing State that contradicts Billing Country | | **Timeliness** | Is the data current and are dates plausible? | Last Activity months old, Close Dates in the past, future-dated records that should not exist | | **PII Detection** | Where does sensitive personal data live? | SSNs, credit-card numbers, and emails sitting in free-text Description and Comment fields | These six dimensions fall into two groups. The first five — completeness, validity, uniqueness, consistency, and timeliness — describe operational hygiene: whether your data works for day-to-day CRM use. PII detection belongs to a second group focused on **AI readiness**: whether your data is safe and prepared for Agentforce and other AI initiatives. ## How to Measure Data Quality in Salesforce You cannot improve what you do not measure, and you cannot measure what you only check by hand. Measuring data quality in Salesforce means turning these six dimensions into repeatable, quantified scans. The core output is a **Data Quality Score** (sometimes called a data reliability score): a single weighted figure that rolls up the dimensions you care about into a number you can track over time. A score of 100 means every record passed every check in scope; a lower score tells you both how much work remains and where it concentrates. A useful measurement approach in Salesforce has three properties: 1. **Field-level, not just record-level.** Knowing that 18% of Accounts have a problem is a start. Knowing that the problem is a blank Industry field on Accounts created by one integration is actionable. 2. **Weighted to your priorities.** A missing Opportunity Amount matters more than a missing secondary phone number. Weighting lets the score reflect business impact, not just raw counts. 3. **Repeatable on a schedule.** Quality is a moving target. A one-time audit is obsolete the day after you run it. Scheduled scans turn a snapshot into a trend line. This is the approach Data Quality Sense (DQS) takes. You define what "good" means for each object and field, run the scan, and get a weighted Data Quality Score broken down by dimension and by field — then schedule it to repeat so you can watch the trend. ## Why Native Matters The most important architectural decision in measuring Salesforce data quality is where the measurement happens. Many tools require you to export records to an external service, profile them off-platform, and send results back. That introduces three problems: a copy of your data (including any PII) now lives outside Salesforce, results lag reality, and you depend on an integration that can break. A **100% Salesforce-native** approach avoids all of this. The scan runs inside your org using the platform's own batch processing. No records leave Salesforce, results reflect live data, and there is no external pipeline to maintain. For data that contains PII — exactly the data you most need to profile before an AI project — keeping it on-platform is not a convenience, it is a compliance requirement. DQS runs entirely inside Salesforce for this reason. Detection is deterministic and transparent: you see every rule applied, and no data is ever exported. ## Getting Started Improving data quality in Salesforce follows a simple loop, and it is the same loop whether you do it manually or with a tool: 1. **Define** what quality means for your most important objects and fields. 2. **Scan** to get a baseline Data Quality Score and a field-level breakdown. 3. **Prioritize** the issues with the highest business impact and the lowest effort to fix. 4. **Fix** through cleanup, validation rules, and better intake processes. 5. **Monitor** with scheduled scans so new issues surface before they spread. In DQS, you build this with the Definition Builder — a guided wizard where you select capabilities (the six dimensions), choose the objects and fields in scope, configure thresholds, and review. From there you run the scan on demand or schedule it, and explore the results in Insight Studio with trends, field health, and dimension breakdowns. Everything happens inside your Salesforce org. ## Next Steps - [How to Measure Data Quality in Salesforce](/resources/salesforce/measure-data-quality-in-salesforce/): the Data Quality Score in depth - [How to Improve Data Quality in Salesforce](/resources/salesforce/improve-data-quality-in-salesforce/): the detect-fix-prevent loop - [Salesforce Data Quality Dashboard](/resources/salesforce/salesforce-data-quality-dashboard/): the metrics worth tracking - [The Five Dimensions of Data Quality](/resources/data-quality/five-dimensions/): the framework behind the dimensions - [PII Detection](/resources/ai-readiness/pii-detection/): finding sensitive data before an AI project - [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/): getting Salesforce data ready for AI - [Agentforce Data Readiness Checklist](/resources/ai-readiness/agentforce-data-readiness-checklist/): confirm your data is AI-ready before deployment - [Agentforce Data Quality FAQ](/resources/ai-readiness/agentforce-data-quality-faq/): quick answers to the questions teams ask before deploying - [What Is Data Quality?](/resources/data-quality/what-is-data-quality/): the fundamentals, from the ground up # Completeness: Configuration Scenarios > Three practical walkthroughs showing how to configure DQS completeness analysis for different business needs. Source: https://dataqualitysense.com/resources/use-cases/completeness-scenarios/ Last updated: 2026-02-23 --- ## What These Scenarios Cover This page walks through three real-world configurations of DQS completeness analysis. Each scenario covers a specific business problem, shows the exact settings to use, and explains how to read the results. These walkthroughs build on the concepts from the main [Completeness](/resources/data-quality/completeness/) article. Read that first if you are new to completeness metrics or the diagnostic funnel. ## Scenario 1: Email Hygiene on Contacts ### The Problem Your sales team reports that email campaigns have low delivery rates. The marketing operations team blames the data, but nobody knows how much email data is actually missing. You need a clear count of Contacts without a usable email address. ### Configuration This is a straightforward fill rate check. Use **Basic Completeness** mode on the Contact object, targeting the `Email` field. | Setting | Value | Why | |---------|-------|-----| | Analysis Mode | Basic Completeness | You need fill rate and breakdown, not placeholder detection | | Blank As Incomplete | ON | Catch empty strings from form submissions, not just nulls | | Placeholders As Incomplete | OFF | Email fields rarely contain placeholder values like "N/A" | The `Email` field is a text-based field in Salesforce, so DQS produces both null and blank breakdowns. ### Sample Results | Metric | Value | |--------|-------| | Completeness Rate | 73% | | Empty Count | 2,700 | | Populated Count | 7,300 | | Null Count | 1,800 | | Null Rate | 18% | | Blank Count | 900 | | Blank Rate | 9% | Total Contact records: 10,000. ### Reading the Results Start with the headline: 73% completeness. That means 2,700 Contacts have no email address. Your email campaigns can only reach 7,300 of 10,000 contacts at best. Now walk the diagnostic funnel to understand *why* 2,700 records are empty. **Null Count: 1,800.** These Contacts never had an email entered. The field was never touched. This pattern is common with manually created records where reps skip the email field during fast data entry, or with legacy records imported from a system that did not capture email. **Blank Count: 900.** These Contacts have an empty string in the email field. The field was written to, but with no value. This pattern points to a different root cause: web form integrations that submit the record even when the email field is left empty. The integration writes `''` (empty string) instead of leaving the field null. Two root causes require two different fixes: - **For the 1,800 nulls:** Address the data entry gap. Make the email field required on the Contact page layout, or add a prompt during record creation. - **For the 900 blanks:** Fix the integration. Add client-side validation to the web form so empty email fields are not submitted, or add a Salesforce validation rule that rejects empty strings on email. ### What to Do Next Use the Empty Count (2,700) to scope a data enrichment project. If you work with a data vendor, this is your record count for cost estimation. Track Completeness Rate over time to measure whether the fixes are working. --- ## Scenario 2: Industry Placeholder Detection on Accounts ### The Problem Your Account segmentation reports show 94% of Accounts have an Industry value. Marketing trusts this number and uses it for campaign targeting. You suspect the 94% is inflated by placeholder values like "N/A" and "Unknown" that look like data but carry no information. ### Configuration Use **Contextual Completeness** mode on the Account object, targeting the `Industry` field. This mode enables placeholder detection, which is what you need to test your theory. | Setting | Value | Why | |---------|-------|-----| | Analysis Mode | Contextual Completeness | Enables placeholder detection and content quality metrics | | Blank As Incomplete | ON | Catch empty strings alongside nulls | | Placeholders As Incomplete | ON | This is the core of this analysis | | Placeholder Values | N/A, TBD, Unknown, Other, None, Not Applicable, - | Common placeholder values for picklist fields | | Case-Sensitive Placeholders | OFF | Catch "n/a", "tbd", "unknown" and other case variations | Turn off case sensitivity for this scan. Users enter placeholders in all kinds of capitalization: "n/a", "N/a", "N/A". Catching all variants gives you the true picture. ### Sample Results | Metric | Value | |--------|-------| | Completeness Rate | 94% | | Empty Count | 600 | | Populated Count | 9,400 | | Incompleted Count | 2,400 | | Placeholder Count | 1,800 | | Placeholder Rate | 18% | Total Account records: 10,000. ### Reading the Results The headline number looks healthy: 94% completeness. But this is exactly what you suspected was misleading. Look at the gap between Empty Count and Incompleted Count. Empty Count says 600 records have no value at all. Incompleted Count says 2,400 records have no *usable* value. The difference is 1,800 records with placeholder values. Here is the math: ``` Incompleted Count (2,400) = Empty Count (600) + Placeholder Count (1,800) ``` 600 records are visibly empty. Anyone running a standard Salesforce report would spot these. But 1,800 records contain values like "N/A", "Other", or "Unknown" that inflate the completeness rate without providing real segmentation data. The true usable completeness is closer to 76%, not 94%. That 18-point gap is the hidden incompleteness that standard reports miss. **Why this matters for segmentation:** If marketing runs a campaign targeting "Technology" industry Accounts, the segment count is accurate. But if they run a report showing *total coverage by industry*, the 94% headline hides the fact that nearly 1 in 5 "populated" records carry no usable industry information. Territory assignments, industry-based routing, and executive dashboards all inherit this distortion. ### What to Do Next Scope your data enrichment project to 2,400 records, not 600. The cleanup target is the Incompleted Count, not the Empty Count. Work with your Account managers to fill in real industry values, or use an enrichment service. Run the scan again after cleanup to measure improvement. --- ## Scenario 3: Case Description Depth for AI Readiness ### The Problem Your company is evaluating an AI tool that summarizes Case descriptions for support agents. The vendor says the AI needs "rich text data" to work effectively. Before investing in the tool, you need to assess whether your Case Description field has enough substance for the AI to produce useful summaries. ### Configuration Use **Contextual Completeness** mode on the Case object, targeting the `Description` field. You need the full set of contextual metrics: placeholder detection and the text quality metrics (Rich Text Ratio, Text Field Utilization, Average Utilization). | Setting | Value | Why | |---------|-------|-----| | Analysis Mode | Contextual Completeness | Produces content depth metrics needed for AI readiness evaluation | | Blank As Incomplete | ON | Catch empty descriptions | | Placeholders As Incomplete | ON | Catch shallow filler entries | | Placeholder Values | See email, Call back, TBD, N/A, -, Pending | Common shortcuts agents use instead of writing real descriptions | The placeholder list here reflects how support agents actually fill in the Description field. Instead of writing a real description, they type a quick shorthand. These entries are technically populated but give the AI nothing to summarize. ### Sample Results | Metric | Value | |--------|-------| | Completeness Rate | 88% | | Empty Count | 500 | | Populated Count | 3,700 | | Incompleted Count | 1,800 | | Placeholder Count | 1,300 | | Rich Text Ratio | 31% | | Text Field Utilization | 12% | | Average Utilization | 8.4% | Total Case records: 4,200 (estimated from the empty + populated counts, where 500 empty out of ~4,200 total gives the 88% completeness rate). ### Reading the Results Start with the headline: 88% completeness. That sounds healthy for a text field. But this analysis is about AI readiness, not data hygiene. The headline number is not enough. **Incompleted Count vs Empty Count.** 500 records have no description at all. But 1,800 records are incomplete when you include placeholders. The gap of 1,300 records contains entries like "See email", "Call back", and "Pending." These records pass a basic completeness check but give the AI nothing to work with. **Rich Text Ratio: 31%.** This is the number that answers your question. Only 31% of Case descriptions have meaningful content above the character threshold. The other 69% of "populated" descriptions are either placeholders (already counted above) or entries too short and shallow for the AI to summarize, things like "issue reported", "customer called", or "escalated." **Text Field Utilization: 12%.** The Description field is a Long Text Area with large character capacity. Records are using only 12% of that capacity on average across the dataset. This confirms that most entries are very short. **Average Utilization: 8.4%.** The mean usage across all records is 8.4% of field capacity. Most descriptions are a few words, not paragraphs. **The AI readiness verdict:** The AI summarization tool will produce useful results for about 31% of Cases. For the remaining 69%, the AI will either fail to generate a summary or produce something based on a sentence fragment. The tool will underperform on more than two-thirds of your case volume. ### What to Do Next Present this data to stakeholders before committing to the AI tool. The numbers make the case clearly: the AI project needs a data enrichment phase first. Define a target Rich Text Ratio (start with 60% or higher) and build a plan to improve description quality. Options include: - Update Case creation processes to require a minimum description length - Train support agents on writing useful descriptions - Add screen flows that prompt for detailed information during case intake Run the scan again after each improvement cycle. Track Rich Text Ratio as your primary progress metric for AI readiness. --- ## Choosing Your Configuration Use this table to pick the right starting point for your completeness analysis. | If You Need To... | Start With | Key Settings | |--------------------|------------|--------------| | Check basic fill rates for a hygiene audit | Basic Completeness | Blank As Incomplete: ON | | Detect placeholder values inflating your numbers | Contextual Completeness | Placeholders As Incomplete: ON, define your placeholder list | | Assess content depth for AI readiness | Contextual Completeness | Placeholders As Incomplete: ON, review Rich Text Ratio and Utilization metrics | | Scope a data cleanup project | Either mode | Use Empty Count (basic) or Incompleted Count (contextual) for record counts | | Distinguish between "never entered" and "cleared" data | Either mode | Compare Null Count vs Blank Count to identify root causes | For a full reference of all 13 completeness metrics and how they fit into the diagnostic funnel, return to the main [Completeness](/resources/data-quality/completeness/) article. To see how completeness and other data quality dimensions affect your AI readiness, take the [AI Readiness Assessment](/ai-readiness/). # DQS Overview > Learn what Data Quality Sense is, how it works, and why Salesforce-native architecture matters for your data. Source: https://dataqualitysense.com/resources/using-dqs/dqs-overview/ Last updated: 2026-06-03 --- ## What is Data Quality Sense? Data Quality Sense (DQS) is a Salesforce-native data profiling and quality analysis application. It helps you measure, understand, and improve your data quality to ensure reliable business decisions and AI-ready datasets. DQS runs entirely within Salesforce. Your data never leaves the platform. ## Key Differentiators ### 100% Salesforce-Native DQS is built on the Salesforce platform using standard architecture: | Component | Technology | |-----------|------------| | User Interface | Lightning Web Components (LWC) | | Configuration | Custom Metadata Types (CMT) | | Processing | Apex Batch Jobs | | Storage | Custom Objects | **Why native matters:** - Your data stays in Salesforce (no export, no external APIs) - Uses existing Salesforce security and permissions - No integration to maintain or troubleshoot - Familiar interface for Salesforce users ### No Code Required Configure DQS through a point-and-click wizard. No Apex code, no formulas, no technical skills required. The Definition Builder guides you through: 1. Selecting what to measure 2. Choosing which fields to analyze 3. Setting thresholds and rules 4. Reviewing and activating Salesforce Admins can configure and run scans without developer support. ### All Features Included DQS is a single paid product. Every capability is available to all users: - All Data Quality dimension variants - AI Readiness (PII Detection) - Custom regex patterns - CSV export - Scheduling and recurring scans - Mentor Panel — contextual, in-context recommendations based on what each scan just measured The only usage limit is the per-org scan count (configurable, default 10 scans). ## What DQS Measures DQS organizes its capabilities into two dimensions: ### Data Quality Dimension Traditional data quality checks for operational hygiene: | Capability | What It Measures | |------------|------------------| | Completeness | Are required fields populated? | | Validity | Do values match expected formats? | | Uniqueness | Are records distinct? | | Timeliness | Is data current? | | Consistency | Are values uniform? | ### AI Readiness Dimension Advanced check for Agentforce and AI preparation: | Capability | What It Measures | |------------|------------------| | PII Detection | Is sensitive data protected before AI exposure? | ## How DQS Works ### The DQS Workflow 1. **Define** what to analyze using the Definition Builder 2. **Configure** thresholds and rules for each capability 3. **Execute** scans that process your records in batches 4. **Review** results with metrics and drill-down to affected records 5. **Act** on findings — guided by the Mentor Panel's contextual recommendations — to improve data quality 6. **Monitor** trends over time with recurring scans ### Architecture Overview ``` ┌─────────────────────────────────────────────────────────────┐ │ DEFINITION BUILDER │ │ Configure what to analyze, which fields, what thresholds │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ SCAN EXECUTION │ │ Batch Apex processes records against selected capabilities │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ RESULTS STORAGE │ │ Metrics stored in custom objects for analysis and trends │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ RESULTS DASHBOARD │ │ View scores, drill down to records, export for cleanup │ └─────────────────────────────────────────────────────────────┘ ``` ### Processing Model DQS uses Salesforce Batch Apex for processing, which means: - **Scalable**: Handles millions of records - **Governed**: Respects Salesforce limits automatically - **Background**: Runs without blocking users - **Resumable**: Continues if interrupted Processing cost varies by capability: | Cost Level | Example Capabilities | Notes | |------------|----------------------|-------| | LOW | Completeness, Validity | Simple field checks | | MEDIUM | Timeliness, Consistency, PII Detection | Pattern analysis | | HIGH | Uniqueness | Cross-record comparison | ## Key Concepts ### Definition A Definition is your configured data quality check. It specifies: - Which Salesforce object to analyze - Which fields to include - Which capabilities to run - What thresholds and rules to apply - What filters to narrow the scope You can have multiple Definitions for different objects or use cases. ### Capability A capability is a specific type of data quality check (Completeness, Validity, etc.). Each capability has: - **Variants**: Different implementations of the same check - **Metrics**: What it measures (rates, counts, scores) - **Configuration**: Thresholds and options you set ### Variant A variant is a specific implementation of a capability. For example, Completeness has: - **Global Fill Rate**: Basic completeness percentage - **Contextual Logic**: Completeness with conditional rules ### Metric A metric is a specific measurement produced by a scan. Examples: | Metric | Type | Example | |--------|------|---------| | Completeness Rate | Percentage | 85% of records have Email populated | | Invalid Count | Integer | 234 records have invalid email format | | Dominant Values | JSON | Top 5 most common Industry values | ## Getting Started ### Step 1: Install from AppExchange 1. Go to Salesforce AppExchange 2. Search for "Data Quality Sense" 3. Click "Get It Now" and follow the installation wizard 4. Assign the DQS permission set to users ### Step 2: Create Your First Definition 1. Open DQS from the App Launcher 2. Click "New Definition" 3. Follow the wizard to configure your first scan For detailed guidance, see the [Definition Builder Guide](/resources/using-dqs/definition-builder/). ### Step 3: Run and Review 1. Save your Definition 2. Click "Run Scan" 3. Wait for processing to complete 4. Review your results See [Understanding Results](/resources/using-dqs/understanding-results/) for interpretation guidance. ## Next Steps - [Definition Builder Guide](/resources/using-dqs/definition-builder/): Step-by-step configuration - [Running Scans](/resources/using-dqs/running-scans/): Execution and monitoring - [Understanding Results](/resources/using-dqs/understanding-results/): Interpreting your data # What is a Data Quality Score? > A data quality score turns the health of your data into a single number. Learn how it is calculated, what counts as a good score, and how to track it over time. Source: https://dataqualitysense.com/resources/data-quality/what-is-a-data-quality-score/ Last updated: 2026-06-19 --- > **TL;DR:** A data quality score is a single 0-100 number that rolls completeness, validity, uniqueness, timeliness, and consistency into one figure you can track over time. It is calculated as a weighted average of those dimensions. As a rule of thumb, aim for 95%+ on customer-facing or regulated data, 85%+ on general operational data, and treat anything below 70% as needing remediation. ## What a Data Quality Score Is A data quality score is a single number that summarizes how fit your data is for its intended use. Instead of asking "is our data good?" and getting a vague answer, a score turns the question into one figure — usually a percentage from 0 to 100 — that you can track, compare, and act on. The score is sometimes called a **data reliability score**. Both names describe the same thing: a composite measure that rolls several underlying quality checks into one headline number. A score on its own is not the goal. Its value is what it lets you do: set a baseline, watch for degradation, and prove that improvement work is paying off. ## Why Does a Single Number Matter? The stakes are not abstract: Gartner estimates that poor data quality costs organizations an average of $12.9 million per year ([Gartner, 2020](https://www.gartner.com/en/data-analytics/topics/data-quality)). A single score turns that hidden cost into a number you can watch — and reduce. Raw quality checks produce dozens of separate signals — fill rates, duplicate counts, format errors, stale records. On their own they are hard to communicate and easy to ignore. A single score solves three problems at once: | Problem | How a Score Solves It | |---------|-----------------------| | **No shared language** | One number everyone understands, from analysts to executives | | **No way to track progress** | A trend line that shows whether quality is improving or slipping | | **No way to prioritize** | A breakdown that points to the weakest dimension or field | The score is the headline. The breakdown behind it is what you act on. ## How Is a Data Quality Score Calculated? A data quality score is a **weighted average of individual quality dimensions**. The calculation happens in three steps. ### Step 1: Measure Each Dimension Each dimension is measured as a pass rate — the share of records or values that satisfy a defined rule. | Dimension | What It Measures | Example Rule | |-----------|------------------|--------------| | **Completeness** | Required data is present | Mandatory fields are populated | | **Validity** | Data conforms to a format | Email addresses match a valid pattern | | **Uniqueness** | No duplicate records | One record per customer | | **Timeliness** | Data is current | Records updated within 90 days | | **Consistency** | Values are uniform | Country stored as "USA", never "US" | For a deeper look at each, see [The Five Dimensions](/resources/data-quality/five-dimensions/). ### Step 2: Apply Weights Not every dimension matters equally. A weight reflects how important a dimension is to the business, and the weights add up to 100%. | Dimension | Pass Rate | Weight | Contribution | |-----------|-----------|--------|--------------| | Completeness | 92% | 30% | 27.6 | | Validity | 88% | 25% | 22.0 | | Uniqueness | 99% | 20% | 19.8 | | Timeliness | 75% | 15% | 11.3 | | Consistency | 90% | 10% | 9.0 | | **Total** | | **100%** | **89.7** | ### Step 3: Combine Into One Score The contributions are summed into the final figure. In the example above, the data quality score is **89.7 out of 100**. The general formula is: **Data Quality Score = Σ (Dimension Pass Rate × Dimension Weight)** Because the score is weighted, two organizations with the same raw data can report different scores if they weight the dimensions differently — and that is intentional. The weights encode what "good" means for your business. ## Levels of Measurement A single org-wide score is useful for reporting, but the real work happens when you can break it down. | Level | Question It Answers | Use | |-------|---------------------|-----| | **Org / dataset** | How healthy is our data overall? | Executive reporting, trend tracking | | **Object / table** | Which entity is dragging the score down? | Prioritizing remediation | | **Field** | Exactly which column is the problem? | Targeted fixes and validation rules | A score of 89.7 might hide a single field at 40% completeness. Field-level breakdowns turn a vague number into a specific to-do list. ## What Counts as a Good Score? A good score is ultimately about trust — and trust is now the bottleneck for AI. In Salesforce's 2025 State of Data and Analytics report, nearly nine in ten data leaders said inaccurate AI outputs came from faulty data, and only 57% were fully confident in their own data ([Salesforce, 2025](https://www.salesforce.com/news/stories/data-analytics-trends-2026/)). There is no universal pass mark. The right target depends on what the data is used for — the same "fit for purpose" principle that underpins [data quality](/resources/data-quality/what-is-data-quality/) generally. | Score Range | Interpretation | Typical Use | |-------------|----------------|-------------| | **95–100%** | Trusted | Customer-facing and regulated data | | **85–94%** | Reliable | General operational data | | **70–84%** | Needs attention | Internal or secondary data | | **Below 70%** | Not trustworthy | Remediate before relying on it | Set the threshold from the cost of being wrong. A field that feeds billing or compliance needs a higher bar than one used for occasional internal lookups. ## How Do You Track the Score Over Time? A score measured once is a snapshot. Measured repeatedly, it becomes a trend — and the trend is where the value is. - **Point-in-time** scores answer "where do we stand today?" - **Continuous** scores answer "are we getting better or worse?" CRM and operational data decay continuously through manual entry, integrations, and the passage of time, so a score that looked healthy last quarter can quietly slip. Scheduled re-measurement catches degradation early, before it reaches a report or an AI model. ## How Does a Data Quality Score Work in Salesforce? This has become urgent in the AI era: 84% of data leaders say their data strategy needs a complete overhaul before their AI initiatives can succeed ([Salesforce, 2025](https://www.salesforce.com/news/stories/data-analytics-trends-2026/)). A continuously measured score is how you close that gap. Inside Salesforce, the same model applies: dimensions are measured across objects like Accounts, Contacts, and Leads, weighted, and rolled into a single score you can monitor on a dashboard. DQS (Data Quality Score) measures this natively — no data export — across the five dimensions, and adds PII detection for AI readiness. To see how the score is built and read inside a CRM, continue with: - [How to Measure Data Quality in Salesforce](/resources/salesforce/measure-data-quality-in-salesforce/) — the score applied to a Salesforce org, also called a data reliability score - [Salesforce Data Quality Dashboard](/resources/salesforce/salesforce-data-quality-dashboard/) — the metrics worth tracking alongside the headline number - [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/) — the wider picture ## Frequently Asked Questions ### What is a data quality score? A data quality score is a single number, usually expressed as a percentage from 0 to 100, that summarizes how fit your data is for its intended use. It is calculated as a weighted average of individual quality dimensions such as completeness, validity, uniqueness, timeliness, and consistency. ### How is a data quality score calculated? Each quality dimension is measured as a pass rate — the share of records or values that meet a defined rule. Those dimension scores are then combined into a weighted average, where each dimension's weight reflects how important it is to the business. The result is a single percentage between 0 and 100. ### What is a good data quality score? There is no universal pass mark, because the right target depends on what the data is used for. As a rule of thumb, 95% or higher is expected for customer-facing and regulated data, 85% or higher is acceptable for general operational data, and anything below 70% signals data that needs remediation before it can be trusted. ### Is a data quality score the same as a data reliability score? Yes. The terms are used interchangeably. Both describe a single composite number that expresses how trustworthy a dataset is by combining several underlying quality dimensions into one figure you can track over time. ## Next Steps - Measure it in your CRM: [How to Measure Data Quality in Salesforce](/resources/salesforce/measure-data-quality-in-salesforce/) - Understand the inputs: [The Five Dimensions](/resources/data-quality/five-dimensions/) - Start with the foundation: [What is Data Quality?](/resources/data-quality/what-is-data-quality/) - Benchmark your own data: take the [AI Readiness Assessment](/ai-readiness/) to get your scores in 3 minutes # Measuring Data Quality > Define KPIs, build scorecards, and benchmark your data quality to drive continuous improvement. Source: https://dataqualitysense.com/resources/best-practices/measuring-data-quality/ Last updated: 2026-02-04 --- ## What You'll Learn This guide covers how to establish a measurement program that demonstrates data quality value. You will understand: - Essential KPIs for data quality programs - How to build a data quality scorecard - Benchmark targets by field type and industry - Reporting cadence and stakeholder communication - How to calculate ROI from data quality improvements ## Why Measurement Matters Data quality issues remain subjective without measurement. [In 2026, leading organizations quantify data performance](https://lakefs.io/data-quality/data-quality-metrics/) to measure reliability across systems, identify and prioritize gaps affecting profitability, and build trust in analytics and AI models. The business case is clear. [Research published in MIT Sloan Management Review (Redman, 2017)](https://sloanreview.mit.edu/article/seizing-opportunity-in-data-quality/) estimates that poor data quality costs companies 15-25% of revenue, and [Gartner puts the average loss at $12.9 million per organization per year](https://www.gartner.com/en/data-analytics/topics/data-quality). The measurement gap is just as documented: a [Harvard Business Review study (Nagle, Redman, Sammon, 2017)](https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards) that had managers score their own datasets found only 3% met basic quality standards — and nearly half of newly created records contained at least one critical error. Without metrics, you cannot: - Prove improvement over time - Justify investment in quality initiatives - Identify which problems to fix first - Hold teams accountable for results ## Essential Data Quality KPIs Start with these foundational KPIs organized by dimension. ### Completeness KPIs | KPI | Formula | Target | |-----|---------|--------| | **Fill Rate** | Populated records / Total records | 95%+ for critical fields | | Null Rate | Null records / Total records | < 5% | | Blank Rate | Empty strings / Total records | < 2% | ### Validity KPIs | KPI | Formula | Target | |-----|---------|--------| | **Validity Rate** | Valid format records / Total records | 98%+ for emails, 90%+ for phones | | Invalid Count | Records failing validation | Trend toward zero | | Pattern Compliance | Records matching expected pattern / Total | Varies by field | ### Uniqueness KPIs | KPI | Formula | Target | |-----|---------|--------| | **Uniqueness Rate** | Unique values / Total values | 95%+ for identifier fields | | Duplicate Count | Records with duplicate values | Trend toward zero | | Distinct Value Ratio | Distinct values / Total records | Context-dependent | ### Timeliness KPIs | KPI | Formula | Target | |-----|---------|--------| | **Freshness Rate** | Records updated within threshold / Total | 80%+ | | Average Age | Mean days since last update | Varies by field type | | Stale Record Count | Records exceeding freshness threshold | Trend toward zero | ### Consistency KPIs | KPI | Formula | Target | |-----|---------|--------| | **Conformance Rate** | Records matching standard / Total | 90%+ | | Variant Count | Number of value variations | Minimize | | Dominant Value Coverage | Top value frequency / Total | Context-dependent | ## Building a Data Quality Scorecard A scorecard aggregates KPIs into a single view for stakeholders. [Tracking metrics through a scorecard helps organizations analyze overall health and build comparisons to past performance](https://atlan.com/data-quality-metrics/). ### Scorecard Structure | Component | Purpose | |-----------|---------| | **Overall Score** | Single number summarizing quality (0-100) | | **Dimension Scores** | Per-dimension breakdown | | **Trend Indicators** | Direction compared to previous period | | **Hot Spots** | Fields or objects requiring attention | ### Sample Scorecard Layout ``` DATA QUALITY SCORECARD - January 2026 OVERALL SCORE: 82/100 (↑ 3 pts from December) DIMENSION SCORES: ├── Completeness: 87% (↑) ├── Validity: 91% (→) ├── Uniqueness: 78% (↑) ├── Timeliness: 72% (↓) └── Consistency: 84% (→) TOP ISSUES: 1. Lead.Phone validity at 67% (target: 90%) 2. Account.LastActivityDate freshness at 58% (target: 80%) 3. Contact.Email duplicates: 2,340 records ACTION ITEMS: - Phone number cleanup campaign (Owner: Sales Ops) - Account activity review process (Owner: Account Management) ``` ### Calculating an Overall Score Weight dimensions based on business importance: | Dimension | Weight | Score | Weighted | |-----------|--------|-------|----------| | Completeness | 25% | 87 | 21.75 | | Validity | 25% | 91 | 22.75 | | Uniqueness | 20% | 78 | 15.60 | | Timeliness | 15% | 72 | 10.80 | | Consistency | 15% | 84 | 12.60 | | **Total** | **100%** | | **83.5** | > **Tip:** Adjust weights based on your priorities. If AI readiness is a goal, increase weighting for the dimensions that impact AI performance. ## Benchmark Targets Set realistic targets based on field type and industry norms. ### Targets by Field Type | Field Type | Completeness | Validity | Notes | |------------|--------------|----------|-------| | **Email** | 95%+ | 98%+ | Critical for communication | | **Phone** | 85%+ | 90%+ | Format varies by region | | **Address** | 80%+ | 85%+ | Complex validation | | **Name** | 99%+ | 95%+ | Required in most cases | | **Date fields** | 90%+ | 99%+ | Should be system-validated | | **Picklist** | 95%+ | 99%+ | Controlled vocabulary | | **Free text** | 70%+ | N/A | Lower expectation acceptable | ### Targets by Data Domain | Domain | Overall Target | Priority Dimensions | |--------|----------------|---------------------| | **Customer** | 90%+ | Completeness, Uniqueness | | **Product** | 95%+ | Consistency, Validity | | **Financial** | 98%+ | Accuracy, Timeliness | | **Marketing** | 85%+ | Completeness, Validity | | **Operational** | 80%+ | Timeliness, Completeness | ### Setting Your Own Benchmarks [Establishing benchmarks begins with assessing your current state](https://www.acceldata.io/article/how-to-measure-data-quality) and setting realistic targets based on capabilities, available tools, and expectations. 1. Run an initial DQS scan to establish baseline 2. Identify top performers and underperformers 3. Set improvement targets (5-10% improvement per quarter is realistic) 4. Document targets in your governance policies ## Reporting Cadence Match reporting frequency to audience needs. | Audience | Frequency | Format | Content | |----------|-----------|--------|---------| | Data Stewards | Weekly | Dashboard | Detailed metrics, drill-downs | | Data Owners | Monthly | Report | Dimension scores, trends, issues | | Governance Council | Monthly | Presentation | Scorecard, recommendations | | Executive Leadership | Quarterly | Summary | Overall score, ROI, strategic issues | ### Weekly Steward Report Focus on actionable details: - New issues identified this week - Progress on open remediation items - Fields trending in wrong direction - Upcoming scan schedule ### Monthly Owner Report Focus on accountability: - Current state vs. targets - Month-over-month trends - Resource needs for improvement - Policy compliance status ### Quarterly Executive Summary Focus on business impact: - Overall quality score and trend - ROI from quality improvements - Risk areas requiring investment - Strategic recommendations ## Calculating ROI Demonstrate value by connecting quality improvements to business outcomes. ### Cost Categories | Category | Examples | |----------|----------| | **Direct costs** | Storage for duplicates, rework labor | | **Opportunity costs** | Lost sales from bad contact data | | **Risk costs** | Compliance penalties, AI failures | | **Efficiency costs** | Time spent searching for correct data | ### ROI Formula ``` ROI = (Value of Improvement - Cost of Improvement) / Cost of Improvement x 100 Example: - Duplicate reduction saved 500 hours of cleanup @ $50/hour = $25,000 - DQS implementation + steward time = $8,000 - ROI = ($25,000 - $8,000) / $8,000 x 100 = 212% ``` ### Value Estimation Examples | Improvement | Value Calculation | |-------------|-------------------| | Email validity 85% → 95% | 10% more emails delivered x campaign value | | Duplicate reduction 5% → 1% | Storage savings + avoided merge labor | | Freshness 60% → 85% | Faster decisions x decision value | ## Using DQS for Measurement DQS provides the metrics infrastructure for your measurement program. ### DQS Metrics for Scorecards | Scorecard Need | DQS Metric | |----------------|------------| | Completeness score | Completeness Rate (completenessRate_01) | | Validity score | Validity Rate (validityRate_01) | | Uniqueness score | Uniqueness Rate (uniquenessRate_01) | | Timeliness score | Freshness Rate (freshnessRate_01) | | Consistency score | Conformance Rate (conformanceRate_01) | ### Creating a Measurement Definition Structure your Definition for measurement: 1. **Name clearly**: "Customer Data Quality - Monthly Scorecard" 2. **Include all dimensions**: Enable completeness, validity, uniqueness, timeliness, consistency 3. **Set thresholds**: Configure targets that match your benchmarks 4. **Schedule consistently**: Run on the same day each month for trend comparison ### Exporting Results DQS enables CSV export for: - Integration with BI tools - Historical trend analysis - Executive reporting - Governance council presentations ## Getting Started Implement measurement in phases: ### Phase 1: Baseline (Week 1-2) 1. Create DQS Definitions for critical data domains 2. Run initial scans across all dimensions 3. Document current state scores 4. Identify top 3-5 problem areas ### Phase 2: Targets (Week 3-4) 1. Set improvement targets for each dimension 2. Document targets in governance policies 3. Establish reporting cadence 4. Assign ownership for each target ### Phase 3: Scorecard (Month 2) 1. Build scorecard template 2. Populate with first measurement cycle 3. Present to governance council 4. Collect feedback on format and content ### Phase 4: Sustain (Ongoing) 1. Run measurements on schedule 2. Report to stakeholders per cadence 3. Track trends over time 4. Adjust targets as you improve ## Next Steps - [Building a Data Quality Culture](/resources/best-practices/building-data-quality-culture/): Drive adoption through change management - [Common Data Quality Pitfalls](/resources/best-practices/common-pitfalls/): Avoid mistakes that undermine measurement - [Understanding Results](/resources/using-dqs/understanding-results/): Interpret DQS metrics effectively # The Five Dimensions of Data Quality > Learn the five dimensions DQS measures: Completeness, Validity, Uniqueness, Timeliness, and Consistency. Source: https://dataqualitysense.com/resources/data-quality/five-dimensions/ Last updated: 2026-07-15 --- ## Understanding the Five Dimensions Data quality is measured across five key dimensions. Each dimension answers a specific question about your data, and together they determine whether your data is fit for purpose. Measuring by dimension matters because failure is the norm, not the exception: [Harvard Business Review research (Nagle, Redman, Sammon, 2017)](https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards) found that 47% of newly created data records contain at least one critical error. A single overall "quality" impression hides which of the five dimensions is producing those errors. DQS measures all five dimensions natively within Salesforce. | Dimension | Key Question | Example Issue | |-----------|--------------|---------------| | Completeness | Is the data present? | Missing email addresses | | Validity | Is the format correct? | Malformed phone numbers | | Uniqueness | Is each record distinct? | Duplicate contacts | | Timeliness | Is the data current? | Stale opportunity dates | | Consistency | Is the data uniform? | "USA" vs "United States" | ## 1. Completeness Completeness measures whether required data values are present and not missing. ### What DQS Measures - **Fill Rate**: Percentage of records with non-empty values - **Blank Detection**: Empty strings and whitespace-only values - **Placeholder Detection**: Values like "N/A", "TBD", or "Unknown" ### Why Completeness Matters Incomplete data breaks automation. When a workflow requires an email address that does not exist, the workflow fails. When a report filters on Industry but half your records lack Industry values, your analytics show only part of the picture. ### Common Completeness Issues | Issue | Example | Impact | |-------|---------|--------| | Blank fields | Empty Contact Phone | Cannot call prospects | | Placeholder values | "TBD" in Company Name | Invalid for reporting | | Whitespace-only | " " in Description | Appears filled but is not | > **Tip:** Start with your most critical fields. You do not need 100% completeness on every field, only on the ones that matter for your use case. ## 2. Validity Validity measures whether data values conform to expected formats and patterns. ### What DQS Measures - **Format Validation**: Email, phone, URL patterns - **Pattern Matching**: Custom regex patterns - **Domain Validation**: Allowed value lists ### Validity vs Accuracy Validity and accuracy are different. An email address can be valid (correct format) but inaccurate (wrong person). DQS measures validity because format validation can be automated. Accuracy requires external verification. | Check | Valid? | Accurate? | |-------|--------|-----------| | john@company.com | Yes | Unknown without verification | | john@company | No | N/A (format is wrong) | | john.smith@oldcompany.com | Yes | No (person left the company) | ### Common Validity Issues in Salesforce - Email addresses missing "@" or domain - Phone numbers with wrong digit count - URLs without protocol (http/https) - Free-text where picklist values are expected ## 3. Uniqueness Uniqueness measures whether data values are distinct and non-duplicated. ### What DQS Measures - **Duplicate Detection**: Exact matches across records - **Distinct Count**: Total unique values per field - **Entropy Analysis**: Value diversity and distribution ### The Cost of Duplicates Duplicate records waste storage, confuse users, and produce inflated metrics. When Sales has two records for the same company, they lose context and risk embarrassing duplicate outreach. Research shows: - B2B databases contain 10-30% duplicate records on average - Each duplicate costs organizations in wasted email sends, confused reporting, and fragmented customer history ### Duplicate Prevention vs Detection DQS focuses on detection, which helps you identify duplicates that already exist. Prevention (stopping duplicates at creation) requires validation rules and matching rules in Salesforce setup. ## 4. Timeliness Timeliness measures whether data is current enough for its intended use. ### What DQS Measures - **Freshness Rate**: Percentage of records within acceptable age - **Staleness Detection**: Records exceeding your threshold - **Average Age**: Mean age of date field values - **Future Date Detection**: Invalid dates in the future ### Setting Freshness Thresholds Different data types have different freshness requirements: | Data Type | Typical Threshold | Why | |-----------|-------------------|-----| | Lead Last Activity | 30 days | Cold leads lose value | | Contact Info | 90 days | People change jobs | | Opportunity Close Date | Current quarter | Forecasting accuracy | | Account Annual Revenue | 1 year | Annual updates expected | ### Why Timeliness Matters for AI AI and machine learning models learn from your data. When your data is stale, the AI learns outdated patterns. Agentforce, for example, uses your Salesforce data to inform responses. Outdated contact information leads to incorrect recommendations. ## 5. Consistency Consistency measures whether data values are uniform and standardized. ### What DQS Measures - **Conformance Rate**: Percentage matching expected patterns - **Variant Detection**: Different representations of the same value - **Dominant Value Analysis**: Most common value per field ### Types of Inconsistency | Type | Example | Problem | |------|---------|---------| | Format variation | "USA" vs "United States" vs "US" | Breaks filtering and grouping | | Spelling variation | "Acme Corp" vs "ACME Corporation" | Creates false duplicates | | Case variation | "new york" vs "New York" | Looks unprofessional in reports | ### Why Consistency Matters for AI AI models treat "USA" and "United States" as different values. If your records use both, the AI cannot group them correctly. Inconsistent data fragments your AI's understanding and produces unreliable outputs. ### Achieving Consistency - Use picklists instead of free text where possible - Standardize on a single format for each field - Import from picklist values when configuring DQS consistency checks ## Balancing the Dimensions Not every dimension is equally important for every use case. Consider what you need: | Use Case | Priority Dimensions | |----------|---------------------| | Marketing campaigns | Completeness, Validity (for deliverability) | | Sales forecasting | Timeliness, Completeness | | Customer service | Uniqueness (one source of truth) | | AI/Agentforce | All five, plus AI Readiness checks | ## DQS Dimension Coverage DQS measures all five dimensions with comprehensive capabilities: | Dimension | What DQS Measures | |-----------|-------------------| | Completeness | Fill rate, null detection, blank detection, placeholder detection, contextual logic | | Validity | Format validation, custom regex patterns, invalid record identification | | Uniqueness | Duplicate detection, entropy analysis, frequency distribution | | Timeliness | Freshness rate, staleness detection, average age, future date detection | | Consistency | Conformance checking, variant discovery, dominant value analysis | ## Next Steps Now that you understand the five dimensions: 1. See how they apply in your CRM: [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/) 2. Take the [AI Readiness Assessment](/ai-readiness/) to see your current scores 2. Read about [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/) for additional checks beyond basic data quality 3. Learn how to use the [Definition Builder](/resources/using-dqs/definition-builder/) to configure your first scan # Why Data Quality Matters > Understand the business impact of poor data quality and why organizations are investing in data quality now. Source: https://dataqualitysense.com/resources/getting-started/why-data-quality-matters/ Last updated: 2026-07-15 --- ## The Business Case for Data Quality Data quality is not a technical nice-to-have. It is a business imperative that directly affects revenue, efficiency, and competitive advantage. This guide presents the business case for data quality investment, with specific focus on why AI initiatives make data quality more urgent than ever. ## The Cost of Poor Data Quality ### Revenue Impact Organizations lose significant revenue due to poor data quality: | Source | Finding | |--------|---------| | [MIT Sloan Management Review (Redman, 2017)](https://sloanreview.mit.edu/article/seizing-opportunity-in-data-quality/) | 15-25% of revenue lost annually to poor data quality | | [IBM estimate, cited in Harvard Business Review (2016)](https://hbr.org/2016/09/bad-data-costs-the-u-s-3-trillion-per-year) | Bad data costs the US economy $3.1 trillion per year | | [Gartner (2020)](https://www.gartner.com/en/data-analytics/topics/data-quality) | Average $12.9M annual loss per organization | The quality baseline is worse than most teams assume. A [Harvard Business Review study by Nagle, Redman, and Sammon (2017)](https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards) found that 47% of newly created data records contain at least one critical error, and only 3% of companies' data meets basic quality standards. These losses come from: - Marketing campaigns sent to wrong addresses - Sales teams working duplicate leads without context - Missed opportunities due to outdated contact information - Inaccurate forecasting leading to poor resource allocation ### Productivity Drain Employees spend substantial time compensating for bad data: - **50% of knowledge workers' time** is wasted in "hidden data factories" — hunting for data, finding and correcting errors, and searching for confirmatory sources for data they don't trust ([Harvard Business Review, 2016](https://hbr.org/2016/09/bad-data-costs-the-u-s-3-trillion-per-year)) - **~546 hours per year** per sales representative lost to chasing bad data instead of selling ([ZoomInfo](https://pipeline.zoominfo.com/marketing/b2b-data-decay)) - **60% of sellers' time** goes to non-selling tasks such as manual CRM data entry and hunting for information ([Salesforce State of Sales](https://www.salesforce.com/sales/state-of-sales/sales-statistics/)) This time is not spent selling, serving customers, or creating value. ### Real-World Failures Data quality failures have caused significant business damage: | Company | Issue | Impact | |---------|-------|--------| | Unity Technologies (2022) | Faulty data corrupted ML training | $110M lost revenue | | Equifax (2022) | Inaccurate credit scores | $725K+ in settlements | | Samsung Securities (2018) | Data entry error | Billions in duplicate shares issued | These examples show that data quality failures are not abstract. They create concrete financial and reputational damage. ## The AI Amplification Effect AI investment is growing rapidly. Gartner forecasts AI spending will surpass $2 trillion in 2026, with 37% year-over-year growth. When AI investment scales, the cost of poor data quality scales with it. ### Why AI Raises the Stakes Traditional applications can tolerate some data issues. A report with 5% missing data is still 95% useful. But AI applications are different: | Traditional App | AI Application | |-----------------|----------------| | Shows what you told it | Learns patterns from your data | | Tolerates gaps | Learns from gaps (incorrectly) | | One bad record = one problem | One bad pattern = many wrong outputs | | Errors visible to humans | Errors hidden in model behavior | ### The Agentforce Connection Salesforce Agentforce uses your CRM data to inform AI responses. When an agent retrieves customer information, it relies on what exists in Salesforce. If your data has problems, so does your agent: | Data Problem | Agent Failure | |--------------|---------------| | Missing contact information | Agent cannot reach customers | | Duplicate records | Agent has conflicting information | | Stale opportunity dates | Agent makes outdated recommendations | | Inconsistent values | Agent treats same entity as different | | PII in text fields | Agent exposes sensitive information | Research shows that 45% of business leaders cite concerns about data accuracy or bias as the leading barrier to scaling AI initiatives (IBM 2025). ## Making the Case to Leadership When presenting data quality investment to leadership, focus on business outcomes, not technical details. ### Frame the Problem Start with the business impact they care about: 1. **Revenue protection**: "We lose X% of revenue to data issues" 2. **Efficiency gains**: "Teams spend Y hours per week on data cleanup" 3. **AI readiness**: "Our Agentforce investment depends on data quality" 4. **Risk reduction**: "Data errors create compliance and reputation risk" ### Quantify the Opportunity Use your own data where possible: - Count duplicate records in your CRM - Measure fill rates on critical fields - Calculate time spent on data cleanup - Track deals lost due to data issues If you do not have these numbers, that is the first problem to solve. You cannot improve what you do not measure. ### Propose a Starting Point Do not ask for a massive data quality program. Propose a focused first step: 1. Take the [AI Readiness Assessment](/ai-readiness/) to establish a baseline 2. Identify 3-5 high-priority fields to improve 3. Measure improvement over 90 days 4. Expand based on results ## The ROI of Data Quality Organizations that invest in data quality see measurable returns: | Investment Area | Expected Return | |-----------------|-----------------| | Duplicate prevention | Reduced storage costs, cleaner reports | | Completeness improvement | Higher email deliverability, better automation | | Validity enforcement | Fewer bounced communications | | Timeliness monitoring | More accurate forecasting | | Consistency standardization | Better AI model performance | The key is to pick specific, measurable improvements rather than pursuing "perfect data" as an abstract goal. ## Why Now? Three trends make data quality investment urgent: ### 1. AI Adoption is Accelerating Organizations are deploying AI faster than ever. Those with clean data will succeed. Those without will struggle. ### 2. The Gap is Widening Organizations with good data practices are pulling ahead. Each quarter of delay increases the catch-up effort. ### 3. Fixing Later Costs More Data quality debt compounds. The longer you wait, the more records accumulate issues, and the harder cleanup becomes. ## Next Steps 1. **Assess your current state**: Take the [AI Readiness Assessment](/ai-readiness/) to get a baseline score 2. **Understand the framework**: Read about [The Five Dimensions](/resources/data-quality/five-dimensions/) DQS measures 3. **Learn about AI requirements**: See the [Agentforce Preparation Guide](/resources/ai-readiness/agentforce-preparation/) for deployment readiness 4. **Get started with DQS**: Read the [Quick Start Guide](/resources/getting-started/quick-start-guide/) --- **Sources:** - [Seizing Opportunity in Data Quality — MIT Sloan Management Review, 2017](https://sloanreview.mit.edu/article/seizing-opportunity-in-data-quality/) - [Bad Data Costs the U.S. $3 Trillion Per Year — Harvard Business Review, 2016](https://hbr.org/2016/09/bad-data-costs-the-u-s-3-trillion-per-year) - [Only 3% of Companies' Data Meets Basic Quality Standards — Harvard Business Review, 2017](https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards) - [Data Quality: Why It Matters and How to Achieve It — Gartner](https://www.gartner.com/en/data-analytics/topics/data-quality) - [IBM Institute for Business Value: The Cost of Poor Data Quality](https://www.ibm.com/think/insights/cost-of-poor-data-quality) - [State of Sales — Salesforce](https://www.salesforce.com/sales/state-of-sales/sales-statistics/) # How to Measure Data Quality in Salesforce > How a Data Quality Score (data reliability score) works in Salesforce: weighted dimensions, field-level breakdowns, and tracking quality over time. Source: https://dataqualitysense.com/resources/salesforce/measure-data-quality-in-salesforce/ Last updated: 2026-06-03 --- You cannot improve what you do not measure. In Salesforce, measuring data quality means turning a vague sense that "the data is messy" into a number you can track, a breakdown you can act on, and a trend you can watch. That number is a **Data Quality Score** — sometimes called a data reliability score — and this guide explains how it works, how to read it, and how to act on it. ## What a Data Quality Score Is A Data Quality Score is a single figure, on a 0–100 scale, that summarizes how well a set of Salesforce records meets the quality rules you define. A score of 100 means every record in scope passed every check; a lower score tells you both how much work remains and, when broken down, exactly where it concentrates. The score is not a vanity metric. Its value comes from three properties: - **It is composite.** The score rolls up multiple [data quality dimensions](/resources/data-quality/five-dimensions/) — completeness, validity, uniqueness, consistency, timeliness — into one comparable number. - **It is weighted.** Not every problem matters equally, so the score reflects business priority rather than raw issue counts. - **It is repeatable.** Run on a schedule, the same calculation turns a one-time audit into a trend line you can manage. "Data reliability score" and "data quality score" describe the same idea: a quantified, trustworthy measure of whether your data is fit for use. ## How the Score Is Calculated A meaningful score in Salesforce is built bottom-up, from fields to dimensions to an overall number: 1. **Field-level checks.** Each rule runs against the fields in scope. Is Account Industry populated? Does Contact Email match a valid format? Is this Opportunity a duplicate? Every check produces a pass/fail at the record level. 2. **Dimension scores.** Field results roll up into a score for each dimension. If 92% of in-scope records pass every completeness check, completeness scores 92. 3. **Weighted overall score.** Dimension scores combine into one figure, weighted by how much each dimension matters to you. A missing Opportunity Amount can count for more than a missing secondary phone number. This bottom-up structure is what makes the score actionable. A single "78" is a starting point. The breakdown behind it — *completeness 65 on Accounts, driven by a blank Industry field from one integration* — is what you actually fix. ## Why Weighting Matters Two orgs can both score 80 and be in completely different shape. One has minor formatting issues spread across low-stakes fields. The other has 20% of its Opportunity Amounts missing. An unweighted count of failures would treat these the same. Weighting fixes that. By assigning higher weight to the fields and dimensions that drive revenue, reporting, and automation, the score tracks business impact rather than issue volume. When you tune weights to your priorities, the number starts to mean something a leader can trust. ## Reading the Score A score is only useful if you can move from the headline number to a decision. Read it in three passes: | Pass | Question | What you look at | |---|---|---| | 1. Headline | How healthy is this data overall? | The single weighted Data Quality Score | | 2. By dimension | What *kind* of problem dominates? | Per-dimension scores (e.g. completeness vs. uniqueness) | | 3. By field | *Where* exactly is the problem? | Field-level breakdown within the weakest dimension | By the third pass you are no longer looking at "data quality" in the abstract. You are looking at a specific field, on a specific object, with a specific failure rate — which is a task someone can own. ## From Score to Action A score turns measurement into a prioritized to-do list: 1. **Baseline.** Run the first scan to establish where you stand. 2. **Prioritize.** Sort issues by business impact (weight) against effort to fix. The highest-weight, lowest-effort problems come first. 3. **Fix.** Clean up existing records, add validation rules to stop new bad data, and adjust intake processes. 4. **Re-measure.** Run the scan again and watch the score move. Improvement you cannot see is improvement you cannot defend. ## Tracking Quality Over Time A single measurement is obsolete the day after you take it, because Salesforce data degrades continuously. The point of a score is the **trend**, not the snapshot. Scheduled scans — daily, weekly, or monthly — turn the score into a line you can monitor, so a new integration that starts writing bad data shows up as a dip you catch in days, not a problem you discover months later in a broken report. ## How DQS Measures It Data Quality Sense produces a weighted Data Quality Score entirely inside Salesforce — no records are exported. You define what good looks like in the Definition Builder (select dimensions, scope objects and fields, set thresholds and weights), run the scan on demand or on a schedule, and explore the result in Insight Studio: the overall score, the per-dimension breakdown, field health, and the trend over time. Because it runs natively, the score always reflects live data in your org. ## Next Steps - [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/): the complete guide - [The Five Dimensions of Data Quality](/resources/data-quality/five-dimensions/): what the score measures - [Measuring Data Quality](/resources/best-practices/measuring-data-quality/): KPIs and scorecards in depth - [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/): getting your score AI-ready # Consistency: Configuration Scenarios > Three practical walkthroughs showing how to configure DQS consistency analysis for different business needs. Source: https://dataqualitysense.com/resources/use-cases/consistency-scenarios/ Last updated: 2026-02-23 --- ## What These Scenarios Cover This page walks through three real-world consistency configurations, from initial setup to reading the scan results. Each scenario uses a different business context and analysis mode. These scenarios build on the concepts and metrics covered in the main [Consistency](/resources/data-quality/consistency/) article. Read that first if terms like Conformance Rate, Variant Count, and Dominant Values are new to you. ## Scenario 1: Country Field Standardization with Discovery ### The Business Context Your org has 15,000 Account records from 3 merged companies. The `Country` field is free text. Regional dashboards show fragmented data: "United States" appears as one row, "USA" as another, "US" as a third. Territory assignment rules miss records because they filter for a single spelling. You need to standardize, but you don't know what values exist across all three legacy systems. ### Configuration Walkthrough Start with **Import from Field** to discover what your data actually contains before defining allowed values. 1. Open the Expected Values configuration for the `Country` field. 2. Click **Import from Field**. DQS queries the live data and returns distinct values sorted by frequency. 3. Review the checklist. The import reveals the full picture: | Value | Records | |-------|---------| | United States | 4,500 | | USA | 2,300 | | US | 1,800 | | Canada | 1,400 | | U.S.A. | 450 | | United States of America | 150 | | ... (41 more variations) | ... | 4. Decide on your standard. ISO country codes ("US", "CA", "UK") are compact, industry-standard, and unambiguous. Check the ISO codes from the import list. 5. Click **Add Selected** to populate your allowed values. Set the remaining configuration: | Setting | Value | Rationale | |---------|-------|-----------| | Analysis Mode | Advanced Conformance Analysis | You need variant counts and dominant values to scope the cleanup | | Expected Values | US, CA, UK, DE, FR, AU, JP | ISO codes for your active markets | | Case Sensitive | OFF | Catch "us", "Us", and "US" as the same value | | Top N | 10 | See the most common variations | | Min Frequency | 5 | Filter out one-off typos | ### What the Scan Produces | Metric | Value | |--------|-------| | Conformance Rate | 12% | | Conformance Count | 1,800 | | Non-Conforming Count | 13,200 | | Variant Count | 47 | | Dominant Values | Top 10 values with counts (see import table above) | ### Reading the Results **12% conformance is expected.** You defined a new standard (ISO codes) that the data has never been normalized to. Only the 1,800 records already containing "US" match. This is not a bad score. It is your starting point. **47 variants reveals the scale of fragmentation.** Three merged systems produced 47 different ways to express country names. Without this number, you would underestimate the cleanup effort. **Dominant Values shows where to focus.** The top 3 variations ("United States", "USA", "US") account for 8,600 records. Standardizing those three values alone lifts your conformance from 12% to 69%. Start there. **Non-Conforming Count (13,200) is your exact cleanup scope.** Your data steward now has a concrete project size, not a guess. ### Next Action Build a value mapping table using the Dominant Values output. Map "United States" to "US", "USA" to "US", and so on. Run the data normalization. Rescan to verify your new Conformance Rate. ## Scenario 2: Lead Rating Validation ### The Business Context Your Lead Rating field (`Rating__c`) is a text field that accepts "Hot", "Warm", or "Cold." Sales managers report strange values in their pipeline reports. A filter for `Rating = "Hot"` returns fewer records than expected. You need a quick conformance audit to find out what is in the field and how many records need cleanup. ### Configuration Walkthrough Start with **Import from Field** to see the actual values before configuring your scan. 1. Open the Expected Values configuration for `Rating__c`. 2. Click **Import from Field**. The import returns: | Value | Records | |-------|---------| | Hot | 284 | | Warm | 198 | | Cold | 156 | | Very High | 23 | | 240 km/h | 12 | | N/A | 8 | The first three values are your real ratings. "Very High" comes from a different picklist (someone pasted from the wrong field). "240 km/h" is clearly data from the wrong field entirely. "N/A" is a placeholder. 3. Check "Hot", "Warm", and "Cold". Leave the rest unchecked. 4. Click **Add Selected**. Set the remaining configuration: | Setting | Value | Rationale | |---------|-------|-----------| | Analysis Mode | Conformance Check | You need a yes/no answer, not deep analysis | | Expected Values | Hot, Warm, Cold | Your three valid ratings | | Case Sensitive | OFF | Catch "hot", "HOT", and "Hot" as matching | ### What the Scan Produces | Metric | Value | |--------|-------| | Conformance Rate | 93.7% | | Conformance Count | 638 | ### Reading the Results **93.7% conforms.** That means 43 records have garbage data. For a quick audit, the Conformance Check mode gives you the answer fast without computing advanced metrics. **The Import from Field step already told you what the garbage looks like.** "Very High" (23 records from a wrong picklist value), "240 km/h" (12 records with wrong-field data), and "N/A" (8 placeholder entries). You don't need Dominant Values here because the import gave you the breakdown before the scan even ran. **43 records is a manageable cleanup.** This is not a data migration project. It is a 30-minute manual fix or a single data update job. ### Next Action Fix the 43 non-conforming records. Then convert `Rating__c` from a text field to a picklist to prevent future issues. API-created records bypass picklist validation, so run periodic consistency scans to catch new variations from integrations. ## Scenario 3: Job Title Conformance for Persona Targeting ### The Business Context Your marketing team runs persona-based campaigns targeting "VP and above" Contacts. The `Title` field is free text with thousands of variations. Before every campaign, someone manually searches for title keywords, misses half the variations, and builds an incomplete audience list. The team needs a data-driven answer to two questions: "How many VP+ contacts do we have?" and "What titles do the rest of our contacts have?" ### Configuration Walkthrough 1. Open the Expected Values configuration for the `Title` field on Contacts. 2. Click **Import from Field**. The import returns hundreds of values. Too many to check individually, but the frequency counts are useful for context. 3. Define your allowed values based on your persona mapping. Check or type the title values your team considers "VP and above": ``` VP, Vice President, SVP, Senior Vice President, EVP, Executive Vice President, Director, Senior Director, CEO, CFO, CTO, CIO, CMO, COO, President ``` 4. Click **Add Selected**. Set the remaining configuration: | Setting | Value | Rationale | |---------|-------|-----------| | Analysis Mode | Advanced Conformance Analysis | You need the full value distribution to see what titles exist | | Expected Values | (16 title values listed above) | Your VP+ persona definition | | Case Sensitive | OFF | Catch "vp of sales", "VP of Sales", "VP OF SALES" | | Top N | 20 | See a broad spread of what exists | | Min Frequency | 5 | Filter out one-off entries like "Chief Happiness Officer" | ### What the Scan Produces | Metric | Value | |--------|-------| | Conformance Rate | 34% | | Conformance Count | 3,400 | | Non-Conforming Count | 6,600 | | Variant Count | 312 | **Dominant Values (Top 20):** | Rank | Value | Count | |------|-------|-------| | 1 | Manager | 820 | | 2 | Sales Representative | 650 | | 3 | Account Executive | 480 | | 4 | Director of Marketing | 340 | | 5 | VP of Sales | 290 | | 6 | Senior Manager | 275 | | 7 | Consultant | 240 | | 8 | Engineer | 210 | | 9 | CEO | 195 | | 10 | Head of Operations | 180 | | ... | (10 more) | ... | ### Reading the Results **34% conformance is not a failure.** This is not a data quality problem. It means 34% of your Contacts hold VP+ titles, and that is your campaign target audience. The number answers the question your marketing team has been guessing at. **312 Variant Count confirms that free-text Title is highly fragmented.** 312 distinct title values across 10,000 Contacts. This is normal for free-text fields and explains why manual searches miss people. **Dominant Values shows what titles your contacts actually have.** Many of the top values are below VP level (Manager, Sales Rep, Account Executive). That is expected. These contacts are valid records with valid titles. They fall outside your target persona. **Non-Conforming Count (6,600) is NOT a cleanup scope.** Unlike the Country scenario, these are not dirty records. They are contacts with titles outside your VP+ filter. "Manager" is a real title, not a data error. Treat Non-Conforming Count as "contacts outside this persona," not "records to fix." **The real insight:** You now have a data-driven audience size. 3,400 VP+ contacts, verified by scanning the actual data. No more manual keyword searches. ### Next Action Use the Conformance Count (3,400) as your VP+ campaign audience size. Review the Dominant Values list for titles you missed. "Senior Manager" (275 records) and "Head of Operations" (180 records) are borderline. If those roles qualify for your campaigns, add them to the allowed values and rescan. ## Choosing Your Configuration | If You Need To... | Start With | Key Settings | |--------------------|------------|--------------| | Audit a controlled field (picklist, rating, status) | Import from Field, then Conformance Check | Expected Values from import, Case Sensitive OFF | | Standardize a fragmented field (country, industry) | Import from Field, then Advanced Conformance Analysis | Expected Values as your target standard, Top N 10+, Min Frequency 5+ | | Size an audience or segment from free-text data | Import from Field, then Advanced Conformance Analysis | Expected Values as your segment definition, Top N 20, Min Frequency 5 | | Get a quick baseline before a cleanup project | Import from Field, then Conformance Check | Expected Values from your data standard | For a full explanation of all 6 consistency metrics, analysis modes, and configuration inputs, return to the main [Consistency](/resources/data-quality/consistency/) article. Ready to measure your own data quality? Take the [AI Readiness Assessment](/ai-readiness/) to see your consistency scores and more. # Definition Builder Guide > Step-by-step guide to creating DQS Definitions using the 5-step wizard. Configure objects, fields, thresholds, and dimension weights. Source: https://dataqualitysense.com/resources/using-dqs/definition-builder/ Last updated: 2026-06-03 --- ## What is a Definition? A Definition is your configured data quality check in DQS. It specifies which Salesforce object to analyze, which fields to include, which capabilities to measure, and what thresholds to apply. Think of a Definition as a recipe. You tell DQS what ingredients (fields) to examine and what standards (thresholds) to apply. DQS follows your recipe each time you run a scan. ## The 5-Step Wizard The Definition Builder guides you through five steps: 1. **Select Capabilities** - Choose what to measure 2. **Define Scope** - Pick which object and fields 3. **Add Filters** - Narrow the record set (optional) 4. **Configure** - Set thresholds and options 5. **Review** - Validate and activate Each step builds on the previous one. You can save progress at any step and return later. ## Step 1: Select Capabilities In this step, you choose which data quality dimensions to measure. ### Available Capabilities The wizard displays two panels: **Data Quality (Operational Hygiene)** - Completeness - Are fields populated? - Validity - Do values match expected formats? - Uniqueness - Are records distinct? - Timeliness - Is data current? - Consistency - Are values uniform? **AI Readiness (Agentforce Prep)** - PII Detection - Is sensitive data protected before AI exposure? ### Selecting Capabilities 1. Click a capability card to select it 2. The card highlights and a checkmark appears 3. Select multiple capabilities for a comprehensive analysis 4. Click again to deselect > **Tip:** Start with 2-3 capabilities for your first Definition. You can add more later. ### Best Practice: Start Focused Select capabilities based on your immediate goal: | Goal | Recommended Capabilities | |------|--------------------------| | Improve data entry quality | Completeness, Validity | | Find duplicates | Uniqueness | | Clean stale records | Timeliness | | Prepare for AI/Agentforce | All AI Readiness | | Full data audit | All capabilities | Click **Continue** when you've selected your capabilities. ## Step 2: Define Scope In this step, you choose which Salesforce object and fields to analyze. ### Selecting an Object 1. Use the object picker dropdown 2. Search by object name or API name 3. Click to select the object DQS supports standard and custom objects. The wizard displays the object label and API name to help you select the correct one. > **Tip:** Start with a high-value object like Contact, Lead, or Account. These typically have the most data quality impact. ### Selecting Fields After choosing an object, the wizard displays available fields. 1. Fields are grouped by type (text, number, date, etc.) 2. Click a field row to select it 3. Use the search box to find specific fields 4. Select multiple fields for analysis The wizard shows which capabilities apply to each field based on field type: | Capability | Compatible Field Types | |------------|------------------------| | Completeness | Most types (text, number, date, picklist, etc.) | | Validity | Text, email, phone, URL, picklist | | Uniqueness | All types | | Timeliness | Date, DateTime only | | Consistency | Text, picklist, email | ### Per-Field Configuration You can set different thresholds for individual fields. This is useful when: - Critical fields need stricter thresholds - Some fields have unique format requirements - Different fields have different freshness expectations Click the gear icon next to a field to access per-field settings. Click **Continue** when you've selected your fields. ## Step 3: Add Filters (Optional) Filters narrow which records DQS analyzes. This step is optional but useful for large datasets or specific use cases. ### When to Use Filters | Scenario | Filter Example | |----------|----------------| | Analyze only active accounts | Status = 'Active' | | Focus on recent records | CreatedDate = LAST_90_DAYS | | Exclude test data | Name does not contain 'Test' | | Target specific regions | BillingCountry = 'United States' | ### Building a Filter 1. Click **Add Condition** 2. Select a field from the dropdown 3. Choose an operator (equals, contains, greater than, etc.) 4. Enter a value 5. Repeat for additional conditions ### Filter Logic Use AND/OR logic to combine conditions: - **AND** - All conditions must be true - **OR** - Any condition can be true Example: `(Status = 'Active') AND (Industry = 'Technology' OR Industry = 'Finance')` ### Record Count Preview The wizard shows how many records match your filter. Use this to verify your filter works as expected. - A count of 0 means no records match (check your filter) - A very high count may need more filtering for large orgs > **Tip:** Skip filters for your first Definition to get a full picture. Add filters later for targeted analysis. Click **Continue** to proceed (or skip this step). ## Step 4: Configure In this step, you set thresholds and options for each selected capability. ### Global vs Per-Field Settings Settings apply at two levels: 1. **Global** - Default settings for all fields 2. **Per-Field** - Override settings for specific fields Configure global settings first, then customize individual fields if needed. ### Completeness Configuration | Option | Description | Default | |--------|-------------|---------| | Treat blanks as incomplete | Count whitespace-only values as missing | Yes | | Treat placeholders as incomplete | Count N/A, TBD, Unknown as missing | Yes | | Custom placeholder values | Add your own placeholder patterns | None | | Threshold | Minimum acceptable completeness % | 95% | **Example settings for Contact:** - Threshold: 90% for optional fields - Threshold: 99% for required fields like Email - Placeholders: N/A, TBD, Unknown, -, . ### Validity Configuration | Option | Description | Default | |--------|-------------|---------| | Pattern type | Email, URL, Fixed Length, Custom Regex | Email | | Custom regex | Your own validation pattern | None | | Case sensitive | Match exact case | No | | Include blank values | Count blanks as invalid | No | **Built-in patterns:** - **Email** - RFC 5322 compliant format - **URL** - HTTP/HTTPS format - **Fixed Length** - Exact character count ### Uniqueness Configuration | Option | Description | Default | |--------|-------------|---------| | Case sensitive | Treat "ABC" and "abc" as different | No | | Threshold | Minimum acceptable uniqueness % | 95% | ### Timeliness Configuration | Option | Description | Default | |--------|-------------|---------| | Freshness window (days) | Days before data is considered stale | 90 | | Grace period (days) | Buffer before flagging as stale | 7 | | Operational range | Min/max expected date boundaries | None | **Example settings by field:** - LastModifiedDate: 30-day freshness window - LastActivityDate: 90-day window - BirthDate: No freshness check needed ### Consistency Configuration | Option | Description | Default | |--------|-------------|---------| | Expected values | List of valid values | None | | Import from picklist | Auto-populate from field's picklist | No | | Case sensitive | Match exact case | No | | Top N dominant values | Show most frequent values | 5 | ### PII Detection Configuration | Option | Description | Default | |--------|-------------|---------| | Pattern type | Which PII patterns to scan for | All patterns | | Custom patterns | Add your own regex patterns for org-specific sensitive data | None | ### Processing Cost Indicator Each capability shows a processing cost: | Cost | Capabilities | Impact | |------|--------------|--------| | LOW | Completeness, Validity | Fast, minimal resources | | MEDIUM | Timeliness, Consistency, PII Detection | Moderate processing time | | HIGH | Uniqueness | Longer processing, more comparisons | Consider cost when selecting capabilities for large datasets. Click **Continue** when configuration is complete. ## Step 5: Review The final step shows a summary of your Definition. ### Review Checklist Verify the following before activating: 1. **Object** - Correct object selected 2. **Fields** - All important fields included 3. **Capabilities** - Appropriate checks selected 4. **Filters** - Record count looks right 5. **Thresholds** - Settings match your requirements ### Definition Summary The summary displays: - Definition name (editable) - Target object and record count - Selected capabilities with variants - Field count by capability - Estimated processing cost ### Naming Your Definition Use descriptive names that indicate: - Object being analyzed - Purpose or scope - Owner (optional) **Good names:** - "Contact Data Quality - Sales Team" - "Lead AI Readiness Check" - "Account Completeness - EMEA Region" **Poor names:** - "Definition 1" - "Test" - "My Definition" ### Saving and Activating You have two options: 1. **Save as Draft** - Save without activating (editable later) 2. **Activate** - Save and make ready for scanning Draft Definitions can be edited. Active Definitions are locked but ready to run. ## Example: Building a Contact Definition Let's walk through creating a Contact Data Quality Definition. ### Step 1: Select Capabilities Select: - Completeness (check for missing data) - Validity (verify email and phone formats) - Timeliness (find stale contact records) ### Step 2: Define Scope Object: Contact Fields: - Email (text, email) - Phone (phone) - MailingCity (text) - MailingState (text) - MailingCountry (text) - Title (text) - LastActivityDate (date) ### Step 3: Add Filters Condition: `AccountId != null` (Contacts with Accounts only) Record count preview: 15,234 records ### Step 4: Configure **Completeness:** - Threshold: 90% - Treat blanks as incomplete: Yes - Placeholders: N/A, Unknown, TBD **Validity:** - Email field: Email pattern - Phone field: Phone pattern (if available) **Timeliness:** - LastActivityDate: 60-day freshness window - Grace period: 14 days ### Step 5: Review Name: "Contact Data Quality - Active Accounts" Summary: - 7 fields - 3 capabilities - 15,234 records - Estimated cost: LOW Click **Activate** to complete. ## Managing Definitions ### Viewing All Definitions From the DQS home screen, you see: - All your Definitions - Status (Draft, Active, Archived) - Last scan date - Quick actions ### Editing Definitions - **Draft** - Fully editable - **Active** - Create a new version to edit - **Archived** - View-only ### Archiving Definitions Archive Definitions you no longer need: 1. Click the dropdown menu 2. Select **Archive** 3. Confirm Archived Definitions remain viewable but cannot run. ## Troubleshooting ### "No fields available" **Cause:** Selected capabilities don't match available field types. **Solution:** Select different capabilities or choose an object with compatible field types. ### "0 records match filter" **Cause:** Filter conditions are too restrictive. **Solution:** Adjust filter values or remove conditions. ## Next Steps - [Running Scans](/resources/using-dqs/running-scans/): Execute your Definition - [Understanding Results](/resources/using-dqs/understanding-results/): Interpret scan outputs # Data Quality KPIs and Metrics > A catalog of 18 data quality KPIs with formulas, example targets, worked calculations, and a weighted scorecard template you can copy. Source: https://dataqualitysense.com/resources/best-practices/data-quality-kpis/ Last updated: 2026-07-15 --- > **TL;DR:** A data quality KPI is a single measurable indicator, such as fill rate or duplicate count, that you track against a target over time. This guide catalogs 18 KPIs across completeness, validity, uniqueness, timeliness, consistency, and AI readiness, each with a formula and an example target. It then shows how to roll them into a weighted scorecard using the same formula DQS applies inside Salesforce. ## What Is a Data Quality KPI? A **data quality KPI** is a single, measurable indicator that tracks one aspect of how fit your data is for use. Each KPI produces one number, usually a rate or a count, that you compare against a target and watch over time. A KPI is not the same as a **data quality score**. A KPI measures one thing: the phone fill rate, the email validity rate, the duplicate count. A [data quality score](/resources/data-quality/what-is-a-data-quality-score/) is a weighted composite that rolls many KPIs across several dimensions into one 0-100 number. The KPI tells you where the problem is. The score tells you the overall health. Use both. Executives read the score. Data stewards act on the individual KPIs behind it. Tracking KPIs is also how you put a price on the problem. [Gartner estimates](https://www.gartner.com/en/data-analytics/topics/data-quality) poor data quality costs organizations an average of $12.9 million per year, and in [Salesforce's State of Data and Analytics research](https://www.salesforce.com/news/stories/data-analytics-trends/) data leaders rated 26% of their own data as untrustworthy. A KPI baseline turns those industry averages into your org's actual numbers. ## The Data Quality KPI Catalog The KPIs below are organized by dimension. Each one maps to a metric you can compute directly, and each includes a formula and an example target. Set your own targets from the cost of being wrong: a field that feeds billing needs a higher bar than one used for occasional lookups. For the concepts behind each dimension, see [The Five Dimensions](/resources/data-quality/five-dimensions/). ### Completeness KPIs Completeness measures whether required data is present, counting NULL, blank, empty, and placeholder values as missing. | KPI | Formula | Example Target | |-----|---------|----------------| | **Fill Rate** | Populated records / Total records | 95%+ for critical fields | | Null Rate | Null or blank records / Total records | Below 5% | | Placeholder Rate | Placeholder values / Total records | Below 2% | **Worked example:** You have 10,000 Contact records. 8,700 have the `Phone` field populated. The phone fill rate is 8,700 / 10,000 = **87%**. Against a 95% target, that is 800 records short. ### Validity KPIs Validity measures whether populated values match the expected format for their field type, such as email, phone, or URL. Validity depends on completeness: only populated values are checked. | KPI | Formula | Example Target | |-----|---------|----------------| | **Format Validity Rate** | Correctly formatted values / Populated values | 98%+ for email, 90%+ for phone | | Invalid Count | Populated values failing format checks | Trend toward zero | | URL Validity Rate | Valid URLs / Populated URL values | 95%+ | **Worked example:** Of the 8,700 populated phone numbers, 7,830 match a valid phone format. The format validity rate is 7,830 / 8,700 = **90%**. The other 870 are populated but malformed. ### Uniqueness KPIs Uniqueness measures whether the same real-world entity appears more than once. DQS reports uniqueness rate, distinct count, and duplicate count. | KPI | Formula | Example Target | |-----|---------|----------------| | **Uniqueness Rate** | Distinct values / Total populated values | 95%+ for identifier fields | | Duplicate Count | Records sharing a value with another record | Trend toward zero | | Distinct Count | Number of unique values | Context-dependent | **Worked example:** Across 10,000 Contacts, 350 records share an email address with at least one other record. The uniqueness rate is 9,650 / 10,000 = **96.5%**, and the duplicate count is **350**. DQS flags these records so you can review them. It does not merge them for you; remediation stays under human control. ### Timeliness KPIs Timeliness, presented in DQS as **Data Freshness**, measures record age against a date field and a threshold you configure. | KPI | Formula | Example Target | |-----|---------|----------------| | **Freshness Rate** | Records updated within threshold / Total records | 80%+ | | Stale Record Count | Records exceeding the freshness threshold | Trend toward zero | | Average Record Age | Mean days since the tracked date field | Varies by object | **Worked example:** You set a 180-day freshness threshold on Accounts. Of 10,000 Accounts, 7,200 were updated within 180 days. The freshness rate is 7,200 / 10,000 = **72%**, and 2,800 records are stale. ### Consistency KPIs Consistency, checked in DQS as a **Conformance Check**, measures whether values match the dominant or expected standard for a field. | KPI | Formula | Example Target | |-----|---------|----------------| | **Conformance Rate** | Records matching the standard / Total records | 90%+ | | Variant Count | Number of distinct value variations | Minimize | | Dominant Value Coverage | Most frequent value / Total records | Context-dependent | **Worked example:** Your `Country` field stores "United States" as the standard, but variants like "US", "USA", and "U.S." exist. 9,400 of 10,000 records use the standard. The conformance rate is **94%**, with 600 records to normalize. ### AI Readiness KPIs AI readiness KPIs measure whether text data is safe and dense enough to ground an assistant like Agentforce. DQS computes PII detection counts, content density, and language consistency. | KPI | Formula | Example Target | |-----|---------|----------------| | **PII Exposure Count** | Records with detected SSN, card, email, or phone in text | Zero in fields used for AI grounding | | Content Density | Average token count per text field | Above your model's minimum useful length | | Language Consistency Rate | Single-language records / Total text records | 95%+ for a single-language corpus | **Worked example:** DQS scans the `Description` field on 10,000 Cases and detects unredacted SSN or credit-card patterns in 128 of them. The PII exposure count is **128**. Those 128 records are candidates to redact before you expose the field to an AI model. In CSV exports, DQS masks the detected values as `[REDACTED]` so the report itself does not leak PII. ## Leading vs Lagging Indicators Data quality KPIs are **leading indicators**. They move before the outcomes they predict. - A falling email validity rate is a leading indicator of a lagging outcome: campaign bounce rates and lost reach. - A rising duplicate count is a leading indicator of inflated pipeline reports and double-counted revenue. - A low PII exposure count and high content density are leading indicators of an AI assistant that answers safely and accurately. Lagging indicators, such as bounce rate, forecast error, or a failed AI response, tell you the damage is already done. Track the KPI so you can act before the lagging metric moves. ## Building a KPI Scorecard A scorecard collects your headline KPIs into one view and rolls them into a single score. Keep it to one or two KPIs per dimension so it stays readable. ### Example Scorecard | Dimension | Headline KPI | Current | Target | Trend | |-----------|--------------|---------|--------|-------| | Completeness | Fill Rate | 87% | 95% | Up | | Validity | Format Validity Rate | 91% | 98% | Flat | | Uniqueness | Uniqueness Rate | 96% | 98% | Up | | Timeliness | Freshness Rate | 72% | 80% | Down | | Consistency | Conformance Rate | 84% | 90% | Flat | | AI Content | Language Consistency Rate | 80% | 95% | Up | | PII Safety | PII Exposure (inverse) | 95% | 100% | Flat | ### Rolling KPIs Into One Score DQS combines dimension scores with a weighted average. The formula is: **Overall Score = SUM(dimension score × weight) / SUM(weight)** The default weights reflect how much each dimension affects reporting and AI outcomes. Adjust them to match your own business priorities. | Dimension | Score | Weight | Weighted (Score × Weight) | |-----------|-------|--------|---------------------------| | Completeness | 87 | 25 | 2,175 | | Validity | 91 | 20 | 1,820 | | Uniqueness | 96 | 15 | 1,440 | | Timeliness | 72 | 15 | 1,080 | | Consistency | 84 | 15 | 1,260 | | AI Content | 80 | 10 | 800 | | PII Detection | 95 | 10 | 950 | | **Total** | | **110** | **9,525** | The overall score is 9,525 / 110 = **86.6 out of 100**. Two details matter in that calculation. First, the denominator is the sum of the weights of the dimensions you actually scanned, not a fixed 100. If you skip the AI Content and PII dimensions, the denominator drops to 90 and the score reflects only the operational dimensions. Unscanned dimensions are excluded, so they never drag the score down. Second, the weights encode what "good" means for you. If AI readiness is a priority, raise the weight on PII and content density. ## Common Mistakes Avoid the failures that make a KPI program stall: - **Too many KPIs.** A scorecard with 30 metrics gets ignored. Track one or two per dimension at the executive level and keep the detail in steward reports. - **KPIs with no target.** A number without a target is trivia. Every KPI needs a target and an owner. - **Measuring once.** A single scan is a snapshot. The value is in the trend, so schedule re-measurement and compare periods. - **Treating empty datasets as perfect.** An unscanned or empty field is not 100% complete. DQS deliberately scores a dimension with no data to measure as 0, not 100, so gaps stay visible instead of inflating your score. ## Tracking KPIs in Salesforce These KPIs map directly onto how DQS works inside Salesforce. DQS scans any SObject, including Accounts, Contacts, Leads, and custom objects, with field selection and scope filters. It computes fill rate, format validity rate, uniqueness rate, freshness rate, conformance rate, and PII detection counts per field, then rolls them into a weighted score. Scheduled scans keep the numbers current, score trend charts show whether each KPI is improving, scan comparison surfaces the delta between two periods, and CSV export moves the results into your BI tool for reporting. Uniqueness violations are the one exception: they are not exported to CSV. Ready to see your own KPIs? Take the [AI Readiness Assessment](/ai-readiness/) to get your baseline scores in a few minutes, or [contact us](/contact/) to walk through the scorecard on your data. ## Frequently Asked Questions ### What are data quality KPIs? Data quality KPIs are single, measurable indicators that track one aspect of how fit your data is for use. Each KPI is a rate or a count, such as fill rate, format validity rate, or duplicate count. You measure each one repeatedly against a target so you can see whether your data is improving or slipping. ### What is an example of a data quality KPI? Fill rate is the most common example. If 8,700 of 10,000 Contact records have a phone number, the phone fill rate is 87%. Other examples include validity rate, uniqueness rate, freshness rate, and PII exposure count. ### How many KPIs should a scorecard have? Track one or two headline KPIs per dimension, which gives you five to eight metrics for a typical operational scorecard. Fewer KPIs keep the scorecard readable and make trends easy to communicate. Add detailed field-level KPIs only in the working reports your data stewards use. ### What is the difference between a data quality KPI and a data quality score? A data quality KPI is a single measurable indicator, such as an 87% fill rate for one field. A data quality score is a weighted composite that rolls many KPIs across several dimensions into one 0-100 number. KPIs tell you where the problem is; the score tells you the overall health. ## Next Steps - [Measuring Data Quality](/resources/best-practices/measuring-data-quality/): build the measurement program, cadence, and ROI case around these KPIs - [What Is a Data Quality Score?](/resources/data-quality/what-is-a-data-quality-score/): how the weighted composite behind your scorecard is calculated - [The Five Dimensions](/resources/data-quality/five-dimensions/): the concepts each KPI measures - [Salesforce Data Quality Dashboard](/resources/salesforce/salesforce-data-quality-dashboard/): the metrics worth watching alongside the headline score # Data Quality Examples > Real CRM examples of good vs bad data across completeness, validity, uniqueness, timeliness, consistency, and AI readiness in Salesforce. Source: https://dataqualitysense.com/resources/data-quality/data-quality-examples/ Last updated: 2026-07-15 --- > **TL;DR:** This page shows good vs bad data examples for each of the five dimensions of data quality, completeness, validity, uniqueness, timeliness, and consistency, plus AI readiness, using realistic Salesforce field values. Each bad example carries a business cost: missed calls, bounced campaigns, double-counted pipeline, or a wrong AI answer. Every example maps to a rate you can measure and track. ## Why Data Quality Examples Beat Definitions You already know what "complete" and "valid" mean. What is harder is spotting the moment your own data stops being either. Examples fix that. When you see a blank phone field next to a filled one, or "USA" sitting beside "United States", you recognize your own org in the picture. The odds say the picture applies to you. In [Experian's data quality benchmark research](https://www.experian.com/blogs/news/2015/01/29/data-quality-research-study/), US organizations estimated that 32% of their data is inaccurate in some way, and 91% of respondents said inaccurate data affects revenue through wasted resources, lost productivity, or wasted marketing spend. Every example below is one of the small failures those percentages are made of. This page pairs a good example with a bad one for each dimension, using field values you would actually find on a Contact, Account, or Case. For the concepts behind each dimension, read [The Five Dimensions of Data Quality](/resources/data-quality/five-dimensions/). This article stays on the concrete: what good and bad data look like, and what the bad version costs you. ## Completeness: Present vs Missing Completeness measures whether a value is there at all. DQS counts NULL, blank, empty, and placeholder junk as missing. A field that reads "N/A" or "test" is not populated in any useful sense, even though it is technically not empty. | Contact field | Good data | Bad data | |---------------|-----------|----------| | Phone | +1 415 555 0100 | *(blank)* | | Email | anna.kim@acme.com | N/A | | Title | VP Marketing | - | | Description | Renewal owner, prefers email | test | The bad column looks filled at a glance, but none of it works. A blank phone means the record cannot be called. A Title of "-" cannot segment a campaign or route a lead. Placeholder values are worse than blanks because they hide the gap: a report counts the field as populated, so the problem never surfaces until an automation fails. ## Validity: Correct Format vs Malformed Validity checks whether a populated value matches its expected format. Validity requires completeness, so DQS checks format only on values that are actually there. A blank email is a completeness problem, not a validity one. | Field | Good data | Bad data | |-------|-----------|----------| | Email | anna.kim@acme.com | anna.kim@acme | | Phone | +1 415 555 0100 | call reception | | Website | https://acme.com | acme | An email with no domain fails at the mail server, so every campaign send to it bounces and drags down your sender reputation. "call reception" in a Phone field passes a not-blank test but breaks any dialer, SMS tool, or telephony integration that expects digits. Format errors are quiet: the record exists, the field is full, and nothing complains until the message fails to send. ## Uniqueness: One Record vs Duplicates Uniqueness measures whether each real-world entity appears once. The classic failure is the same person entered several times with slight variations, so no single record holds the full history. | Contact | Email | Same person? | |---------|-------|--------------| | Anna Kim | anna.kim@acme.com | Yes | | Anna Kim | a.kim@acme.com | Yes | | Anna M. Kim | anna.kim@acme.com | Yes | Three records, one person. DQS reports this as a distinct count and a duplicate count: three total records collapse to one distinct individual, so the duplicate count is two. Duplicates inflate reporting, so a pipeline of "3 contacts engaged" is really one. They also fragment history, so the note logged on record one is invisible when a colleague opens record two, and two reps email the same person the same week. ## Timeliness: Current vs Stale Timeliness, shown in DQS as **Data Freshness**, measures whether a record is recent enough to trust. You set a freshness threshold, and records older than it count as stale. | Account | Last Modified | Against a 90-day threshold | |---------|---------------|----------------------------| | Acme Corp | 30 days ago | Fresh | | Globex Inc | 4 years ago | Stale | The 4-year-old account is a forecasting risk. Its Annual Revenue, owner, and contact roles reflect a company that has since moved, restructured, or churned. A pipeline built on stale accounts forecasts a customer base that no longer exists. Freshness thresholds differ by data type: a cold lead loses value in weeks, while an annual revenue figure is fine for a year. The point is to measure age against a threshold you choose, not to treat all data as timeless. ## Consistency: Standard vs Variant Consistency measures whether the same meaning is stored the same way. Free-text and loose picklists let one value drift into many spellings. | Country field | Records | Conforms to "United States"? | |---------------|---------|------------------------------| | United States | Standard value | Yes | | US | Variant | No | | USA | Variant | No | | U.S. | Variant | No | DQS finds the dominant value, here "United States", and reports a conformance rate: the share of records that match it. Four spellings of one country break every report that groups or filters by Country. A regional dashboard shows four segments where there should be one, and a filter for "United States" silently drops every record stored as "US" or "USA". The data is present and readable to a human, but a machine treats each variant as a separate value. ## AI Readiness: Grounded vs Risky Text Beyond the five dimensions, DQS adds AI readiness checks for text you plan to feed a model like Agentforce. Free-text fields carry risks that never matter for a report but break AI grounding. | Check | Good data | Bad data | |-------|-----------|----------| | PII safety | "Customer disputes the March invoice." | "SSN 000-00-0000, card on file." | | Content density | "Customer reports the renewal quote is missing the agreed 12% discount and wants a corrected PDF before Friday." | "call back" | | Language quality | "Customer requests a refund for the duplicate charge." | "Klient prosi o refund for the duplicate charge." | The PII example, using an obviously fake number, is a safety failure: sensitive values in a Case Description can surface in an AI response or a vector index. DQS detects SSN, credit card, email, and phone patterns in text fields and reports the count. A 3-word description like "call back" is too thin to ground an answer, so DQS measures content density by token count. Mixed Polish and English in one field confuses language models, so DQS flags mixed-language content that hurts model performance. ## From Examples to Measurement Every example above maps to a number you can put on a dashboard. That is what turns "our data feels messy" into a target you can move. | Example | Measured as | |---------|-------------| | Blank or "N/A" phone | Fill rate (completeness) | | "anna.kim@acme" | Validity rate | | Three records, one person | Uniqueness rate, distinct and duplicate count | | Account untouched for 4 years | Freshness rate | | "US" vs "United States" | Conformance rate | | Fake SSN in a Case Description | PII count | For how to turn these into an ongoing measurement practice, see [How to Measure Data Quality](/resources/best-practices/measuring-data-quality/). For the specific metrics worth tracking, the KPI catalog lives at [Data Quality KPIs](/resources/best-practices/data-quality-kpis/). ## Finding These Examples in Your Own Org DQS scans any SObject in your Salesforce org, so you can point it at Contact, Account, Case, or a custom object. You select the fields, set thresholds, and run a scan either manually or on a schedule. Batch scans process your records in chunks and report results by dimension and by field. When a record fails a check, DQS flags the exact record, so you are not left guessing which rows are the problem. You can export the failing records to CSV for every dimension except Uniqueness. In exports, detected PII values are shown as `[REDACTED]` so you do not copy sensitive data out of the platform. To act on impacted records, you can create Tasks or post Chatter messages on them directly from the results view. DQS detects and reports these examples. It does not auto-fix, cleanse, or merge records. Remediation stays with your team, guided by the exact records DQS surfaces. ## See Where Your Data Stands To find your own good and bad data examples, take the [AI Readiness Assessment](/ai-readiness/) for a scored view of where your data stands. To discuss measuring quality across your objects, [contact us](/contact/). ## Frequently Asked Questions ### What are examples of data quality issues? Common data quality issues include missing values like a blank Contact Phone or a placeholder such as "N/A", invalid formats like "anna.kim@acme" with no domain, duplicate records for the same person, stale accounts untouched for years, and inconsistent values like "US", "USA", and "United States" in one Country field. Each issue maps to a measurable rate you can track over time. ### What is an example of good data quality? Good data quality looks like a Contact record with a populated Title, a phone in a single format such as "+1 415 555 0100", and a valid email like "anna.kim@acme.com". There is one record per real person, the account was updated recently, and the Country field always reads "United States". Good data is complete, correctly formatted, distinct, current, and consistent. ### What are the five dimensions of data quality with examples? The five dimensions are completeness (a filled vs blank Email), validity (a correct vs malformed email format), uniqueness (one record vs three duplicates for the same person), timeliness (an account updated last week vs four years ago), and consistency (Country stored as "United States" vs mixed "US" and "USA" variants). DQS measures all five inside Salesforce and adds AI readiness checks. ### How do you identify data quality issues in Salesforce? You identify data quality issues in Salesforce by scanning your objects against defined rules and reviewing the results by dimension and field. DQS runs batch scans on any SObject, reports fill rate, validity rate, uniqueness rate, freshness rate, and conformance rate, and flags the exact records that fail. You can export the failing records to CSV or create Tasks on them for follow-up. ## Next Steps - Understand the concepts: [The Five Dimensions of Data Quality](/resources/data-quality/five-dimensions/) - Track the metrics: [Data Quality KPIs](/resources/best-practices/data-quality-kpis/) - See it in your CRM: [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/) - Go deeper on one dimension: [Completeness Scenarios](/resources/use-cases/completeness-scenarios/) # Building a Data Quality Culture > Drive adoption and sustainability through change management, training, and organizational alignment. Source: https://dataqualitysense.com/resources/best-practices/building-data-quality-culture/ Last updated: 2026-02-04 --- ## What You'll Learn This guide covers how to build organizational commitment to data quality beyond technology implementation. You will understand: - Why technology alone fails to deliver lasting improvement - Strategies for stakeholder engagement - Training and onboarding approaches - Incentives and accountability mechanisms - Quick wins that build momentum - How to sustain quality culture long-term ## Why Technology Alone Fails Implementing a data quality tool without addressing culture produces temporary results at best. [The failure rate persists because organizations focus on technology deployment rather than addressing fundamental issues](https://www.integrate.io/blog/data-transformation-challenge-statistics/). Cultural resistance represents the dominant barrier, while companies allocate only 10% of transformation budgets to change management. The pattern is predictable: 1. Organization buys tool 2. IT implements tool 3. Initial scans reveal problems 4. No one acts on results 5. Tool sits unused 6. Quality remains poor Breaking this pattern requires treating data quality as an organizational change initiative, not a technology project. ### The Culture Gap [Organizations making the most progress treat data quality as a shared responsibility](https://www.alation.com/blog/data-management-trends/) rather than an IT function. They invest in data literacy, communicate quality expectations consistently, and embed quality checks into workflows. | Technology-Only Approach | Culture-Focused Approach | |--------------------------|--------------------------| | "We have a data quality tool" | "We value data quality" | | IT owns quality | Everyone owns quality | | Quarterly cleanup projects | Quality built into daily work | | Metrics reported | Metrics acted upon | ## Stakeholder Engagement Strategies Success requires buy-in from multiple levels. ### Executive Sponsorship [In 2025, 40% of CIOs prioritize fostering a data-driven culture](https://www.ibsolution.com/academy/blog_en/data-and-analytics/five-key-trends-for-data-driven-companies-in-2026). Such an environment requires an entrepreneurial mindset with strong stakeholder management and communication strategy. Engage executives by: 1. **Connecting to business outcomes**: "Our 12% email bounce rate costs us $50K monthly in wasted marketing spend" 2. **Showing competitive risk**: "Competitors with better data make faster, more accurate decisions" 3. **Highlighting AI readiness**: "Poor data will limit our Agentforce success" | Executive Concern | Data Quality Connection | |-------------------|-------------------------| | Revenue growth | Clean customer data drives sales effectiveness | | Cost reduction | Eliminating duplicates reduces storage and labor | | Risk management | Quality data ensures compliance | | AI adoption | High-quality data is prerequisite for AI success | ### Middle Management Managers control whether their teams prioritize quality. Engage them by: - Including quality metrics in team goals - Providing time allocation for quality activities - Recognizing quality improvements in performance reviews - Sharing success stories from peer organizations ### Front-line Users People who create and use data daily determine actual quality. Engage them by: - Explaining why quality matters for their work - Making quality requirements clear and achievable - Removing friction from data entry processes - Providing immediate feedback on data issues > **Tip:** Lead with "how does bad data affect your job?" rather than "you need to enter better data." ## Training and Onboarding Build capability through structured learning. ### Training Components | Component | Audience | Format | |-----------|----------|--------| | **Awareness** | All employees | 30-minute overview | | **Role-specific** | Data entry staff | Hands-on workshop | | **Steward training** | Data Stewards | Multi-session program | | **Tool training** | DQS users | Guided walkthrough | ### Awareness Training Content Cover fundamentals for all employees: 1. What is data quality and why it matters 2. How bad data affects the organization 3. Individual responsibility for data quality 4. How to report data issues 5. Where to get help ### Role-Specific Training Customize for different roles: | Role | Training Focus | |------|----------------| | Sales reps | Contact and Account data entry standards | | Service agents | Case documentation quality | | Marketing | Lead data requirements | | Finance | Accuracy requirements for financial data | ### Onboarding Integration Include data quality in new employee onboarding: 1. Add data quality module to orientation 2. Assign quality mentor for first 30 days 3. Review data entry expectations in role training 4. Test understanding before granting data access ## Incentives and Accountability Behavior follows consequences. Align incentives with quality goals. ### Positive Incentives | Incentive Type | Example | |----------------|---------| | Recognition | "Data Champion" awards | | Gamification | Team quality leaderboards | | Career development | Quality expertise as growth opportunity | | Tangible rewards | Gift cards for hitting quality targets | ### Accountability Mechanisms | Mechanism | Application | |-----------|-------------| | Quality metrics in goals | Include in performance reviews | | Team dashboards | Make quality visible at team level | | Escalation paths | Clear process when quality fails | | Consequence for negligence | Address repeated quality failures | ### Balancing Carrot and Stick Focus on positive reinforcement initially: 1. Start with recognition and rewards 2. Make success visible and celebrated 3. Address persistent issues privately 4. Reserve consequences for negligent behavior > **Tip:** Punishing data entry errors creates fear and hiding. Focus on fixing processes, not blaming people. ## Quick Wins to Build Momentum Early success builds credibility. Target improvements that are: - Visible to stakeholders - Achievable within 30-60 days - Measurable with clear before/after - Valuable to the business ### Quick Win Examples | Quick Win | Timeline | Impact | |-----------|----------|--------| | Clean up duplicate Accounts | 2-4 weeks | Immediate storage savings | | Validate email addresses | 1-2 weeks | Better email deliverability | | Standardize state/country values | 1 week | Consistent reporting | | Fill missing required fields | 2-3 weeks | Process automation enabled | ### Quick Win Process 1. **Identify**: Run DQS scan to find low-hanging fruit 2. **Quantify**: Calculate impact of improvement 3. **Fix**: Execute targeted cleanup 4. **Measure**: Run follow-up scan to prove improvement 5. **Communicate**: Share results broadly ### Sample Communication ``` Subject: Data Quality Win - Email Validation Team, Last month, 15% of our customer emails were invalid, causing marketing campaigns to bounce and sales outreach to fail. We ran a targeted cleanup and: - Corrected 2,340 invalid email formats - Identified 890 bounced addresses for verification - Improved email validity from 85% to 97% Result: Our last campaign had 12% higher delivery rate. Thank you to the Sales team for prioritizing data verification! ``` ## Long-Term Sustainability Culture change takes years, not months. Plan for sustained effort. ### Sustainability Factors | Factor | Why It Matters | |--------|----------------| | Executive continuity | Sponsor turnover can kill initiatives | | Budget protection | Quality requires ongoing investment | | Process integration | Quality becomes "how we work" | | Measurement persistence | What gets measured gets managed | ### Embedding Quality in Processes Move from periodic cleanup to continuous quality: 1. **Data entry validation**: Prevent bad data at creation 2. **Workflow integration**: Quality checks in business processes 3. **Automated monitoring**: DQS scans on schedule 4. **Review gates**: Quality approval before data use ### Succession Planning Protect against knowledge loss: - Document all processes and policies - Cross-train multiple people on DQS - Include quality responsibilities in job descriptions - Build quality into organizational structure, not individual heroics ### Annual Review Conduct yearly assessment: 1. Review quality metrics trend over 12 months 2. Evaluate governance effectiveness 3. Update policies based on lessons learned 4. Set new improvement targets 5. Recognize contributions and achievements ## Common Culture Challenges Anticipate and address predictable obstacles. ### "We Don't Have Time" Response: Calculate time spent on bad data problems. Quality investment saves time overall. ### "That's IT's Job" Response: IT manages systems. Business owns data. Quality requires partnership. ### "Our Data Is Fine" Response: Let's measure and find out. DQS provides objective assessment. ### "We Tried This Before" Response: What was different? This time includes governance, measurement, and accountability. ### "Too Many Priorities" Response: Poor data quality impacts every other priority. It's foundational, not additional. ## Getting Started Build culture incrementally: ### Month 1: Foundation 1. Secure executive sponsor 2. Identify pilot team 3. Run baseline DQS scan 4. Communicate importance ### Month 2-3: Quick Wins 1. Execute 2-3 quick win improvements 2. Measure and communicate results 3. Begin awareness training 4. Establish recognition program ### Month 4-6: Expansion 1. Expand to additional teams 2. Implement role-specific training 3. Add quality to performance goals 4. Establish regular reporting cadence ### Month 7-12: Institutionalization 1. Integrate quality into standard processes 2. Automate ongoing measurement 3. Review and adjust governance 4. Plan for long-term sustainability ## Next Steps - [Data Governance Framework](/resources/best-practices/data-governance-framework/): Establish structure that supports culture - [Common Data Quality Pitfalls](/resources/best-practices/common-pitfalls/): Avoid mistakes that undermine culture - [Why Data Quality Matters](/resources/getting-started/why-data-quality-matters/): Build the business case for change # Completeness > All 10 completeness metrics DQS measures, the diagnostic funnel for finding missing data, and how to configure completeness analysis. Source: https://dataqualitysense.com/resources/data-quality/completeness/ Last updated: 2026-02-23 --- ## What is Completeness? Completeness measures whether your data is actually there. A field is complete when it contains meaningful data. A field is incomplete when it is null, blank, or filled with a placeholder like "N/A" or "TBD." Completeness is the most fundamental data quality dimension. Without data, you have nothing to validate, deduplicate, or analyze. ``` Completeness Rate = (Records with Data / Total Records) x 100 ``` If 850 of 1,000 Contact records have an Email value, your Email completeness rate is 85%. This metric (sometimes called fill rate) is the headline number for any field. ## Why Completeness Matters ### Reporting Incomplete data skews your analytics. When 40% of Account records lack an Industry value, any report grouped by Industry shows only partial truth. Dashboards become unreliable. Executive decisions rest on a fraction of the picture. ### Automation Salesforce automation depends on field values. A workflow that sends emails fails when Email is blank. A process that updates Account Owner fails when the lookup is null. Each missing value is a potential automation failure. ### AI and Agentforce AI models learn from your data. When fields are empty, the model has nothing to learn from. Agentforce uses your Salesforce data to generate responses and take action. Missing data means incomplete context and less useful AI outputs. | System | Completeness Impact | |--------|---------------------| | Reports | Partial data produces skewed metrics | | Workflows | Missing values cause process failures | | Duplicate Rules | Incomplete records are harder to match | | Agentforce | Gaps in context reduce AI accuracy | ## How DQS Measures Completeness DQS produces 10 completeness metrics organized around a diagnostic question: **"Where is the data missing, why, and is the data that exists actually useful?"** Think of these metrics as a diagnostic funnel. Each step builds on the previous one. ### Step 1: How Complete Is It? **Completeness Rate** is the headline metric. It calculates the percentage of records where the field contains a non-empty, non-null value. This is the number you put on a dashboard. You run a scan on the Account object. The `Industry` field shows a Completeness Rate of 62%. That means 38% of your Accounts have no industry value, which means your segmentation reports, territory rules, and marketing campaigns that filter by industry all work with incomplete data. Every other completeness metric exists to explain *why* this number is not 100%. ### Step 2: What Is the Scale? Rates tell you severity. Counts tell you workload. **Populated Count** answers the scale question: how many records actually have a value. Use it for coverage reporting and to size the gap against your total record count — the difference between your total and the Populated Count is the cleanup backlog. **Example:** Your data steward needs to build a cleanup campaign. With 50,000 Contacts and a Populated Count of 35,800 on `Phone`, she knows 14,200 records need enrichment, can estimate cost with a data vendor, and can set a realistic timeline. ### Step 3: Why Is It Incomplete? Three metrics break down the *cause* of incompleteness. Each points to a different root problem. **Null Count and Null Rate** measure records where the field has a true database null, meaning the field was never populated. In Salesforce, null and empty string are different states. A field that was never touched is null. A field that was explicitly cleared is an empty string. This distinction tells you whether data was never captured or was deliberately removed. **Example:** After a data migration, the `Fax` field on Accounts shows a 45% Null Rate. The fax data was never migrated from the legacy system (null = never existed) rather than being captured and later cleared. A high Null Rate points you at the source system, not at user behavior. **Placeholder Count and Placeholder Rate** measure records containing known placeholder values like "N/A", "TBD", "Unknown", or any custom values you define. These values *look* like data but carry no real information. **Example:** Your global Account data shows 94% Completeness Rate on `Industry`. Looks great on paper. But Placeholder Rate reveals that 18% of those "populated" values are actually "N/A", "Other", or "Unknown." The true completeness is closer to 76%. This is the metric that turns a green dashboard red. ### Step 4: Is the "Complete" Data Useful? The first three steps identify what is missing. Step 4 asks a harder question: is the data that *is* there actually worth having? **Incompleted Count** is the broadest measure of missing data. It combines all forms of incompleteness: nulls, blanks, *and* placeholder values. When placeholder detection is active, Incompleted Count is always greater than or equal to the Null Count alone, because it also captures whitespace-only and placeholder entries. **Example:** Your `Description` field on Opportunities shows a Null Count of 500 but an Incompleted Count of 1,800. The difference? 1,300 records have descriptions like "TBD", "N/A", or "---". Those records are technically filled in but practically useless. Without this metric, you would think you only have 500 records to fix instead of 1,800. **Rich Text Ratio** measures the percentage of text field records that contain substantial content above a character threshold. It separates fields with meaningful prose from fields with a few words. A `Description` field is "populated" whether it contains "Good customer" or a three-paragraph account plan. For AI readiness, the depth of content matters as much as its presence. **Example:** Your company is evaluating an AI tool that summarizes Case descriptions. You scan the `Description` field on Cases: 88% Completeness Rate, but only 31% Rich Text Ratio. Only 31% of case descriptions have enough substance for the AI to work with. The rest are entries like "call back", "see email", or "issue reported." The AI project needs a data enrichment phase before it can deliver value. **Text Field Utilization** measures how much of a text field's available character capacity is used. A Long Text Area with 32,000 character capacity where the average entry is 45 characters has very low utilization. **Average Utilization** gives you the mean percentage of field length used across all records. Together with Text Field Utilization, it paints a complete picture of whether your text fields are right-sized. **Example:** During an org assessment, Text Field Utilization reveals that `Notes__c` (a Long Text Area, 131,072 characters) averages 3.2% utilization, with most entries under 200 characters. Meanwhile, `Short_Description__c` (Text, 255 characters) shows 94% utilization with frequent truncation issues. The schema needs right-sizing: the Long Text Area is overkill, and the Text field is too small. > **Note:** Text Field Utilization and Average Utilization apply only to String and TextArea fields, because these are the field types with a defined character capacity to measure against. ### Why Rates and Counts Come in Pairs Most metrics come as a rate (percentage) and a count (absolute number). This is intentional: - **Rates** are for dashboards, executive reporting, and trend tracking. "Completeness improved from 72% to 89% this quarter." - **Counts** are for project planning, workload estimation, and cleanup scoping. "We have 14,200 records to fix." Use rates to communicate progress. Use counts to plan work. ## Metric Reference ### Foundation Metrics These 5 metrics form the base of every completeness analysis. They work on virtually all field types. | Metric | Type | Applies To | |--------|------|-----------| | Completeness Rate | Percentage | All field types | | Populated Count | Count | All field types | | Incompleted Count | Count | All field types | | Null Rate | Percentage | All field types | | Null Count | Count | All field types | ### Contextual Metrics These 5 metrics go beyond "is it there?" to ask "is it meaningful?" They require the Contextual Completeness analysis mode. | Metric | Type | Applies To | |--------|------|-----------| | Placeholder Rate | Percentage | Text fields only | | Placeholder Count | Count | Text fields only | | Rich Text Ratio | Percentage | Text fields only | | Text Field Utilization | Percentage | String and TextArea only | | Average Utilization | Percentage | String and TextArea only | ### Field Type Coverage DQS supports completeness checks on all standard Salesforce field types: | Coverage Group | Field Types | Metrics Available | |---------------|-------------|-------------------| | All types (20) | String, TextArea, LongTextArea, Html, EncryptedText, Picklist, Multipicklist, Email, Phone, URL, Reference (Lookup), Date, DateTime, Double, Integer, Currency, Percent, Boolean, Combobox, Id | Completeness Rate, Populated/Incompleted Count, Null Rate/Count | | Text fields (8) | Text, TextArea, LongTextArea, Html, EncryptedText, Email, Phone, URL | Above + Placeholder Rate/Count, Rich Text Ratio | | String and TextArea (2) | String, TextArea | Above + Text Field Utilization, Average Utilization | ## Two Analysis Modes DQS offers two completeness analysis modes: **Basic Completeness** answers the question: "Are fields filled in?" It produces the 5 foundation metrics and covers the essentials every org needs for a data hygiene check or quick audit. **Contextual Completeness** goes deeper. It produces all 10 metrics, including placeholder detection, rich text analysis, and field utilization. Use this mode when you need to distinguish between data that is *present* and data that is *useful*. | Business Need | Recommended Mode | |---------------|-----------------| | Quick hygiene check or baseline audit | Basic Completeness | | Data migration assessment | Contextual (placeholder detection catches fake data from legacy systems) | | AI readiness evaluation | Contextual (Rich Text Ratio and utilization metrics assess content depth) | | Ongoing data governance | Start with Basic, move to Contextual when ready for deeper analysis | ## Configuring Completeness DQS provides four configuration inputs for completeness. Each can be set at the global level (applies to all fields) and overridden at the individual field level. | Setting | What It Controls | |---------|-----------------| | **Blank As Incomplete** | When enabled, DQS treats empty strings and whitespace-only values as incomplete. Default: enabled. | | **Placeholders As Incomplete** | When enabled, DQS treats placeholder values (like "N/A" or "TBD") as incomplete. Default: disabled. | | **Placeholder Values** | The list of strings DQS treats as placeholders. You define these based on your org's data entry patterns (e.g., `N/A, TBD, Unknown, --, 000-000-0000`). | | **Case-Sensitive Placeholders** | Controls whether placeholder matching is case-sensitive. When enabled, "tbd" and "TBD" are treated as different values. Default: case-sensitive. | > **Tip:** Start with the common placeholders ("N/A", "TBD", "Unknown", "--") and add org-specific values as you discover them in scan results. ## Common Completeness Issues ### Optional Fields Never Filled When fields are optional, users skip them. Over time, valuable fields like Company Description or LinkedIn URL have near-zero completeness rates. **Fix:** Make critical fields required, or create prompts during record editing. ### Bulk Imports with Gaps Data migrations and list imports often lack values for certain fields. A purchased contact list has no Account association. A legacy system export lacks standardized Industry values. **Fix:** Audit imports before loading. Use DQS to establish baselines and track improvement after each import. ### Placeholder Abuse Users enter "N/A" or "TBD" to pass validation rules. The field appears complete but contains no usable data. Standard reports count these as populated. **Fix:** Enable placeholder detection and define your placeholder values list. Review and update placeholder values during regular data maintenance. ### Whitespace Padding Some integrations or manual entry leaves fields with whitespace only. Salesforce counts these as "filled" but they contain nothing useful. **Fix:** Enable blank detection to catch whitespace-only values. ## Best Practices ### Prioritize by Business Impact Not every field needs high completeness. Focus on fields that drive automation, appear in executive dashboards, feed AI and Agentforce, or support compliance requirements. ### Track Trends Over Time A single completeness score is a snapshot. Track scores across multiple scans to detect degradation early, measure improvement initiatives, and identify problem data sources. ### Address Root Causes Low completeness signals a process issue. Investigate whether users are skipping fields, imports are missing data, or integrations are failing silently. Fix the source, not just the symptom. ### Use the Diagnostic Funnel Do not stop at Completeness Rate. Walk through the funnel: check the scale (Populated Count), identify the cause (Null vs Placeholder), then evaluate content quality (Rich Text Ratio, Utilization). Each step reveals a different type of problem with a different fix. ## Next Steps You now understand how to measure and improve completeness. Continue learning about the next dimension: - **In Salesforce:** [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/) - measure completeness across your CRM records - **Next:** [Validity](/resources/data-quality/validity/) - Ensure your data conforms to expected formats - **Related:** [The Five Dimensions](/resources/data-quality/five-dimensions/) - Overview of all dimensions - **Action:** [AI Readiness Assessment](/ai-readiness/) - See your current completeness scores # Quick Start Guide > Get from zero to your first data quality insights in 10 minutes. Step-by-step guide to getting started. Source: https://dataqualitysense.com/resources/getting-started/quick-start-guide/ Last updated: 2026-06-03 --- ## Get Started in 10 Minutes This guide takes you from zero to your first data quality insights. Follow these steps to understand your current state and identify where to focus first. ## Step 1: Take the AI Readiness Assessment Start with the free assessment to establish your baseline. **What you'll get:** - Score across key data quality dimensions - Specific recommendations for improvement - Comparison to industry benchmarks - Priority areas to address first **How to take it:** 1. Go to [AI Readiness Assessment](/ai-readiness/) 2. Answer 10 questions about your Salesforce data practices 3. Get your score in 3 minutes > **Tip:** Be honest in your answers. The assessment is for your benefit, not a test to pass. Accurate answers give you accurate recommendations. ## Step 2: Understand Your Score The assessment provides scores across five data quality dimensions: | Dimension | What It Measures | Low Score Means | |-----------|------------------|-----------------| | Completeness | Required fields populated | Missing data in critical fields | | Validity | Correct formats | Malformed emails, phones, etc. | | Uniqueness | No duplicates | Duplicate records fragmenting data | | Timeliness | Current information | Stale records need updating | | Consistency | Uniform values | Inconsistent formats across records | ### Score Tiers | Score | Tier | What It Means | |-------|------|---------------| | 80-100 | Strong | Your data foundation is solid. Focus on maintaining it. | | 60-79 | Developing | Good progress, but specific areas need attention. | | 40-59 | Emerging | Multiple dimensions need improvement before AI initiatives. | | 0-39 | Critical | Significant data quality issues exist. Start with fundamentals. | ## Step 3: Identify Priority Areas Based on your score, identify 2-3 areas to focus on first. Do not try to fix everything at once. ### Prioritization Framework | If Your Score Is Low In... | Start With... | |----------------------------|---------------| | Completeness | Identify top 5 critical fields, measure fill rates | | Validity | Audit email and phone formats, add validation rules | | Uniqueness | Run duplicate detection, establish merge process | | Timeliness | Define freshness thresholds, create update workflows | | Consistency | Standardize picklist values, clean up variations | ### High-Impact Starting Points For most organizations, these fields have the highest impact: **Contacts:** - Email (validity, completeness) - Phone (validity, completeness) - Title (completeness, consistency) **Accounts:** - Industry (completeness, consistency) - Annual Revenue (timeliness, completeness) - Billing Address (validity, completeness) **Opportunities:** - Close Date (timeliness) - Amount (completeness) - Stage (consistency) ## Step 4: Install DQS When you're ready to measure your actual Salesforce data, install Data Quality Sense. > **Get Data Quality Sense:** [Install from Salesforce AppExchange](https://appexchange.salesforce.com/appxListingDetail?listingId=e1742ac7-7ec3-4dfb-815e-7922082524c4) ### Installation Steps 1. Go to Salesforce AppExchange 2. Search for "Data Quality Sense" 3. Click "Get It Now" 4. Follow the installation wizard 5. Assign permissions to users who will configure and run scans ### What DQS Adds After installation, you have access to: | Feature | Description | |---------|-------------| | Definition Builder | Configure what to analyze | | Scan Execution | Run data quality checks | | Results Dashboard | View metrics and drill-down | | Export | Download affected records for cleanup | ## Step 5: Create Your First Definition A Definition tells DQS what to analyze. Start with a focused scope. > **See it in action:** [Watch this step in the demo (0:29)](#dqs-demo-29) ### Recommended First Definition For your first scan, focus on one object with high business impact: **Option A: Contact Data Quality** - Object: Contact - Fields: Email, Phone, MailingCity, MailingState, MailingCountry - Dimensions: Completeness, Validity, Consistency **Option B: Account Health Check** - Object: Account - Fields: Industry, AnnualRevenue, BillingCity, BillingState - Dimensions: Completeness, Consistency, Timeliness **Option C: Opportunity Pipeline** - Object: Opportunity - Fields: Amount, CloseDate, StageName - Dimensions: Completeness, Timeliness ### Definition Builder Steps 1. Click **New Definition** in DQS 2. Select **Capabilities** (which dimensions to measure) 3. Select **Object** and **Fields** to analyze 4. Optionally add **Filters** to narrow scope 5. **Configure** thresholds for each dimension 6. **Review** and save For detailed guidance, see the [Definition Builder Guide](/resources/using-dqs/definition-builder/). ## Step 6: Run Your First Scan With your Definition saved, run your first scan. > **See it in action:** [Watch this step in the demo (2:32)](#dqs-demo-152) 1. Open the Definition 2. Click **Run Scan** 3. Wait for processing to complete (time depends on record count) 4. Review results in the dashboard ### Schedule Recurring Scans With DQS, you can automate scans so your data quality is monitored continuously without manual effort. 1. Open your Definition 2. Navigate to the **Schedule** tab 3. Set the frequency (daily, weekly, or monthly) 4. Choose the preferred time and day 5. Save the schedule For a walkthrough, see [Running Scans](/resources/using-dqs/running-scans/). Scheduled scans run automatically in the background and update your dashboard with fresh results. This is the recommended approach for ongoing monitoring — you catch data quality degradation early without having to remember to run scans manually. ### What to Expect First scans often reveal more issues than expected. This is normal. Your goal is visibility, not perfection. Common first-scan findings: - 10-30% of records have at least one issue - Certain fields have much lower fill rates than expected - Duplicate detection finds records you did not know existed - Format validation reveals inconsistencies in data entry ## What to Do Next ### Week 1: Understand the Baseline - Review scan results - Identify the top 3 issues by volume - Understand which records are affected ### Week 2-4: Address Priority Issues - Start with the highest-impact, easiest-to-fix issues - Create a cleanup plan for affected records - Add validation rules to prevent new issues ### Ongoing: Monitor and Maintain - Schedule recurring scans - Track improvement over time - Expand scope to additional objects and fields ## Next Steps - [Understanding Results](/resources/using-dqs/understanding-results/): How to interpret your scan data - [Definition Builder Guide](/resources/using-dqs/definition-builder/): Detailed configuration guidance - [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/): Preparing data for Agentforce - [Best Practices](/resources/best-practices/common-pitfalls/): Avoid common data quality mistakes # How to Improve Data Quality in Salesforce > A practical, repeatable workflow to improve and maintain data quality in Salesforce: detect, prioritize, fix, prevent, and monitor. Source: https://dataqualitysense.com/resources/salesforce/improve-data-quality-in-salesforce/ Last updated: 2026-07-15 --- Improving data quality in Salesforce is not a project with an end date. CRM data decays continuously — through manual entry, integrations, time, and now AI agents reading and writing records — so the goal is not a one-time cleanup but a repeatable loop that keeps quality high as new data arrives. The decay rate is well documented: B2B contact data goes stale at roughly [2.1% per month, or about 22.5% per year](https://pipeline.zoominfo.com/marketing/b2b-data-decay), which means a cleanup that ends in January is measurably out of date by summer. This guide lays out that loop and the Salesforce-specific tactics that make each step work. ## The Improvement Loop Every durable data-quality program, whether you run it by hand or with a tool, follows the same five steps: 1. **Detect** — measure where you stand today, by dimension and by field. 2. **Prioritize** — rank issues by business impact against the effort to fix. 3. **Fix** — clean up existing records. 4. **Prevent** — stop the same problem from coming back. 5. **Monitor** — re-measure on a schedule so new issues surface early. Skipping any step breaks the loop. Cleaning without preventing means you fix the same duplicates every quarter. Preventing without monitoring means you never know whether it worked. The steps reinforce each other. ## Step 1: Detect You cannot prioritize what you cannot see. Start by [measuring your data quality](/resources/salesforce/measure-data-quality-in-salesforce/) to get a baseline Data Quality Score broken down by dimension and field. The breakdown is what matters: "completeness is 64 on Accounts, driven by a blank Industry field" is a starting point you can act on; "the data is messy" is not. A good baseline answers three questions: which objects are worst, which dimension dominates the problem, and which specific fields drive the failures. ## Step 2: Prioritize Not every issue deserves the same urgency. Rank what you found on two axes: - **Business impact** — does this field drive revenue, reporting, automation, or AI? A missing Opportunity Amount distorts the forecast; a missing secondary fax number does not. - **Effort to fix** — can this be solved with a bulk update and a validation rule, or does it need a process change and stakeholder buy-in? Start with high-impact, low-effort issues. They build momentum and free up capacity for the harder structural problems. ## Step 3: Fix Fixing falls into a few repeatable patterns in Salesforce: | Problem | Typical fix | |---|---| | Missing values (completeness) | Bulk update from a trusted source; enrichment; make the field required where appropriate | | Invalid formats (validity) | Mass correction, then a validation rule to enforce the format going forward | | Duplicates (uniqueness) | Merge records; configure duplicate and matching rules to block new ones | | Inconsistent values (consistency) | Standardize to a controlled picklist; replace free text with a constrained field | | Stale records (timeliness) | Re-engagement or archival workflows; flag records past a freshness threshold | | Exposed PII | Identify with [PII detection](/resources/ai-readiness/pii-detection/), then mask, restrict, or remove | Fixing the existing backlog is necessary, but on its own it is a treadmill. The leverage is in the next step. ## Step 4: Prevent The difference between a one-time cleanup and a lasting improvement is prevention. The economics favor it heavily: the 1-10-100 rule from quality management research (Labovitz and Chang, *Making Quality Work*, 1992) estimates that an error costs $1 to prevent at entry, $10 to correct afterward, and $100 once it reaches customers or decisions. Salesforce gives you native controls to stop bad data at the source: - **Validation rules** reject malformed values before they are saved. - **Required fields** (on the page layout or via validation) close completeness gaps at entry. - **Duplicate and matching rules** block duplicate Accounts and Contacts as they are created. - **Picklists instead of free text** eliminate an entire class of consistency problems. - **Integration contracts** — agreeing which system owns which field — prevent two sources from overwriting each other. Each control you add lowers the rate at which new issues appear, which is what actually moves the score over time. ## Step 5: Monitor A single fix is invisible the moment new data starts flowing. Schedule recurring scans — daily, weekly, or monthly — so your Data Quality Score becomes a trend line, not a snapshot. When a new integration starts writing bad data, a monitored score dips within days and you catch it before it reaches a report or an AI model. Without monitoring, the same problem surfaces months later as a broken dashboard nobody trusts. ## How DQS Helps Data Quality Sense supports the whole loop inside Salesforce, with no data export. You define what good looks like in the Definition Builder, run a scan to get a weighted Data Quality Score with a field-level breakdown, schedule it to repeat, and track the trend in Insight Studio. Detection and prioritization become a dashboard rather than a spreadsheet exercise — so the loop is something you run continuously, not a project you restart every quarter. ## Next Steps - [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/): the complete guide - [How to Measure Data Quality in Salesforce](/resources/salesforce/measure-data-quality-in-salesforce/): the Data Quality Score - [Common Pitfalls](/resources/best-practices/common-pitfalls/): mistakes that undermine data quality programs - [Building a Data Quality Culture](/resources/best-practices/building-data-quality-culture/): making improvement stick # Validity: Configuration Scenarios > Three practical walkthroughs showing how to configure DQS validity analysis for different business needs. Source: https://dataqualitysense.com/resources/use-cases/validity-scenarios/ Last updated: 2026-02-23 --- ## What These Scenarios Cover This page walks through three real-world configurations of DQS validity analysis. Each scenario covers a specific business problem, shows the exact settings to use, and explains how to read the results. These walkthroughs build on the concepts from the main [Validity](/resources/data-quality/validity/) article. Read that first if you are new to validity metrics, the diagnostic flow, or pattern configuration. ## Scenario 1: Secondary Email Validation on a Custom Text Field ### The Problem Your organization stores a secondary email address in a custom `Secondary_Email__c` text field on the Contact object. Unlike the standard Salesforce Email field, a text field has no built-in format validation. Users paste, type, and import anything into it. Marketing wants to use these secondary addresses for a re-engagement campaign, but nobody knows how many are structurally valid. You need a concrete number so marketing can set realistic campaign projections and your ops team can scope the cleanup. > **Why not the standard Email field?** Salesforce's native Email field type validates format on input. Values in a standard Email field already pass basic format checks. DQS email validation is useful on custom Text fields that store email addresses without Salesforce's built-in enforcement. ### Configuration Use **Format Validation** mode on the Contact object, targeting the `Secondary_Email__c` field. You need the headline validity rate and a count of usable records. Placeholder detection and noise analysis are not relevant here because email addresses either match the format or they don't. | Setting | Value | Why | |---------|-------|-----| | Analysis Mode | Format Validation | You need the match rate and valid count, not the full invalid breakdown | | Pattern Type | Email | Built-in pattern: `^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$` | | Include Blanks | OFF | Blank emails are a completeness problem, not a validity problem. Keep them out of this analysis. | | Case Sensitive | OFF | Email addresses are case-insensitive by definition | The Email pattern is a built-in preset. You do not need to write any regex. Select "Email" from the pattern picker and the regex is applied automatically. ### Sample Results | Metric | Value | |--------|-------| | Validity Rate | 71% | | Valid Count | 35,500 | Total Contact records evaluated: 50,000. ### Reading the Results Start with the headline: 71% validity. That means 29% of secondary email addresses fail the format check. Of 50,000 Contacts with a populated `Secondary_Email__c`, only 35,500 have a structurally valid address. **What 29% invalid looks like in practice:** These are values missing the "@" symbol (`john.company.com`), missing a domain extension (`john@company`), containing double dots (`john@company..com`), or including spaces (`john @company.com`). Because this is a text field, Salesforce accepted all of them on entry. Every campaign sent to these addresses bounces. **The campaign math changes.** Marketing has been projecting re-engagement reach based on 50,000 secondary addresses. The real addressable audience is 35,500. Open rates, click rates, and conversion projections all need to be recalculated against the valid base, not the inflated total. **Why Format Validation is enough here.** You don't need the Advanced mode for this scenario. The question is simple: "How many secondary emails match a valid format?" Validity Rate and Valid Count answer that question. If you later need to scope a cleanup project with exact invalid counts, switch to Advanced Format Validation for the full breakdown. ### What to Do Next Use Valid Count (35,500) as the real addressable audience for campaign planning. Scope a cleanup project for the remaining 14,500 records: export them, identify the most common format errors, and fix them through data enrichment or manual correction. Consider adding a Salesforce validation rule on `Secondary_Email__c` to enforce email format on future entries, or convert the field to the Email type if your processes allow it. --- ## Scenario 2: Product Code Validation with Fixed Length ### The Problem Your company uses 8-character product codes in a custom `Product_Code__c` field on the Opportunity Product object. These codes drive inventory lookups, pricing rules, and ERP integration. The ERP sync has been failing on roughly 5% of records each week, and the integration team suspects malformed product codes. You need to confirm how many codes fail the format check and get the exact cleanup scope. ### Configuration Use **Advanced Format Validation** mode on the Opportunity Product object, targeting the `Product_Code__c` field. You need the full valid/invalid breakdown so the integration team has exact record counts for their remediation project. | Setting | Value | Why | |---------|-------|-----| | Analysis Mode | Advanced Format Validation | You need Invalid Count to scope the cleanup, plus Noise Rate to check for junk entries | | Pattern Type | Fixed Length | Product codes are always exactly 8 characters | | Fixed Length | 8 | Your standard code length | | Include Blanks | ON | A blank product code is invalid for ERP sync. Count it as a failure. | | Case Sensitive | OFF | Product codes are not case-dependent in your system | The Fixed Length pattern generates the regex `^.{8}$` automatically. Any value that is not exactly 8 characters fails validation. ### Sample Results **Foundation Metrics:** | Metric | Value | |--------|-------| | Validity Rate | 94.2% | | Valid Count | 9,420 | **Advanced Metrics:** | Metric | Value | |--------|-------| | Invalid Rate | 5.8% | | Invalid Count | 580 | | Noise Rate | 0.4% | | Noisy Records Count | 40 | Total records evaluated: 10,000. ### Reading the Results **5.8% invalid confirms the integration team's estimate.** 580 product codes out of 10,000 do not match the 8-character format. These are the records breaking the ERP sync. **Invalid Count (580) is the cleanup scope.** Your integration team now has a concrete number. Instead of investigating each sync failure individually, they can pull the 580 records, categorize the format errors, and batch-fix them. Common problems in product code fields include truncated codes (5-7 characters from copy-paste errors), codes with trailing spaces (9 characters because of an invisible space), and codes with dashes or prefixes added by users ("PC-12345678"). **Noise Rate (0.4%) is low but worth noting.** 40 records contain noise patterns: repeated characters ("XXXXXXXX"), keyboard entries ("asdfghjk"), or special character strings. These 40 records are not format errors. They are junk entries that happen to be exactly 8 characters long. Validity Rate counted them as valid because they pass the length check, but they are garbage data that will fail the ERP lookup for a different reason. Noise Rate catches what the format check misses. **Include Blanks ON matters here.** With Include Blanks enabled, any record where `Product_Code__c` is empty counts as invalid. If you had left this setting off, those blank records would be excluded from evaluation entirely, and your Invalid Count would be lower than the true number of records failing ERP sync. Since a blank product code breaks the integration the same way a malformed one does, including blanks gives you the accurate failure scope. ### What to Do Next Export the 580 invalid records for the integration team. Categorize errors by type: truncated codes, extra characters, trailing spaces. Fix them in bulk using a data update job. For the 40 noisy records, investigate the source. If they came from a specific import or user, address that root cause. After cleanup, add a Salesforce validation rule enforcing the 8-character length on `Product_Code__c` to prevent new bad entries. Rescan to verify your new Validity Rate. --- ## Scenario 3: Web-to-Lead Company Name Noise Detection ### The Problem Your web-to-lead form requires the `Company` field. Lead volume is strong: 20,000 new leads per quarter. But the SDR team reports that many leads have garbage company names, entries like "asdf", "test", "xxx", or "na na na." These leads waste SDR time and pollute your segmentation. A basic completeness check shows 98% of leads have a Company value. You suspect the 98% is misleading because junk entries are technically "populated." ### Configuration Use **Advanced Format Validation** mode on the Lead object, targeting the `Company` field. You need Noise Rate to quantify the garbage that hides behind a healthy completeness score. For the format pattern, there is no strict format rule for company names. Company names are free text. Use a minimal text validation to check that the value contains at least one alphanumeric character. | Setting | Value | Why | |---------|-------|-----| | Analysis Mode | Advanced Format Validation | You need Noise Rate and Noisy Records Count to quantify junk entries | | Pattern Type | Custom | No built-in pattern fits free-text company names | | Custom Pattern | `^.*[a-zA-Z0-9].*$` | Matches any value containing at least one letter or digit. Catches values that are purely special characters. | | Include Blanks | ON | Blank company names are a problem too. Include them in the failure count. | | Case Sensitive | OFF | Not relevant for this pattern, but leave it off as the default | The real value of this scan is in the noise metrics, not the format validation. The custom pattern is intentionally loose because you are not enforcing a specific company name format. You are running the scan in Advanced mode to get access to Noise Rate and Noisy Records Count. ### Sample Results **Foundation Metrics:** | Metric | Value | |--------|-------| | Validity Rate | 97.5% | | Valid Count | 19,500 | **Advanced Metrics:** | Metric | Value | |--------|-------| | Invalid Rate | 2.5% | | Invalid Count | 500 | | Noise Rate | 12% | | Noisy Records Count | 2,400 | Total Lead records evaluated: 20,000. ### Reading the Results **97.5% validity is expected and not the point.** Almost every value passes the loose format check because the pattern only requires one alphanumeric character. The 500 invalid records are entries with only special characters or whitespace, values like "---", "...", or "!!!". Those are easy to identify and delete. **Noise Rate (12%) is the real finding.** 2,400 leads have company names that contain noise patterns. These are entries with repeated characters ("aaaa", "xxxxx"), consecutive special characters ("!@#$%"), or control characters. They pass the format check because they contain alphanumeric characters, but the values are garbage. **The true data quality picture:** | Category | Records | What It Means | |----------|---------|---------------| | Clean and valid | 17,100 | Real company names ready for SDR outreach | | Invalid (pure junk) | 500 | No alphanumeric content at all. Delete or quarantine. | | Noisy (hidden junk) | 2,400 | Looks populated but contains garbage. Manual review or auto-flag. | Your SDR team is right: the lead quality problem is real. 2,900 out of 20,000 leads (14.5%) have unusable company data. That is 14.5% of SDR time wasted on leads that can never be properly routed, enriched, or segmented. **The completeness vs validity gap.** Completeness says 98% of leads have a Company value. Validity says 97.5% pass the format check. Noise Rate says 12% of those passing values are garbage. Each dimension reveals a different layer of the problem. Completeness alone misses the junk that Noise Rate catches. ### What to Do Next Build a cleanup queue for the 2,900 combined invalid and noisy records. For the 500 purely invalid records, auto-delete or quarantine them. For the 2,400 noisy records, decide: auto-delete leads with no other useful data, or flag them for manual review if phone or email data is still usable. Fix the source. The junk is coming from your web form. Add client-side validation: a minimum character length, block repeated-character patterns, and consider CAPTCHA for bot prevention. After implementing form changes, run the scan again next quarter and compare Noise Rate to this baseline. --- ## Choosing Your Configuration Use this table to pick the right starting point for your validity analysis. | If You Need To... | Start With | Key Settings | |--------------------|------------|--------------| | Check email format on custom text fields | Format Validation | Pattern Type: Email, Include Blanks: OFF | | Validate fixed-length codes (product codes, SKUs, postal codes) | Advanced Format Validation | Pattern Type: Fixed Length, set your character count, Include Blanks: ON | | Validate URL format on website fields | Format Validation | Pattern Type: URL, Include Blanks: OFF | | Enforce a custom business format (regex) | Advanced Format Validation | Pattern Type: Custom, enter your regex pattern | | Detect junk and noise in free-text fields | Advanced Format Validation | Use a loose format pattern, focus on Noise Rate and Noisy Records Count | | Scope a data cleanup project for an integration | Advanced Format Validation | Include Blanks: ON, use Invalid Count and Noisy Records Count for project sizing | For a full reference of all 6 validity metrics, pattern types, and noise detection details, return to the main [Validity](/resources/data-quality/validity/) article. Ready to measure your own data quality? Take the [AI Readiness Assessment](/ai-readiness/) to see your validity scores and more. # Running Scans > Learn how to execute DQS scans, monitor progress, handle large datasets, and schedule recurring scans. Source: https://dataqualitysense.com/resources/using-dqs/running-scans/ Last updated: 2026-06-03 --- ## How Scans Work When you run a scan, DQS processes your Salesforce records against the capabilities you configured. The scan runs in the background using Salesforce Batch Apex, so you can continue working while it processes. DQS respects Salesforce governor limits automatically. Your org stays responsive during scans. ## Running a Manual Scan ### Starting a Scan 1. Open DQS from the App Launcher 2. Find your Definition in the list 3. Click **Run Scan** (or the play icon) 4. Confirm to start The scan begins processing immediately. ### Scan Status Indicators | Status | Icon | Meaning | |--------|------|---------| | Queued | Clock | Waiting to start | | Processing | Spinner | Currently running | | Completed | Checkmark | Finished successfully | | Failed | X | Error occurred | ### Viewing Active Scans The DQS home screen shows all running scans: - Definition name - Progress percentage - Records processed / total - Elapsed time - Estimated time remaining ## Understanding Progress ### Progress Tracking DQS processes records in batches. The progress bar shows: - **Batches completed** out of total batches - **Records processed** out of total records - **Current capability** being evaluated Example: "Processing batch 5 of 12 (2,500 of 6,000 records) - Completeness" ### Processing Order DQS evaluates capabilities in this order: 1. Completeness (fast field checks) 2. Validity (format pattern matching) 3. Timeliness (date comparisons) 4. Consistency (value conformance) 5. Uniqueness (duplicate detection) 6. AI Readiness capabilities Lower-cost capabilities run first to provide quick feedback. ### Estimated Time Scan duration depends on: | Factor | Impact | |--------|--------| | Record count | More records = longer time | | Field count | More fields = longer time | | Capability cost | HIGH-cost capabilities take longer | | Org load | Busy orgs process slower | Typical processing rates: | Record Count | Estimated Time | |--------------|----------------| | 1,000 | Under 1 minute | | 10,000 | 2-5 minutes | | 100,000 | 15-30 minutes | | 1,000,000+ | 1-2 hours | These are estimates. Actual time varies by capability selection and org activity. ## Processing Costs Each capability has a processing cost that affects scan duration. ### Cost Levels | Cost | Capabilities | Processing Notes | |------|--------------|------------------| | LOW | Completeness, Validity | Simple field checks per record | | MEDIUM | Timeliness, Consistency, PII Detection | Pattern analysis and date math | | HIGH | Uniqueness | Cross-record comparisons | ### Cost Calculation The Definition summary shows estimated total cost: - **Low** - All selected capabilities are LOW cost - **Medium** - At least one MEDIUM cost capability - **High** - At least one HIGH cost capability > **Tip:** For your first scan on a large dataset, start with LOW-cost capabilities only. Add HIGH-cost capabilities once you understand the baseline. ## Batch Processing Details ### How Batch Apex Works DQS uses Salesforce Batch Apex to process records. Here's what that means: 1. Records are divided into batches (default: 200 records per batch) 2. Each batch processes independently 3. If one batch fails, others continue 4. Governor limits reset between batches This approach allows DQS to: - Process millions of records - Respect Salesforce limits - Run without blocking users - Resume if interrupted ### Salesforce Governor Limits Batch Apex has these key limits: | Limit | Value | Notes | |-------|-------|-------| | Max queued batch jobs | 5 | DQS uses 1 job per scan | | Records via QueryLocator | 50 million | More than enough for most orgs | | Daily batch executions | 250,000 | Across all batch jobs in org | DQS is designed to stay well within these limits. ### Batch Size Optimization DQS adjusts batch size based on capability complexity: | Capability Type | Batch Size | |----------------|------------| | LOW cost only | 200 records | | MEDIUM cost included | 200 records | | HIGH cost included | 100 records | Smaller batches for complex capabilities prevent timeout errors. ## Handling Large Datasets ### Datasets Over 100,000 Records For large datasets, follow these practices: 1. **Use filters** to limit scope 2. **Start with LOW-cost capabilities** first 3. **Run during off-peak hours** when possible 4. **Monitor progress** for any issues ### Datasets Over 1 Million Records For very large datasets: 1. **Segment your data** using multiple Definitions with filters 2. **Schedule scans** during maintenance windows 3. **Run capabilities separately** if needed 4. **Use segmentation** to process data in parallel Example segmentation: - Definition A: Contacts where Region = 'Americas' - Definition B: Contacts where Region = 'EMEA' - Definition C: Contacts where Region = 'APAC' ### Performance Tips | Tip | Benefit | |-----|---------| | Fewer fields per Definition | Faster processing | | Use record filters | Smaller dataset to scan | | Run HIGH-cost capabilities separately | Better progress visibility | | Schedule for off-peak | Less competition for resources | ## Scan Completion ### Completion Notifications When a scan finishes, you receive: 1. **In-app notification** - Bell icon shows new results 2. **Email notification** - Summary sent to your email 3. **Home screen update** - Status changes to Completed ### Viewing Results Click on a completed scan to see: - Overall quality score - Dimension-level scores - Metric details - Drill-down to affected records See [Understanding Results](/resources/using-dqs/understanding-results/) for interpretation guidance. ### Scan History DQS keeps a history of all scans for each Definition: - Date and time - Duration - Record count - Overall score - Comparison to previous scan Use history to track improvement over time. ## Scheduling Scans You can schedule recurring scans to automate data quality monitoring. ### Setting Up a Schedule 1. Open your Definition 2. Click **Schedule** (clock icon) 3. Choose frequency: - Daily - Weekly (select day) - Monthly (select date) 4. Set start time 5. Click **Save Schedule** ### Schedule Best Practices | Frequency | Use Case | |-----------|----------| | Daily | High-volume data entry, critical quality monitoring | | Weekly | Standard quality tracking, trend analysis | | Monthly | Executive reporting, compliance audits | > **Tip:** Schedule scans during off-peak hours (early morning or weekends) to minimize impact on users. ### Managing Schedules From the Definition detail page: - **Edit** - Change frequency or time - **Pause** - Temporarily stop without deleting - **Resume** - Restart a paused schedule - **Delete** - Remove schedule entirely ### Schedule Limits Scheduled scans are available for all users with no cap on the number of schedules you can set up. ## Canceling a Scan ### How to Cancel 1. Find the running scan on the home screen 2. Click the stop icon (or **Cancel**) 3. Confirm cancellation ### What Happens When Canceled - Processing stops after the current batch - Partial results are saved - Status changes to "Canceled" - You can view partial data collected Canceled scans do not count against limits. ## Troubleshooting ### "Scan queued but not starting" **Cause:** Other batch jobs in your org are running. **Solution:** Wait for other jobs to complete. Salesforce allows 5 concurrent batch jobs maximum. **Check:** Setup > Apex Jobs to see what's running. ### "Scan failed" **Cause:** Usually a data issue or permission problem. **Solution:** 1. Check the error message in scan details 2. Verify you have access to the object and fields 3. Review any filter conditions for errors 4. Try running with fewer records ### "Scan taking too long" **Cause:** Large dataset or HIGH-cost capabilities. **Solution:** 1. Let it complete (it will finish eventually) 2. Add filters to reduce record count 3. Remove HIGH-cost capabilities 4. Schedule for off-peak hours ### "Results don't show all records" **Cause:** Filter conditions excluded some records. **Solution:** Review and adjust your Definition filters. ## Next Steps - [Understanding Results](/resources/using-dqs/understanding-results/): Interpret your scan data - [Definition Builder](/resources/using-dqs/definition-builder/): Modify your Definition # 10 Common Data Quality Pitfalls > Avoid the mistakes that derail data quality initiatives and learn recovery strategies. Source: https://dataqualitysense.com/resources/best-practices/common-pitfalls/ Last updated: 2026-07-15 --- ## What You'll Learn This guide covers the most common mistakes that derail data quality initiatives. You will understand: - The top 10 pitfalls and their warning signs - Recovery strategies when things go wrong - How DQS helps prevent each pitfall - Real-world patterns that indicate trouble [Gartner predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data](https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk). Most failures trace back to preventable mistakes. Learn from others' experience. ## Pitfall 1: Treating Quality as a One-Time Project **The Mistake**: Running a "data cleanup project" with a defined end date, then declaring victory. **Warning Signs**: - Quality initiative has a "completion date" - No ongoing budget after initial project - Success measured by project delivery, not sustained quality - No scheduled recurring scans **Why It Fails**: Data degrades continuously. [Even high-quality data becomes misleading or obsolete over time](https://www.ibm.com/think/insights/data-quality-issues). A one-time fix addresses today's problems but ignores tomorrow's. The economics compound too: the 1-10-100 rule from George Labovitz and Yu Sang Chang's quality research (*Making Quality Work*, 1992) holds that an error costs $1 to prevent at entry, $10 to correct later, and $100 once it reaches customers or downstream decisions. **Recovery Strategy**: 1. Convert project budget to operational budget 2. Establish recurring scan schedule in DQS 3. Define ongoing stewardship responsibilities 4. Report quality metrics regularly, not just at project end **How DQS Helps**: Schedule recurring scans to catch degradation early. Track trends over time to prove ongoing value. --- ## Pitfall 2: Focusing on Technology Over Process **The Mistake**: Buying a tool and expecting it to solve quality problems automatically. **Warning Signs**: - Extensive tool evaluation, minimal process design - No documented data entry standards - Tool configured but rarely used - Quality measured but not acted upon **Why It Fails**: [The failure rate persists because organizations focus on technology deployment rather than addressing fundamental issues](https://www.integrate.io/blog/data-transformation-challenge-statistics/). Cultural resistance represents the dominant barrier. **Recovery Strategy**: 1. Pause technology focus 2. Document current data entry processes 3. Identify where bad data enters the system 4. Fix processes before optimizing tools **How DQS Helps**: DQS identifies where problems exist, but fixing them requires process change. Use scan results to prioritize process improvements. --- ## Pitfall 3: Not Measuring Baselines **The Mistake**: Launching improvement initiatives without knowing the starting point. **Warning Signs**: - No current quality metrics documented - Improvement claims without evidence - Unable to answer "how bad is it?" - Anecdotes instead of data **Why It Fails**: Without baseline measurement, you cannot: - Prove improvement - Identify which problems matter most - Set realistic targets - Justify continued investment **Recovery Strategy**: 1. Run comprehensive DQS scan immediately 2. Document current state across all dimensions 3. Create baseline report for stakeholders 4. Set improvement targets based on actual data **How DQS Helps**: Run your first scan before any cleanup work. Export results as your baseline. Compare future scans against this starting point. --- ## Pitfall 4: Trying to Fix Everything at Once **The Mistake**: Attempting to address all data quality issues simultaneously across all systems. **Warning Signs**: - Initiative scope includes "all data" - No prioritization of fields or objects - Resources spread too thin - Progress hard to demonstrate **Why It Fails**: Perfect is the enemy of good. Broad scope dilutes focus and delays visible results. Teams become overwhelmed and lose momentum. **Recovery Strategy**: 1. Identify highest-impact data domain 2. Focus on 5-10 critical fields 3. Achieve measurable improvement 4. Expand scope only after success **How DQS Helps**: Create focused Definitions for specific objects. Start with one high-priority domain. Add scope as you prove value. > **Tip:** Ask "what data, if wrong, hurts the business most?" Start there. --- ## Pitfall 5: Ignoring Root Causes **The Mistake**: Repeatedly cleaning bad data without fixing why it became bad. **Warning Signs**: - Same issues reappear after cleanup - Cleanup projects happen repeatedly - No analysis of how bad data enters - Front-line processes unchanged **Why It Fails**: [Manual entry mistakes like typos and misclassifications are a common source of bad data](https://portable.io/learn/data-quality-issues). Fixing symptoms without addressing causes creates an endless cycle. **Recovery Strategy**: 1. For each quality issue, ask "why does this happen?" 2. Trace bad data back to its entry point 3. Implement prevention at the source 4. Add validation rules in Salesforce 5. Improve training for data entry staff **How DQS Helps**: Drill down to specific records with issues. Analyze patterns. Use findings to identify systemic causes. --- ## Pitfall 6: No Clear Data Ownership **The Mistake**: Assuming "someone" owns data quality without defining who. **Warning Signs**: - No documented Data Owners - IT blamed for business data problems - Cross-functional disputes about data - Nobody accountable for quality targets **Why It Fails**: [No designated stewards means no one is accountable for data quality](https://atlan.com/data-quality-issues/). Issues fall through cracks between teams. **Recovery Strategy**: 1. List critical data domains 2. Assign a business owner for each 3. Document responsibilities in writing 4. Include quality targets in owner's goals 5. Establish escalation paths **How DQS Helps**: Organize Definitions by data domain. Assign Definition ownership. Route scan results to appropriate owners. --- ## Pitfall 7: Reactive Instead of Proactive **The Mistake**: Addressing quality only when problems cause visible business impact. **Warning Signs**: - Quality work triggered by complaints - No scheduled quality monitoring - Issues discovered during reporting - Crisis mode is normal **Why It Fails**: Reactive approaches catch problems after damage is done. Proactive monitoring catches issues early. **Recovery Strategy**: 1. Schedule regular DQS scans 2. Set threshold alerts for key metrics 3. Review trends weekly, not just issues 4. Build quality checks into data entry **How DQS Helps**: Schedule scans on a recurring basis. Monitor trends before they become crises. Catch degradation early. --- ## Pitfall 8: Forgetting AI Readiness **The Mistake**: Focusing on traditional data quality while ignoring AI-specific requirements. **Warning Signs**: - PII exposure not assessed before AI deployment - Data completeness and consistency unchecked - AI initiative launched without data assessment - No baseline quality score across key objects **Why It Fails**: [Data quality concerns exploded from 56% to 82%](https://qat.com/ai-data-quality-mistakes/) as AI adoption accelerated. Traditional quality metrics don't capture AI readiness. [Gartner reports that 63% of organizations either don't have, or aren't sure they have, the right data management practices for AI](https://qat.com/ai-data-quality-mistakes/). **Recovery Strategy**: 1. Assess data quality across all five dimensions before AI deployment 2. Scan for PII exposure in free-text fields 3. Fix completeness and consistency gaps that degrade AI accuracy 4. Establish a quality baseline and track improvement over time **How DQS Helps**: DQS includes PII Detection to scan text fields for sensitive data before AI exposure. Combined with the five data quality dimensions (completeness, consistency, validity, timeliness, uniqueness), you get a full pre-AI audit. > **Tip:** AI readiness assessment takes hours. AI failures cost months. Assess first. --- ## Pitfall 9: Underestimating Change Management **The Mistake**: Treating data quality as a technical problem without addressing organizational change. **Warning Signs**: - No communication plan - Training not provided - Front-line staff surprised by new requirements - Resistance from affected teams **Why It Fails**: [Cultural resistance represents the dominant barrier, while companies allocate only 10% of transformation budgets to change management](https://www.integrate.io/blog/data-transformation-challenge-statistics/). **Recovery Strategy**: 1. Identify affected stakeholders 2. Communicate why quality matters 3. Provide training before imposing requirements 4. Involve front-line staff in process design 5. Celebrate early wins **How DQS Helps**: Use scan results to communicate the current state. Share improvement metrics to demonstrate progress. Make quality visible. --- ## Pitfall 10: Not Celebrating Progress **The Mistake**: Focusing only on problems without recognizing improvement. **Warning Signs**: - Reports focus on failures - No recognition for quality improvement - Teams feel criticized, not supported - Burnout among data stewards **Why It Fails**: Sustained effort requires positive reinforcement. Teams that feel their work matters continue contributing. **Recovery Strategy**: 1. Track and report improvements 2. Recognize individuals and teams 3. Share success stories broadly 4. Connect quality wins to business outcomes **How DQS Helps**: Compare scans over time. Quantify improvement. Create before/after reports for recognition. --- ## Recovery Checklist When a data quality initiative is struggling, use this checklist: | Question | If No | |----------|-------| | Do we have executive sponsorship? | Secure sponsor before proceeding | | Is ownership clearly defined? | Assign Data Owners for each domain | | Are we measuring consistently? | Establish baseline with DQS | | Is scope focused? | Narrow to highest-impact data | | Are processes addressed? | Map and fix data entry processes | | Is this treated as ongoing? | Convert project to operations | | Do teams understand why? | Communicate business impact | | Are we recognizing progress? | Establish recognition program | ## Warning Signs Summary Watch for these patterns that indicate trouble: | Pattern | Likely Pitfall | |---------|----------------| | "We cleaned this last year" | One-time project (#1) | | Tool purchased but unused | Technology over process (#2) | | "We don't know how bad it is" | No baseline (#3) | | "We're fixing all data" | Boiling the ocean (#4) | | Same problems recur | Ignoring root causes (#5) | | Finger-pointing between teams | No ownership (#6) | | Issues found during audits | Reactive mode (#7) | | AI project hitting data problems | Forgot AI readiness (#8) | | "Nobody told us" | Change management gaps (#9) | | Low morale in data team | Not celebrating (#10) | ## Next Steps - [Data Governance Framework](/resources/best-practices/data-governance-framework/): Establish structure that prevents pitfalls - [Measuring Data Quality](/resources/best-practices/measuring-data-quality/): Build baselines and track progress - [Quick Start Guide](/resources/getting-started/quick-start-guide/): Get started the right way # Validity > All 6 validity metrics DQS measures, the diagnostic flow for finding format errors and noise, and how to configure pattern-based validation. Source: https://dataqualitysense.com/resources/data-quality/validity/ Last updated: 2026-02-23 --- ## What is Validity? Validity measures whether data values conform to expected formats and patterns. A value is valid when it matches the defined structure. A value is invalid when it breaks the format rules. An email address is valid when it contains an "@" symbol and a domain. A URL is valid when it starts with a protocol and contains a domain. A product code is valid when it has the exact character count your system requires. DQS validates field values using regex (regular expression) patterns. You choose from built-in patterns for common formats like Email, URL, and Fixed Length, or write your own regex for any business-specific format. ``` Validity Rate = (Records Matching Pattern / Total Records) x 100 ``` If 35,500 of 50,000 Contact records have an email address that matches the email format pattern, your Email validity rate is 71%. The remaining 29% contain values that fail the pattern check. ### Validity vs Accuracy Validity and accuracy are different concepts: | Check | Valid? | Accurate? | |-------|--------|-----------| | john@company.com | Yes | Unknown without verification | | john@company | No | N/A (format is wrong) | | john.doe@formerjob.com | Yes | No (person left the company) | | 555-123-4567 | Yes | Unknown without calling | | 555-12-456 | No | N/A (wrong digit count) | DQS measures validity because format checks can be automated. Accuracy requires external verification or human confirmation. Valid data works in your systems even if it does not reflect reality. Invalid data breaks your systems regardless of its real-world truth. Focus on validity first. Address accuracy through verification processes. ## Why Validity Matters Invalid data causes failures across your entire stack. Bounced emails damage sender reputation. Malformed phone numbers waste dialer time. Broken URLs frustrate users and block enrichment tools. APIs reject malformed data. When your integration sends an invalid email format to a marketing platform, the entire batch can fail. Salesforce flows that parse field values break when the format is unexpected. AI models process text as-is. When a phone field contains "Phone: 555-1234" instead of a clean number, the model sees inconsistent patterns. Invalid formats reduce AI effectiveness and produce unreliable Agentforce outputs. | System | Validity Impact | |--------|-----------------| | Email campaigns | Bounces damage sender reputation | | Telephony | Invalid numbers waste dialer time | | Web links | Broken URLs block enrichment and navigation | | APIs | Malformed data causes sync failures | | AI and Agentforce | Inconsistent formats reduce model accuracy | ## How DQS Measures Validity DQS produces 6 validity metrics organized around a diagnostic question: **"Does the data match the pattern, and is there junk hiding in values that pass?"** Think of these metrics as a diagnostic flow. Each step reveals a deeper layer of the problem. ### Step 1: Does It Match the Pattern? **Validity Rate** is the headline metric. It calculates the percentage of records where the field value matches your configured pattern. This is the number you put on a dashboard. You configure the Email pattern on the `PersonEmail` field for Contacts. Validity Rate comes back at 71%. That means 29% of email addresses fail the format check. They are missing the "@" symbol, have no domain, or contain spaces. Every marketing campaign sent to those addresses bounces. Every automated workflow that triggers on email fails silently. **Valid Count** tells you the absolute number. Of 50,000 Contacts, 35,800 have valid email addresses. That is your actual addressable audience for email campaigns, not the 50,000 in the system. Marketing can set realistic campaign projections instead of working from inflated numbers. ### Step 2: What Is the Full Breakdown? Rates tell you severity. Counts tell you workload. Two metrics complete the picture: | Metric | What It Tells You | |--------|-------------------| | **Invalid Rate** | The negative framing of your validity score. "29% of our email addresses are structurally invalid" gets more attention in a board presentation than "71% are valid." Same data, framed for action. | | **Invalid Count** | The cleanup workload as a hard number. Your company is migrating to a new telephony system requiring E.164 format. Invalid Count on the Phone field: 23,400. That is the exact number of records that need reformatting before the migration can go live. | ### Step 3: Is There Junk Beyond Format Errors? A value can pass a format check and still be garbage. Your web-to-lead form requires a Company field. Validity Rate on Company is 98%, because almost everything passes a basic text pattern. But **Noise Rate** reveals 14% of those values are entries like "asdf", "test", "xxxxx", or "na na na." Format-valid, but completely useless for sales routing, enrichment, or segmentation. **Noisy Records Count** gives you the cleanup scope. If Noise Rate is 14% on 50,000 records, that is 7,000 leads with garbage company names. Your ops team can build a cleanup queue, estimate hours, and decide whether to auto-delete or flag for manual review. ### Two Categories of Failure Validity metrics distinguish two fundamentally different problems: | Problem | Metrics | Root Cause | Fix | |---------|---------|------------|-----| | **Format errors** | Validity Rate, Invalid Rate, Valid/Invalid Count | Human mistakes, integration bugs, missing validation rules | Clean the data: field validation rules, data transformation, enrichment | | **Noise and junk** | Noise Rate, Noisy Records Count | Bots, forced form submissions, bulk imports with garbage defaults | Fix the source: CAPTCHA, required field redesign, record deletion | The distinction matters because the fix is completely different. Format errors are remediated by cleaning the data. Noise is remediated by fixing the source that produces it. ## Metric Reference ### Foundation Metrics These 2 metrics form the base of every validity analysis. They tell you the match rate and the number of records that pass. | Metric | Type | What It Measures | |--------|------|-----------------| | Validity Rate | Percentage | Share of records matching the configured pattern | | Valid Count | Count | Number of records matching the configured pattern | ### Advanced Metrics These 4 metrics go beyond "does it match?" to give the full breakdown, including noise detection. They require the Advanced Format Validation analysis mode. | Metric | Type | What It Measures | |--------|------|-----------------| | Invalid Rate | Percentage | Share of records failing the configured pattern | | Invalid Count | Count | Number of records failing the configured pattern | | Noise Rate | Percentage | Share of records containing noise patterns (junk data) | | Noisy Records Count | Count | Number of records containing noise patterns | ### Why Rates and Counts Come in Pairs Most metrics come as a rate (percentage) and a count (absolute number). This is intentional: - **Rates** are for dashboards, executive reporting, and trend tracking. "Validity improved from 71% to 92% this quarter." - **Counts** are for project planning, workload estimation, and cleanup scoping. "We have 23,400 phone numbers to reformat." Use rates to communicate progress. Use counts to plan work. ## Field Type Coverage All 6 validity metrics share the same base field type support, with noise metrics limited to text fields. | Metric | All 6 Field Types | String and TextArea Only | |--------|:--:|:--:| | Validity Rate | X | | | Valid Count | X | | | Invalid Rate | X | | | Invalid Count | X | | | Noise Rate | | X | | Noisy Records Count | | X | Pattern-based metrics (Validity Rate, Valid Count, Invalid Rate, Invalid Count) work on all 6 supported field types: String, TextArea, Email, Phone, URL, and Picklist. Noise metrics (Noise Rate, Noisy Records Count) apply only to String and TextArea fields. Noise patterns like repeated characters and keyboard smash are free-text phenomena. A Picklist field with a valid picklist value cannot contain noise. Noise detection only makes sense on fields where users type free text. ## Two Analysis Modes DQS offers two validity analysis modes: **Format Validation** answers the question: "Do field values match the expected pattern?" It produces the 2 foundation metrics and covers the essentials for a format compliance check or quick audit. **Advanced Format Validation** goes deeper. It produces all 6 metrics, including the full valid/invalid breakdown and noise detection. Use this mode when you need to distinguish between format errors and junk data, or when you need precise counts for cleanup project planning. | Business Need | Recommended Mode | |---------------|-----------------| | Quick format compliance check | Format Validation | | Compliance reporting or audit | Advanced (full valid/invalid breakdown for regulators) | | Lead quality assessment | Advanced (Noise Rate catches junk that passes format checks) | | Pre-migration data assessment | Advanced (full breakdown to scope remediation by category) | | Ongoing data governance | Start with Format Validation, move to Advanced for noise detection | ## Configuring Validity Unlike completeness (which works automatically on any field), validity requires configuration. You must define what "valid" means for each field before DQS can check it. A validity scan without a pattern is meaningless: valid compared to what? DQS provides 5 configuration inputs. Each can be set at the global level (applies to all fields) and overridden at the individual field level. | Setting | What It Controls | |---------|-----------------| | **Pattern Type** | The format to validate against. Choose from Email, URL, Fixed Length, or Custom regex. Required: you must select a pattern type before running a scan. | | **Pattern / Fixed Length** | The specific value for your chosen type. For Fixed Length, enter a character count (1 to 255). For Custom, enter a regex pattern. Email and URL use built-in patterns. | | **Custom Pattern** | Your own regex when Pattern Type is set to Custom. DQS validates your regex before saving and blocks invalid expressions. | | **Include Blanks** | When enabled, DQS counts blank values as invalid. When disabled (the default), blanks are excluded from evaluation entirely. | | **Case Sensitive** | When enabled, pattern matching considers letter casing. When disabled (the default), matching is case-insensitive. | ### Pattern Types | Type | What It Validates | Example Pass | Example Fail | |------|-------------------|-------------|-------------| | **Email** | Standard email address format: user@domain.tld | user@example.com | user@domain, invalid-email | | **URL** | HTTP/HTTPS web addresses with valid domain | https://example.com | example.com, htp://site.com | | **Fixed Length** | Exact character count (you define the number) | `AAAAAAAAAA` (10 chars, if length = 10) | `SHORT` (5 chars) | | **Custom** | Any regex pattern you define | Depends on your pattern | Depends on your pattern | **Example:** Your product codes follow the format "DQS-" followed by 6 digits. Set Pattern Type to Custom and enter the regex `^DQS-\d{6}$`. DQS flags any product code that does not match this structure. ## Noise Detection Noise detection catches data that passes format checks but is still garbage. DQS uses two built-in heuristics to identify noisy values: **Heuristic 1: Consecutive identical characters.** Three or more of the same character in a row. Values like "aaaa", "!!!", "---", or "xxxxx" trigger this check. These typically come from keyboard holding, padding, or placeholder abuse. **Heuristic 2: Excessive special characters.** More than 50% non-alphanumeric characters (excluding spaces). Values like "!@#$%^" or "***///---" trigger this check. These indicate keyboard smash, bot input, or deliberate junk entry. | Heuristic | What It Catches | Example Noisy Values | Example Clean Values | |-----------|-----------------|---------------------|---------------------| | 3+ consecutive identical characters | Padding, filler, keyboard holding | "aaaa", "!!!", "---", "xxxxx" | "Premium", "DOT AB3 2024" | | More than 50% special characters | Keyboard smash, bot input, junk | "!@#$%^", "***test", "//--//" | "test@email.com", "O'Brien Inc" | You can also define custom noise patterns using regex for org-specific junk that the built-in heuristics do not cover. > **Tip:** Noise detection is most valuable on free-text fields where users can type anything: Company, Description, Notes, and custom text fields. Run it on your web-to-lead fields first, where bot submissions and forced entries are most common. ## Common Validity Issues ### Invalid Email Addresses Users enter emails without proper format. Missing "@" symbols, missing domains, double dots, and typos are the most common problems. | Issue | Example | |-------|---------| | Missing @ | john.company.com | | Missing domain | john@ | | Double dots | john@company..com | | Typos | john@comapny.com | **Impact:** Bounced emails, damaged sender score, lost communication. ### Malformed Phone Numbers Phone fields accept any text in Salesforce, leading to inconsistent and invalid formats. | Issue | Example | |-------|---------| | Letters mixed in | 555-CALL-NOW | | Wrong digit count | 555-12 | | Extension in field | 555-1234 ext 5 | | Country code confusion | 1-555-123-4567 vs 555-123-4567 | **Impact:** Failed calls, wasted sales time, telephony sync errors. ### Invalid URLs Web address fields often contain partial or malformed values. | Issue | Example | |-------|---------| | Missing protocol | www.company.com | | Missing domain | https:// | | Typos | htps://company.com | | Social handles | @company (not a URL) | **Impact:** Broken links, failed enrichment, navigation errors. ## Best Practices ### Validate at Entry The best validity check happens at data entry. Use Salesforce validation rules to enforce formats before data enters your system. ``` // Example: Email format validation rule NOT(ISBLANK(Email)) && NOT(REGEX(Email, "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$")) ``` ### Standardize Formats Before Scanning Choose one format for each field and enforce it. For phone numbers, E.164 (`+15551234567`) is the most universally accepted standard. For URLs, require the `https://` protocol. Document your format decisions so the team knows the standard. ### Set Thresholds by Field Priority Different fields need different validity standards: | Field | Suggested Threshold | Rationale | |-------|---------------------|-----------| | Primary Email | 95%+ | Critical for communication | | Phone | 90%+ | Important but legacy data expected | | Website | 85%+ | Often entered incompletely | | Custom text codes | 98%+ | System-generated, expect high compliance | ### Use Noise Detection on Free-Text Fields Run noise detection on fields where users type free text: Company, Description, custom text fields, and any field populated by web forms. Noise Rate reveals problems that format validation misses. ### Document Expected Formats Create a data dictionary that specifies the expected format for each field, acceptable variations, and examples of valid and invalid values. Share this with your team and reference it during data cleanup projects. ## Next Steps You now understand how to validate data formats and detect noisy values. Continue learning about the next dimension: - **In Salesforce:** [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/) - enforce valid formats on Salesforce fields - **Next:** [Uniqueness](/resources/data-quality/uniqueness/) - Detect and prevent duplicate records - **Previous:** [Completeness](/resources/data-quality/completeness/) - Ensure required data is present - **Related:** [The Five Dimensions](/resources/data-quality/five-dimensions/) - Overview of all dimensions - **Action:** [AI Readiness Assessment](/ai-readiness/) - See your current validity scores # Salesforce Data Quality Dashboard: Metrics That Matter > What a Salesforce data quality dashboard should track: the Data Quality Score, dimension breakdowns, field health, trends, and PII exposure. Source: https://dataqualitysense.com/resources/salesforce/salesforce-data-quality-dashboard/ Last updated: 2026-06-03 --- A data quality dashboard turns dozens of scattered checks into a single view you can monitor at a glance. In Salesforce, the right dashboard tells you — in seconds — how trustworthy your data is, where the problems concentrate, and whether things are getting better or worse. This guide covers the metrics that matter and how to read them. ## What a Data Quality Dashboard Is For A dashboard answers three questions on a recurring basis: - **Can I trust this data today?** A single headline number for an at-a-glance read. - **Where are the problems?** A breakdown that turns the headline into specific, ownable tasks. - **Are we improving?** A trend that shows whether your fixes are working and catches new issues early. If a dashboard cannot answer all three, it is a report, not a monitoring tool. ## The Metrics That Matter A useful Salesforce data quality dashboard tracks a small set of complementary metrics rather than a wall of numbers: | Metric | What it tells you | Why it matters | |---|---|---| | **Data Quality Score** | A single weighted 0–100 figure across all dimensions | The headline. One number leaders can track over time. | | **Dimension breakdown** | Score per dimension (completeness, validity, uniqueness, consistency, timeliness) | Shows *what kind* of problem dominates | | **Field health** | Pass/fail rate per field | Shows *where exactly* the problem lives — the actionable layer | | **Trend over time** | The score across successive scans | Shows whether you are improving and surfaces new issues fast | | **PII exposure** | Records and fields containing sensitive data | Critical before any Agentforce or AI project | | **Worst offenders** | The objects and fields driving the most failures | Tells you where to start | Together these move you from "how healthy is the data?" down to "which field, on which object, do we fix first?" in three clicks. ## How to Read the Dashboard Read it top-down, from headline to action: 1. **Headline.** Glance at the Data Quality Score. Up from last scan? Down? Flat? 2. **Dimension.** Open the dimension breakdown to see which type of problem is pulling the score down — a completeness problem and a uniqueness problem call for very different fixes. 3. **Field.** Drill into the weakest dimension's field health to find the specific fields driving failures. This is the layer someone can own and fix. 4. **Trend.** Check the trend line. A sudden dip usually means a new integration or process started writing bad data — catch it here, not in a broken report three months from now. ## Why Trends Beat Snapshots A single measurement is obsolete the day after you take it, because Salesforce data changes constantly. The real value of a dashboard is the **trend**. A score of 82 means little on its own; 82 and falling for three weeks is an alarm, while 82 and climbing is proof your program works. Scheduled scans are what turn a one-time audit into a trend you can manage — and what let you set a target and watch the line move toward it. ## What "Good" Looks Like There is no universal passing score; it depends on how the data is used. A practical way to set targets is to tier them by stakes: | Data | Target | |---|---| | Regulatory / compliance fields | 99%+ | | Customer-facing and revenue data | 95%+ | | Operational data | 85%+ | | Historical / archival data | 70%+ | Set the target per dimension and per object, then let the dashboard tell you how far each one has to go. ## Building It in DQS Data Quality Sense provides this dashboard inside Salesforce through Insight Studio. After you run a scan from the Definition Builder, Insight Studio shows the weighted Data Quality Score, the per-dimension breakdown, field health, and the trend across scans — plus PII exposure for AI-readiness work. Because scans run natively and on a schedule, the dashboard always reflects live data in your org, with no exports and no external pipeline to maintain. ## Next Steps - [How to Measure Data Quality in Salesforce](/resources/salesforce/measure-data-quality-in-salesforce/): the Data Quality Score in depth - [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/): the complete guide - [How to Improve Data Quality in Salesforce](/resources/salesforce/improve-data-quality-in-salesforce/): from dashboard to action - [Measuring Data Quality](/resources/best-practices/measuring-data-quality/): KPIs and scorecards in depth # Timeliness: Configuration Scenarios > Three practical walkthroughs showing how to configure DQS timeliness analysis for different business needs. Source: https://dataqualitysense.com/resources/use-cases/timeliness-scenarios/ Last updated: 2026-02-23 --- ## What These Scenarios Cover This page walks through three real-world configurations of DQS timeliness analysis. Each scenario covers a specific business problem, shows the exact settings to use, and explains how to read the results. These walkthroughs build on the concepts from the main [Timeliness](/resources/data-quality/timeliness/) article. Read that first if you are new to timeliness metrics, the diagnostic flow, or configuration options like Freshness Window and Null As Stale. ## Scenario 1: Lead Outreach Freshness on a Custom Date Field ### The Problem Your sales team tracks when each lead was last contacted in a custom `Last_Outreach_Date__c` field on the Lead object. SDRs update this field manually after each call or email. The CRM shows 8,000 open leads, but nobody knows how many have recent outreach. Some leads were never contacted at all because the field was left blank. The sales ops team needs a clear count of fresh vs stale leads so they can prioritize the queue and catch leads that fell through the cracks. > **Why a custom field?** Standard Salesforce date fields like `LastModifiedDate` are always populated and update automatically. A custom date field like `Last_Outreach_Date__c` depends on user input. It can be null (never contacted), outdated (contacted months ago), or current. That makes it a good target for freshness analysis with Null As Stale enabled. ### Configuration This is a straightforward freshness check. Use **Data Freshness** mode on the Lead object, targeting the `Last_Outreach_Date__c` field. You need the headline freshness rate and staleness breakdown, not the advanced anomaly metrics. | Setting | Value | Why | |---------|-------|-----| | Analysis Mode | Data Freshness | You need freshness and staleness rates, not overdue tracking or anomaly detection | | Freshness Window | 30 days | Active leads need engagement within the last month | | Null As Stale | ON | A null `Last_Outreach_Date__c` means the lead was never contacted. That is stale by definition. | `Last_Outreach_Date__c` is a "last event" field. Freshness Rate is the right headline metric here. Overdue Rate would read tautologically high because most outreach dates are in the past by nature. ### Sample Results | Metric | Value | |--------|-------| | Freshness Rate | 38% | | Staleness Rate | 62% | Total Lead records evaluated: 8,000. ### Reading the Results Start with the headline: 38% freshness. That means 62% of your open leads, 4,960 records, have no outreach in the last 30 days. Your SDRs are working from a pool of 8,000 leads where nearly two-thirds are cold. Now break down what the 62% staleness contains. **Null As Stale is ON, so nulls are counted as stale.** If 1,200 of those 4,960 stale records have a null `Last_Outreach_Date__c`, those leads were never contacted at all. They entered the system through a web form, import, or integration and nobody logged outreach. The remaining 3,760 records have an outreach date, but it is older than 30 days. Two groups, two different actions: - **For the 1,200 nulls:** These are untouched leads. Route them to SDRs for first contact. They are not "stale" in the traditional sense. They are leads that fell through the cracks. - **For the 3,760 with old outreach dates:** These are leads where outreach happened but engagement stopped. Review the age distribution. If most dates cluster around 31-45 days, a quick follow-up campaign can move many back into the fresh window. If most dates are 90+ days old, consider recycling or archiving them. ### What to Do Next Use the Freshness Rate to segment your lead pool. Create a list view or report filtered to `Last_Outreach_Date__c` within the last 30 days and route those 3,040 fresh leads to your SDRs first. Track Freshness Rate over time. If it drops between scans, your lead follow-up process has a gap. If it climbs, your outreach cadence is working. --- ## Scenario 2: Contract Renewal Deadline Tracking ### The Problem Your customer success team manages 2,500 active contracts. Renewals are tracked in the `Contract_End_Date__c` field on the Account object. The team gets a quarterly report of upcoming renewals, but contracts that slip past their end date without renewal go unnoticed for weeks. By the time someone spots an expired contract, the customer has already started evaluating competitors. You need a way to measure how many contracts are past due and by how much. ### Configuration Use **Advanced Data Freshness** mode on the Account object, targeting the `Contract_End_Date__c` field. You need Overdue Rate with a grace period because this is a deadline field where "past due" has direct business meaning. | Setting | Value | Why | |---------|-------|-----| | Analysis Mode | Advanced Data Freshness | Enables Overdue Rate and Average Age for the full deadline picture | | Freshness Window | 365 days | Contracts renew annually. A contract end date within the last year is "current." | | Null As Stale | ON | A null contract end date means the date was never set. That is a data gap, not a clean record. | | Overdue Tracking | ON | This is a deadline field. You need to know what percentage is past due. | | Grace Period | 30 days | Give the renewal process 30 days after the contract end date before flagging as overdue. Renewals often close in the weeks after expiration. | `Contract_End_Date__c` is a deadline field. Overdue Rate is the right headline metric here, not Freshness Rate. The question is "how many contracts are past due?" not "how many contract dates are recent?" ### Sample Results **Foundation Metrics:** | Metric | Value | |--------|-------| | Freshness Rate | 64% | | Staleness Rate | 34.8% | **Advanced Metrics:** | Metric | Value | |--------|-------| | Average Age | 210 days | | Future Rate | 1.2% | | Overdue Rate | 14% | Total Account records evaluated: 2,500. ### Reading the Results **Overdue Rate (14%) is your headline number.** 350 contracts are more than 30 days past their end date without being updated. These are active revenue leakage risks. The 30-day grace period already filtered out contracts in the normal renewal window, so these 350 are genuinely stuck. **Freshness Rate (64%) provides context.** 64% of contract end dates fall within the last 365 days. This tells you most contracts have been touched within a renewal cycle. The 34.8% that are stale include both the overdue contracts and contracts with very old end dates that were never updated after renewal. **Average Age (210 days) reveals the depth of the problem.** The mean age of contract end dates is 210 days. Given a 365-day freshness window, this average sits inside the window but closer to the stale boundary. Your dataset skews toward older dates, meaning many contracts are approaching their next renewal window. **Future Rate (1.2%) flags 30 records with contract end dates in the future.** For a contract end date, a future date is normal. It means the contract has not expired yet. A 1.2% Future Rate on 2,500 contracts means only 30 have future end dates. This is a useful data point: it tells you that the vast majority of contracts in your system are already past their end date, and the `Contract_End_Date__c` field is rarely updated to reflect renewal extensions. **The business math:** 350 overdue contracts at your average contract value represent real revenue at risk. If your average annual contract is $15,000, that is $5.25 million in contracts sitting past due with no active renewal on record. ### What to Do Next Build a priority queue from the 350 overdue contracts. Sort by contract value and days past due. Assign each to a customer success manager for immediate outreach. After the initial cleanup, run the scan monthly. Track Overdue Rate as your primary renewal health metric. A rising Overdue Rate between scans means your renewal process is falling behind. --- ## Scenario 3: Pipeline Date Cleanup After Data Migration ### The Problem Your company migrated 12,000 Opportunity records from a legacy CRM into Salesforce six months ago. Pipeline reports look wrong: deals appear in quarters they do not belong to, and forecast totals include amounts from years-old opportunities. The RevOps team suspects the `CloseDate` field contains legacy dates from the old system (some from 2015) and placeholder dates (2099-12-31) injected by the migration tool. Before the team can trust the pipeline, they need to know exactly how many close dates fall outside a realistic range. ### Configuration Use **Advanced Data Freshness** mode on the Opportunity object, targeting the `CloseDate` field. You need Operational Range Rate to define what counts as a "realistic" close date and catch everything outside that boundary. | Setting | Value | Why | |---------|-------|-----| | Analysis Mode | Advanced Data Freshness | Enables Operational Range Rate and Future Rate for anomaly detection | | Freshness Window | 180 days | A close date within the last 6 months is "current" for pipeline purposes | | Null As Stale | OFF | `CloseDate` is a required field on Opportunities. Nulls are rare and not the focus of this analysis. | | Operational Range | ON | The core of this analysis. Define what dates are realistic. | | Operational Range Min | 365 days in the past | Any close date older than 1 year from today is a legacy artifact | | Operational Range Max | 180 days in the future | Any close date more than 6 months out is either a placeholder or an unrealistically far forecast | The Operational Range inputs use "days in the past" and "days in the future" from today. DQS converts these to absolute dates at scan time. If you run this scan on March 1, 2026, the range becomes March 1, 2025 through August 28, 2026. Any close date before March 1, 2025 or after August 28, 2026 is flagged as out of range. ### Sample Results **Foundation Metrics:** | Metric | Value | |--------|-------| | Freshness Rate | 52% | | Staleness Rate | 38.5% | **Advanced Metrics:** | Metric | Value | |--------|-------| | Average Age | 285 days | | Future Rate | 9.5% | | Overdue Rate | Not computed (Overdue Tracking OFF) | | Operational Range Rate | 71% | Total Opportunity records evaluated: 12,000. ### Reading the Results **Operational Range Rate (71%) is your headline number.** 71% of close dates fall within the realistic range (1 year past to 6 months future). That means 29%, or 3,480 records, have close dates outside this boundary. These are the records distorting your pipeline. Break down what sits outside the range: **Future Rate (9.5%) flags 1,140 records with close dates in the future.** Some of these are normal: open Opportunities with upcoming close dates within the next 6 months are expected and fall inside the operational range. The records Future Rate flags here are all close dates after today. Cross-reference with the operational range: records that are both future-dated AND outside the 180-day-future boundary are the problematic ones. These are placeholder dates like 2099-12-31 or unrealistically far close dates from the migration. **The out-of-range breakdown looks like this:** | Category | Estimated Records | What It Means | |----------|-------------------|---------------| | Legacy dates (older than 365 days) | ~2,340 | Migrated from the old CRM. Close dates from 2015-2024 on deals that were never cleaned up. | | Far-future placeholders | ~1,140 | Dates like 2099-12-31 injected by the migration tool where the source system had no close date. | | **Total out of range** | **~3,480** | **Your cleanup scope** | **Average Age (285 days) confirms the legacy data drag.** The mean age across all close dates is 285 days, well outside your 180-day freshness window. This high average reflects the large volume of old migrated dates pulling the number up. After you clean the legacy records, expect this number to drop sharply. **Freshness Rate (52%) gives you the pipeline health baseline.** Only about half of your close dates are within the last 6 months. After removing the 3,480 out-of-range records, recalculate. Your clean dataset of 8,520 records will have a much higher freshness rate, and your pipeline reports will finally reflect current deals. ### What to Do Next Export the 3,480 out-of-range records. Split them into two cleanup tracks: - **Legacy dates (2,340 records):** Review by stage. Closed-Won and Closed-Lost opportunities with old close dates are historical records. Leave them but exclude them from active pipeline views. Open opportunities with close dates from 2015-2024 are dead deals that were never closed in the old system. Update their stage to Closed-Lost. - **Placeholder dates (1,140 records):** Replace 2099-12-31 and similar placeholders with realistic close dates based on the opportunity stage and creation date. For deals with no clear close timeline, set the close date to end of current quarter and flag for sales review. After cleanup, rescan. Your target is an Operational Range Rate above 95% and a Freshness Rate above 75% for the active pipeline. --- ## Choosing Your Configuration Use this table to pick the right starting point for your timeliness analysis. | If You Need To... | Start With | Key Settings | |--------------------|------------|--------------| | Check date freshness for a quick hygiene audit | Data Freshness | Set your Freshness Window, Null As Stale ON if nulls represent missing data | | Measure lead or contact engagement recency | Data Freshness | Freshness Window: 30 days, Null As Stale ON, use Freshness Rate as your headline | | Track deadlines and renewal compliance | Advanced Data Freshness | Overdue Tracking ON, set Grace Period to match your business process buffer | | Detect legacy or placeholder dates after a migration | Advanced Data Freshness | Operational Range ON, set Min/Max to define your realistic date boundary | | Get the full date quality picture on a critical field | Advanced Data Freshness | All settings configured: Freshness Window + Null As Stale + Overdue Tracking + Operational Range | | Understand staleness severity beyond the rate | Advanced Data Freshness | Review Average Age alongside Freshness Rate to plan the right remediation effort | For a full reference of all 6 timeliness metrics and how they fit into the diagnostic flow, return to the main [Timeliness](/resources/data-quality/timeliness/) article. Ready to measure your own data quality? Take the [AI Readiness Assessment](/ai-readiness/) to see your timeliness scores and more. # Understanding Results > Learn to interpret DQS scan results, read dimension scores, drill down to affected records, and export data for cleanup. Source: https://dataqualitysense.com/resources/using-dqs/understanding-results/ Last updated: 2026-06-03 --- ## Results Overview After a scan completes, DQS presents your results in a dashboard view. The dashboard shows scores at multiple levels: 1. **Overall Score** - Single number representing total data quality 2. **Dimension Scores** - Scores for each capability (Completeness, Validity, etc.) 3. **Field Scores** - Scores for each analyzed field 4. **Record Details** - Drill-down to specific affected records ## The Results Dashboard ### Dashboard Layout ``` ┌─────────────────────────────────────────────────────────────────┐ │ OVERALL QUALITY SCORE │ │ 85% │ │ ▲ +3% from last scan │ ├──────────────────────┬──────────────────────┬───────────────────┤ │ COMPLETENESS │ VALIDITY │ UNIQUENESS │ │ 92% │ 78% │ 95% │ ├──────────────────────┼──────────────────────┼───────────────────┤ │ TIMELINESS │ CONSISTENCY │ AI READINESS │ │ 88% │ 82% │ 76% │ └──────────────────────┴──────────────────────┴───────────────────┘ ``` ### Accessing Results 1. Open DQS from the App Launcher 2. Find your Definition in the list 3. Click the Definition name 4. Select the **Results** tab 5. Choose a scan date to view The most recent scan shows by default. ## Overall Quality Score The overall score is a weighted average of all dimension scores. ### How It's Calculated DQS uses default weights for each dimension: | Dimension | Default Weight | |-----------|---------------| | Completeness | 25% | | Validity | 20% | | Uniqueness | 20% | | Timeliness | 15% | | Consistency | 20% | Formula: Overall = (Completeness x 0.25) + (Validity x 0.20) + (Uniqueness x 0.20) + (Timeliness x 0.15) + (Consistency x 0.20) AI Readiness scores are shown separately and don't affect the Data Quality overall score. ### Score Interpretation | Score Range | Quality Level | Action | |-------------|---------------|--------| | 90-100% | Excellent | Maintain current practices | | 80-89% | Good | Address specific weak areas | | 70-79% | Fair | Prioritize improvement | | 60-69% | Poor | Immediate attention needed | | Below 60% | Critical | Major data cleanup required | ### Trend Indicator Next to your score, you'll see a trend arrow: - **Green arrow up** - Score improved from last scan - **Red arrow down** - Score declined from last scan - **Gray dash** - Score unchanged The percentage shows the change amount. ## Dimension Scores Click any dimension card to see detailed metrics. ### Completeness Metrics | Metric | Type | What It Shows | |--------|------|---------------| | Completeness Rate | Percentage | Fields that have values | | Populated Count | Number | Records with data | | Incomplete Count | Number | Records missing data | | Null Rate | Percentage | Fields that are NULL | | Blank Rate | Percentage | Empty or whitespace only | | Placeholder Rate | Percentage | N/A, TBD, Unknown values | **Example interpretation:** - Completeness Rate: 85% means 15% of records are missing values - High Placeholder Rate suggests users enter "TBD" instead of real data ### Validity Metrics | Metric | Type | What It Shows | |--------|------|---------------| | Validity Rate | Percentage | Values matching expected format | | Valid Count | Number | Records with correct format | | Invalid Rate | Percentage | Values not matching format | | Invalid Count | Number | Records with format errors | **Example interpretation:** - Validity Rate of 78% on Email field means 22% have format issues - Common issues: missing @, spaces, typos like ".con" ### Uniqueness Metrics | Metric | Type | What It Shows | |--------|------|---------------| | Uniqueness Rate | Percentage | Distinct vs total values | | Distinct Count | Number | Number of unique values | | Entropy | Decimal | Value diversity (higher = more diverse) | | Max Frequency | Number | Most common value occurrence | | Rarity | Percentage | How rare values are distributed | **Example interpretation:** - Uniqueness Rate of 95% means 5% are duplicates - Low Entropy suggests many records share the same values ### Timeliness Metrics | Metric | Type | What It Shows | |--------|------|---------------| | Freshness Rate | Percentage | Records within freshness window | | Staleness Rate | Percentage | Records past freshness window | | Average Age | Days | Mean age of date values | | Recency Rate | Percentage | Records updated recently | | Future Rate | Percentage | Records with future dates (errors) | | Overdue Rate | Percentage | Records past expected update | **Example interpretation:** - Staleness Rate of 30% means 30% of records haven't been touched in your freshness window - Future Rate above 0% indicates data entry errors ### Consistency Metrics | Metric | Type | What It Shows | |--------|------|---------------| | Conformance Rate | Percentage | Values matching expected patterns | | Conformance Count | Number | Records that conform | | Non-Conforming Count | Number | Records with variations | | Variant Count | Number | Different value variations found | | Dominant Values | JSON | Top values and their counts | **Example interpretation:** - Variant Count of 15 on Country field suggests inconsistent entry (USA vs United States vs US) - Dominant Values shows which variations are most common ### AI Readiness Metrics **PII Detection:** | Metric | What It Shows | |--------|---------------| | Records with PII | Absolute count of records with pattern matches (for remediation scoping) | | PII Exposure Rate | Percentage of records containing PII (for compliance reporting) | ## Field-Level Details Click a dimension to see per-field breakdown. ### Field Score Table | Field | Score | Issues | Actions | |-------|-------|--------|---------| | Email | 92% | 234 invalid | View Records | | Phone | 78% | 1,456 invalid | View Records | | MailingCity | 95% | 180 missing | View Records | ### Reading Field Scores Each field shows: - **Score** - Performance for this field - **Issues** - Count of problematic records - **Actions** - Links to drill-down and export ### Identifying Problem Fields Sort fields by score (lowest first) to find: - Fields with most issues - Fields needing immediate attention - Patterns across related fields > **Tip:** Focus on high-impact fields first. A 10% improvement in Email validity has more business value than perfecting a rarely-used field. ## Drill-Down to Records Click **View Records** to see affected data. ### Record List View The drill-down shows records with issues: | Name | Email | Issue | Created Date | |------|-------|-------|--------------| | John Smith | `john.smith@example` | Invalid format | 2026-01-15 | | Jane Doe | `jane.doe@mail,com` | Invalid format | 2026-01-20 | ### Filtering the Record List Filter by: - Issue type (missing, invalid, duplicate, etc.) - Date range - Owner - Custom field values ### Direct Record Access Click any record to open it in Salesforce. Make corrections directly or assign to the appropriate team member. ## Comparing Results Over Time ### Trend Charts DQS displays trend charts showing: - Overall score over time - Dimension scores over time - Field scores over time Charts help you: - Track improvement progress - Identify declining areas - Measure impact of cleanup efforts ### Scan Comparison Compare any two scans: 1. Click **Compare** on the Results tab 2. Select a baseline scan (older) 3. Select a comparison scan (newer) 4. View side-by-side metrics The comparison highlights: - Improved metrics (green) - Declined metrics (red) - Unchanged metrics (gray) ### Setting Improvement Targets Use historical data to set realistic targets: | Current Score | Realistic 90-Day Target | |---------------|------------------------| | Below 60% | 70-75% | | 60-70% | 75-82% | | 70-80% | 82-88% | | 80-90% | 90-94% | | Above 90% | Maintain or 95%+ | ## Exporting Data You can export results for offline analysis and cleanup workflows. ### CSV Export Export options: - **Summary Export** - Scores and metrics only - **Affected Records Export** - Full list of records with issues - **Field Detail Export** - Per-field breakdown ### How to Export 1. Open scan results 2. Click **Export** (download icon) 3. Choose export type 4. Select format (CSV) 5. Download the file ### Export Contents **Affected Records Export includes:** - Record ID - Record Name - Field with issue - Issue type - Current value - Suggested action **Example row:** ``` 0031x00000ABC123,John Smith,Email,INVALID_FORMAT,john.smith@example,Fix email domain ``` ### Using Exports for Cleanup 1. Export affected records to CSV 2. Open in Excel or Google Sheets 3. Review and correct values 4. Use Data Loader to update Salesforce 5. Re-run scan to verify improvements > **Tip:** Create a cleanup assignment workflow. Export records, assign owners based on Account or Region, and track corrections. ## Sharing Results ### Sharing Options Share results with stakeholders: 1. **Link sharing** - Copy URL to scan results 2. **Screenshot** - Dashboard view for presentations 3. **Export** - CSV for detailed analysis 4. **Email summary** - Automated reports ### Creating Reports for Leadership For executive presentations, focus on: - Overall score and trend - Improvement from previous period - Top 3 problem areas - Action plan with timeline Avoid overwhelming with metric details. Lead with the story. ## Understanding Score Changes ### Why Scores Change | Change | Common Causes | |--------|---------------| | Score improved | Cleanup efforts, better data entry | | Score declined | New data with issues, changed thresholds | | Big jump up | Bulk data cleanup completed | | Big drop down | Data import with quality issues | ### Investigating Changes When scores change unexpectedly: 1. Compare scans to identify which metrics changed 2. Drill down to field level 3. Review recent data changes (imports, integrations) 4. Check if Definition configuration changed ## Next Steps - [Definition Builder](/resources/using-dqs/definition-builder/): Adjust thresholds based on findings - [Running Scans](/resources/using-dqs/running-scans/): Schedule regular scans - [Measuring Data Quality](/resources/best-practices/measuring-data-quality/): Build a quality scorecard # Agentforce Readiness: Assessing Your Salesforce Org > Assess Agentforce readiness across data, org configuration, use cases, governance, and people. Includes a 25-point checklist and a five-level maturity model. Source: https://dataqualitysense.com/resources/ai-readiness/agentforce-readiness/ Last updated: 2026-08-15 --- > **TL;DR:** Agentforce readiness is the state in which your Salesforce org can run AI agents in production reliably, safely, and at a predictable cost. It spans five pillars: data, org configuration, use cases, governance, and people. Score your org against the 25-point checklist below, map the result to a five-level maturity model, and work the 30/60/90 day plan from wherever you land. Most stalled pilots fail on pillar one. Looking for the Trailhead superbadge unit "Dashboard Insights for Agentforce Readiness"? That is a different topic, covered on [Trailhead](https://trailhead.salesforce.com/content/learn/superbadges/dashboard_insights_for_agentforce_readiness_superbadge_unit). This article is about assessing whether your organization is ready to deploy agents. ## What Agentforce Readiness Means Agentforce readiness is the state in which your Salesforce org can run AI agents in production reliably, safely, and at a predictable cost. The word does a lot of work, so it helps to say what readiness is not. Readiness is not a license. Enabling Agentforce takes an afternoon; making it trustworthy takes longer. Readiness is also not a single dimension. An org with clean data and no escalation path ships an agent that frustrates customers. An org with a perfect use case and unresolved PII in Case Comments ships a compliance incident. Five pillars carry the assessment: | Pillar | The question it answers | Who owns it | |---|---|---| | **1. Data** | Can the agent retrieve accurate, complete, safe context? | Data owner, admin | | **2. Org configuration** | Can the agent see and do what the use case requires? | Salesforce admin, architect | | **3. Use case** | Is this task suited to an agent, and how do we know it worked? | Process owner | | **4. Governance** | Can we prove the agent behaved correctly? | Security, compliance | | **5. People** | Who owns the agent the day after launch? | Operations lead | The pillars are ordered by how often they break, not by importance. Pillar one causes most of the failures, which is why the rest of this site covers it in depth. ## Why Most Agentforce Pilots Stall Before Production A pilot is easy to start and hard to graduate. The pattern is consistent enough to name the blockers: | Blocker | What it looks like in week one | Where it surfaces later | |---|---|---| | **Grounding on thin data** | Demo works on hand-picked records | Generic answers on real records with empty Description fields | | **Unmeasured scope** | "The agent reads Case and Account" | Nobody knows the fill rate of the fields it actually reads | | **PII in free text** | Nobody scanned Comments or Notes | An SSN appears in a generated response | | **No success metric** | "See if it's useful" | No way to justify expanding, so the pilot ends quietly | | **No owner after launch** | The project team runs it | Quality drifts, nobody notices, trust erodes | Each blocker has the same root: the pilot was scoped as a technology test rather than an operations change. Readiness assessment moves those questions to the front, where they cost days instead of quarters. For the data-specific version of this failure analysis, see [Why Agentforce Agents Give Wrong Answers](/resources/ai-readiness/why-agentforce-agents-fail/). ## Pillar 1: Data Readiness Agents ground their responses in the records they retrieve. A blank field is not neutral; the agent reads it as absence of fact and answers accordingly. This pillar decides whether the other four matter. Measure the objects and fields in the agent's scope across six dimensions, then compare each against a threshold: | Dimension | DQS metric | Working threshold | |---|---|---| | Completeness | Completeness Rate | 85% or higher on fields that ground answers | | Consistency | Conformance Rate | 90% or higher on picklists and references | | Validity | Validity Rate | 90% or higher on formatted fields | | Timeliness | Timeliness Rate (shown as Data Freshness) | Within your defined window | | Uniqueness | Duplicate Rate | Low and trending down | | PII safety | PII Exposure Rate | Below 1% on text fields the agent reads | DQS rolls these into a single weighted score. Worked example: an org scans four dimensions before a pilot and gets Completeness 78, Validity 91, Consistency 84, and PII Safety 96. With default weights of 25, 20, 15, and 10, the calculation is (78 × 25) + (91 × 20) + (84 × 15) + (96 × 10) = 5,990, divided by the sum of those weights, 70. The result is **85.57**. Dimensions you did not scan stay out of the denominator, so the score reflects what you actually measured rather than punishing you for gaps in coverage. One caution on that number: a dimension with no data to measure scores 0, not 100. An empty result is not a clean result. DQS detects and reports these issues; it does not cleanse, merge, or deduplicate records for you. Remediation happens through the Tasks and Chatter actions it raises on impacted records, and through the process fixes you make upstream. Scans run in batch, manually or on a schedule, which is the right cadence for readiness work: baseline now, re-measure after remediation, then monitor. Go deeper: [Agentforce Data Readiness Checklist](/resources/ai-readiness/agentforce-data-readiness-checklist/) for the item-by-item version of this pillar, and [Salesforce Data Cleanup for Agentforce](/resources/ai-readiness/salesforce-data-cleanup-for-agentforce/) for object-level remediation. ## Pillar 2: Org Configuration Readiness An agent inherits the running user's access and can only perform the actions you expose to it. Configuration readiness is about making that boundary deliberate. Four things to settle before a pilot: **Permissions and visibility.** An agent cannot read a field hidden by field-level security. Many "the agent doesn't know that" reports turn out to be permission gaps rather than data gaps. Assign the agent user a permission set built for the use case, then verify what it can see against what the use case needs. **Actions the agent can take.** Agents act through Flows, Apex, and standard actions. Every action you expose is a capability and a risk. List them, and for each one decide whether the agent runs it unattended or hands off to a person. **Technical debt in the org.** Years of custom objects, overlapping automations, and abandoned fields make the agent's context ambiguous. Three deprecated status fields with conflicting values teach the agent three versions of the truth. **Knowledge as a source.** If the agent grounds on Knowledge articles, the articles need owners and review dates. Outdated documentation produces confidently wrong answers. Worked example: a service team scopes an agent to read Case, Contact, and Knowledge, and to execute two actions (update Case status, create a follow-up Task). That is 3 objects and 2 actions to review, not the whole org. Scoping the review this way is what makes it finishable in a week. ## Pillar 3: Use Case Readiness Not every task suits an agent. The ones that do share three traits: they repeat often, they have a verifiable correct answer, and the cost of being wrong is recoverable. Score a candidate use case on four questions: 1. **Volume.** Does this happen enough that automating it changes a number someone tracks? 2. **Determinism.** Can a reviewer look at the agent's output and say whether it was right? 3. **Blast radius.** If the agent is wrong, is the damage a bad answer, a bad record, or a bad refund? 4. **Escalation.** What triggers a handoff to a person, and does that path exist today? Define the success metric before launch, not after. "Resolution rate on tier-1 password-reset cases, measured weekly against the six weeks before launch" is a metric. "See if customers like it" is not. If you cannot name the number you will look at in 60 days, the use case is not ready. ## Pillar 4: Governance, Security, and Compliance This is the pillar competitors skip and regulators do not. Three questions decide it. **What sensitive data can the agent reach?** PII accumulates in free-text fields through copy-paste, email-to-case, and integrations. A Social Security Number in a Case Comment is inside the agent's context the moment it retrieves that record. Scan text fields in scope for patterns such as SSNs and credit card numbers before you connect an agent, and remediate confirmed matches. DQS runs entirely inside Salesforce, so records never leave the org during detection, and PII values appear as `[REDACTED]` in CSV exports rather than being copied into a file. See [Agentforce and PII](/resources/ai-readiness/agentforce-pii-compliance/) and [PII Detection](/resources/ai-readiness/pii-detection/). **Where does the data go, and under which rules?** GDPR, CCPA, HIPAA, and PCI DSS obligations do not pause for a pilot. Confirm your data residency position, what leaves the org for model processing, and what your Data Processing Agreement covers before an agent touches customer records. **Can you reconstruct a decision?** When someone asks why the agent answered as it did, you need the retrieved context, the action taken, and the timestamp. Decide who reviews agent transcripts, how often, and what happens when a review fails. Worked example: a scan of Case Description and Comments across 40,000 records returns 312 pattern matches, a PII Exposure Rate of 0.78%. That is below a 1% threshold but not zero, so the remediation task is finite: review 312 records, mask or delete confirmed matches, then rescan to confirm the rate. ## Pillar 5: People and Ownership An agent is a system that degrades. Data drifts, processes change, and the answers get worse slowly enough that nobody notices until trust is gone. Name three roles before launch: - **Agent owner.** Accountable for the agent's behavior in production, including the decision to pause it. - **Data owner.** Accountable for the quality metrics on the objects in scope. If nobody owns completeness, completeness does not improve. See [Who Owns Data Quality in Salesforce](/resources/salesforce/who-owns-data-quality-in-salesforce/). - **Reviewer.** Samples agent outputs on a schedule and reports on accuracy. Then handle the human side: the support and sales teams whose work the agent changes need to know what it does, what it will not do, and how to escalate around it. An agent introduced without that conversation gets routed around. ## What Drives Agentforce Cost Agentforce is priced on consumption, so cost scales with how much the agent does rather than how many seats you buy. Readiness affects the bill directly, which is why this belongs in an assessment rather than a procurement conversation. Four drivers to estimate before a pilot: | Driver | Why it moves the number | |---|---| | **Volume of agent actions** | Consumption is per action, so use case volume is the primary multiplier | | **Retries and failed answers** | Poor grounding produces re-asks, which are billable work with no outcome | | **Data platform footprint** | Unifying or ingesting data for grounding carries its own cost line | | **Scope creep** | Each new topic added to a live agent expands the action surface | Note the second row: bad data does not only produce bad answers, it produces more of them. An agent that cannot resolve a request on the first attempt burns consumption on the retry and the escalation. Fixing pillar one is a cost control, not only a quality control. Check current rates on Salesforce's own pricing pages before you model a budget, because consumption pricing changes more often than license pricing. ## The Agentforce Readiness Checklist Twenty-five checkpoints, five per pillar. Score one point per item you can confirm with evidence rather than opinion. The total maps to the maturity model in the next section. **Data (5 points)** - [ ] Every object and field the agent will read is listed and scoped - [ ] A baseline scan exists for each dimension in scope - [ ] Completeness Rate is 85% or higher on fields that ground answers - [ ] Conformance and Validity Rates are 90% or higher on picklists and formatted fields - [ ] PII Exposure Rate is below 1% on text fields in scope **Org configuration (5 points)** - [ ] A dedicated permission set defines what the agent user can see - [ ] Field-level security has been verified against the use case, not assumed - [ ] Every action the agent can execute is documented and approved - [ ] Conflicting or deprecated fields in scope have been retired or excluded - [ ] Knowledge articles in scope have owners and review dates **Use case (5 points)** - [ ] The first use case is high-volume and verifiable - [ ] A success metric and its baseline are recorded before launch - [ ] The escalation path to a person exists and has been tested - [ ] The blast radius of a wrong answer is understood and acceptable - [ ] A rollback or pause procedure is written down **Governance (5 points)** - [ ] Text fields in scope have been scanned for sensitive data - [ ] Data residency and processing terms are confirmed for your region - [ ] Agent transcripts are retained and reviewable - [ ] A review cadence and failure threshold are agreed - [ ] Compliance has signed off on the post-remediation scan **People (5 points)** - [ ] An agent owner is named - [ ] A data owner is named per dimension in scope - [ ] A reviewer samples outputs on a schedule - [ ] Affected teams have been briefed on scope and limits - [ ] A recurring scan schedule keeps the data metrics current ## Five Levels of Agentforce Readiness Add your checkpoints and find the band. The bands are deliberately unequal: the last two points are the hardest, because they are the operational ones. | Level | Score | State | What unlocks the next level | |---|---|---|---| | **1. Unaware** | 0-5 | Licenses discussed, nothing measured | Scope the objects and fields, run a baseline scan | | **2. Exploring** | 6-11 | Baseline exists, gaps are known | Remediate data, define one use case with a metric | | **3. Preparing** | 12-17 | Data improving, use case chosen | Close permissions, actions, and PII items | | **4. Pilot-ready** | 18-22 | Safe to run a scoped pilot | Assign ownership, set review cadence and monitoring | | **5. Production-ready** | 23-25 | Safe to expand scope | Repeat the assessment per new use case | Worked example: an org scores Data 2, Org configuration 4, Use case 3, Governance 2, and People 3. The total is 14, which places it at **Level 3, Preparing**. The two weakest pillars are Data and Governance, both at 2, so the next 30 days go to scanning and remediation rather than to agent configuration. The instinct at Level 3 is usually to start building the agent, because configuration feels like progress. It is the most common way to reach Level 4 on paper and Level 2 in production. ## After You Score: A 30/60/90 Day Plan **Days 1-30: measure and remediate.** Scope the objects and fields the agent will read. Run a baseline scan across the dimensions in scope, starting with PII because it is the only category that can block deployment outright. Fix the highest-impact, lowest-effort items, then rescan and compare against the baseline. In parallel, choose the first use case and write down its success metric. **Days 31-60: pilot narrowly.** Build the agent for one use case, one team, one channel. Verify the permission set and the action list against what the agent actually needs. Test outputs against remediated data and confirm no sensitive values appear in generated responses. Keep the scope small enough that a bad week is recoverable. **Days 61-90: measure and decide.** Compare the success metric against its pre-launch baseline. Review a sample of transcripts for accuracy. Re-run the readiness checklist, because the score changes once real usage exposes gaps. Then make an explicit decision: expand, iterate, or stop. A pilot without a decision date becomes a permanent pilot. Set a recurring scan schedule before day 90, not after. Data quality degrades as users create new records, so an org that passed in month one drifts by month three unless something is watching. See [Running Scans](/resources/using-dqs/running-scans/) for scheduling. ## Frequently Asked Questions ### What is Agentforce readiness? Agentforce readiness is the state in which your Salesforce org can run AI agents in production reliably, safely, and at a predictable cost. It covers five pillars: the quality of the data agents read, the configuration of the org they act in, the use cases they are assigned, the governance around them, and the people who own them after launch. Readiness is measured, not assumed. ### Do I need Data Cloud to use Agentforce? Not for every use case. An agent can ground its answers in the Salesforce records and Knowledge articles it already has access to. Data Cloud becomes necessary when the agent needs a unified customer profile across systems, or needs to retrieve unstructured content at scale. Decide this per use case, because it changes both your architecture and your cost model. ### How do I get my data ready for AI agents? Scope the objects and fields the agent will read, measure them across completeness, consistency, validity, timeliness, uniqueness, and PII exposure, then remediate against defined thresholds before deployment. Measurement comes first: until you have a baseline rate per dimension, data readiness is an opinion rather than a number. ### How long does it take to become Agentforce ready? For a single narrow use case, a realistic path is 90 days: 30 days to measure and remediate the data the agent will read, 30 days to run a scoped pilot, and 30 days to measure results and decide whether to expand. Orgs with heavy technical debt or unresolved PII exposure in text fields take longer, because those items block deployment rather than slow it down. ## Next Steps Readiness is a number, not a feeling. The fastest way to find your starting point is to measure the pillar that breaks most often. - [AI Readiness Assessment](/ai-readiness/): score your org's readiness in a few minutes - [Agentforce Data Readiness Checklist](/resources/ai-readiness/agentforce-data-readiness-checklist/): pillar one, item by item, with DQS metrics - [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/): the phased plan for getting Salesforce data ready - [Why Agentforce Agents Give Wrong Answers](/resources/ai-readiness/why-agentforce-agents-fail/): the data root causes behind weak agent output - [What Is a Data Quality Score?](/resources/data-quality/what-is-a-data-quality-score/): how the weighted score behind pillar one is calculated - [Contact us](/contact/): talk through a readiness assessment for your org # PII Detection > The 8 PII detection patterns DQS uses, three presets for common scanning scenarios, and how to configure pattern-based detection. Source: https://dataqualitysense.com/resources/ai-readiness/pii-detection/ Last updated: 2026-06-03 --- ## What Is PII Detection? PII Detection scans text fields for personally identifiable information using configurable regex patterns. It answers three questions about your Salesforce data: - Does my data contain PII that needs protection? - How exposed is my dataset? - Which fields hold sensitive information? DQS profiles the type and density of PII exposure across every text field. It uses pattern-based detection: regex patterns match against field values to flag SSNs, credit cards, emails, phone numbers, and other identifiers. Three properties define how detection works: 1. **Deterministic.** Same input produces the same result every time. 2. **Transparent.** You see every pattern DQS applies. No black-box scoring. 3. **On-platform.** Detection runs entirely within Salesforce. No data leaves your org. ## Why It Matters **Compliance.** GDPR, CCPA, HIPAA, and PCI DSS all mandate identifying and protecting PII. You can't protect what you haven't found. Automated detection gives you an inventory of exposure across every text field in scope. **AI readiness.** Before feeding data to Agentforce or any AI system, you need to know which fields contain PII. Undetected PII in training data or retrieval indexes creates exposure that no downstream filter can fully prevent. **Data governance.** Text fields accumulate PII over time. Agents paste email threads into case comments. Customers provide SSNs for verification. Integrations write contact details into description fields. Without detection, this PII sits unprotected. ## How DQS Detects PII DQS runs PII detection as a progressive diagnostic. Each step builds on the previous one. ### Step 1: Is There a PII Problem? **Records with PII** gives the absolute count of records where at least one pattern matched. This is the scoping number. For example: you scan Case comments using the Standard preset. Records with PII comes back as 847. That means 847 case records need review before you can safely use the data for AI training or share it with third-party analytics. ### Step 2: How Bad Is It? **PII Exposure Rate** gives the percentage of scanned records containing pattern matches. The rate puts the count in context. 847 records out of 1,000 is 84.7% exposure, a systemic problem requiring a process change. 847 out of 500,000 is 0.17%, isolated incidents you can address with targeted cleanup. ### Step 3: What Kind of PII? The pattern configuration itself tells you what types were scanned. Each pattern has a category: Financial, Contact, Technical, or Identity. By reviewing which patterns triggered matches, you know whether you're dealing with credit card leaks, email address exposure, or SSN contamination. ## The 8 Detection Patterns DQS ships with 8 predefined regex patterns organized into 4 categories. ### Financial | Pattern | What It Matches | False Positive Risk | |---------|----------------|---------------------| | Social Security Number | US SSN in NNN-NN-NNNN format | Low. The hyphenated format is distinctive. | | Credit Card Number | 13-16 digit sequences with optional spaces/hyphens | Medium. Long numeric sequences (order numbers, tracking IDs) can false-match. | | IBAN | International bank account numbers (ISO 13616 format) | Low. The country code + check digit prefix is distinctive. | ### Contact | Pattern | What It Matches | False Positive Risk | |---------|----------------|---------------------| | Email Address | Standard user@domain.tld format | Low. The @ symbol structure is distinctive. | | US Phone Number | US/Canadian formats: (NNN) NNN-NNNN, NNN-NNN-NNNN, +1 variants | Medium. 10-digit numbers with separators can match non-phone data. | | International Phone | E.164-style numbers starting with + country code | Low. The + prefix is a strong signal. | ### Technical | Pattern | What It Matches | False Positive Risk | |---------|----------------|---------------------| | IP Address | IPv4 dotted decimal (NNN.NNN.NNN.NNN) | Low-Medium. Software version numbers are the main false-positive source. | ### Identity | Pattern | What It Matches | False Positive Risk | |---------|----------------|---------------------| | Date of Birth | US date format MM/DD/YYYY or MM-DD-YYYY | High. Matches any US-formatted date. Best paired with field-level targeting. | > **DQS uses regex-only pattern matching.** Detection is format-based, not contextual. There is no checksum validation (Luhn for credit cards, modulo-97 for IBAN), no keyword proximity boosting, and no ML-based confidence scoring. Every match is binary: the pattern matched or it didn't. This makes detection fully auditable and deterministic, but you need to review matches on fields with high false-positive risk. ## Regulatory Coverage All 8 patterns are grounded in major privacy and security frameworks. | Pattern | NIST 800-122 | GDPR | CCPA | PCI DSS | HIPAA | ISO 27701 | |---------|:---:|:---:|:---:|:---:|:---:|:---:| | SSN | X | X | X | | X | X | | Credit Card | X | X | X | X | | X | | Email | X | X | X | | X | X | | US Phone | | X | X | | X | X | | Intl Phone | | X | X | | X | X | | IP Address | | X | X | | X | X | | IBAN | | X | | | | X | | Date of Birth | X | X | X | | X | X | These are the same identifier types detected as built-in patterns by Google Cloud DLP, AWS Macie, and Microsoft Purview. The difference: cloud DLP tools use multi-layered detection (regex + checksum + keyword proximity + ML). DQS uses regex-only matching, which is simpler and fully transparent but does not provide confidence scoring. ## Three Detection Presets Presets configure which patterns are active in a single click. | Preset | Patterns | Count | When to Use | |--------|----------|:-----:|-------------| | **Standard** | SSN, Credit Card, Email, US Phone | 4 | General PII audit. Covers the four most common types with manageable false-positive rates. This is the default. | | **Critical** | SSN, Credit Card | 2 | Financial compliance check. Minimum scan for identity theft and payment card exposure. Use when you need fast results with near-zero false positives. | | **Extended** | All 8 patterns | 8 | Full scan. Includes IBAN, IP Address, Date of Birth, and International Phone. Higher false-positive rate in exchange for maximum coverage. Best for first-time audits and compliance assessments. | You can also add custom regex patterns beyond the 8 predefined ones. Custom patterns are validated server-side before they can be saved. Any valid regex works. ## Metric Reference ### Foundation Metrics | Metric | Type | What It Returns | |--------|------|----------------| | Records with PII | Count (integer) | Number of records where at least one pattern matched. A record is counted once regardless of how many patterns matched or how many matches exist within it. | ### Advanced Metrics | Metric | Type | What It Returns | |--------|------|----------------| | PII Exposure Rate | Percentage | Percentage of scanned records containing PII matches. This is the headline exposure number for reports and dashboards. | ## Field Type Coverage | Metric | String | TextArea | Email | Phone | EncryptedString | LongTextArea | Html | |--------|:------:|:--------:|:-----:|:-----:|:---------------:|:------------:|:----:| | Records with PII | X | X | X | X | X | | | | PII Exposure Rate | | X | | | | X | X | Records with PII casts a wide net across all text field types. PII Exposure Rate focuses on longer text fields where PII density is meaningful. A 255-character String field matching an email regex is a single data point. A 32,000-character LongTextArea with 15 SSN matches tells a different story. ## Two Analysis Modes DQS runs PII Detection in two modes. **PII Scan** processes all selected fields using the configured patterns and returns Records with PII. This mode answers: "Do I have a PII problem?" Use it for quick audits before data migrations or AI projects. **PII Detection Analysis** adds PII Exposure Rate on top of Records with PII. The exposure rate gives context to the raw count, turning "847 records contain PII" into "12.3% of your dataset is exposed." Use this mode for compliance reporting and ongoing governance. ## Configuring PII Detection | Input | What It Controls | |-------|-----------------| | Detection Patterns | Which of the 8 predefined patterns are active. Pick a preset or toggle individual patterns. | | Custom Patterns | Any valid regex pattern, validated server-side. Added alongside predefined patterns. | | Per-Field Overrides | Different pattern sets for different fields. Override the global configuration on a field-by-field basis. | ### Choosing Patterns by Field Type Different fields need different pattern sets. An Email field already contains email addresses by design. Scanning it for email patterns produces 100% matches, which is expected, not a problem. A Case Description field is free text where any PII type can appear. Configure patterns based on what you expect to find vs. what signals a problem. Example configurations: - **Email fields:** Scan for SSN and Credit Card only (email matches are expected) - **Description and Notes fields:** Use Standard or Extended preset (free text can contain anything) - **Short text fields (Subject, Title):** Use Critical preset only (low tolerance for false positives) ## Common Issues | Issue | Cause | Fix | |-------|-------|-----| | 100% PII match rate on Email field | Email pattern matches the field's intended content | Remove the email pattern from that field's override, or exclude the field from PII scanning | | High false positives on Date of Birth | The DOB pattern matches any US-formatted date (meeting dates, deadlines) | Use field-level overrides to apply the DOB pattern only on fields where birth dates are a known risk | | No matches found despite known PII | SSN regex only matches hyphenated format (NNN-NN-NNNN), not 9 consecutive digits | Add a custom pattern for the specific format in your data. Example: `\b\d{9}\b` for unformatted SSNs (high false-positive risk) | ## Best Practices 1. **Start with the Standard preset on free-text fields.** Run an initial scan to understand your baseline before expanding to Extended. 2. **Use field-level overrides to tune detection per field.** Global patterns cast a wide net. Per-field overrides eliminate noise. 3. **Scan unstructured text fields first.** Description, Comments, and Notes fields are where PII accumulates through copy-paste and email-to-case. Structured fields (Email, Phone) contain PII by design. 4. **Review matches on high-FP patterns like Date of Birth before treating them as confirmed PII.** These patterns produce more false positives than SSN or Email. 5. **Pair Records with PII (absolute count) with PII Exposure Rate (percentage) for a complete picture.** The count scopes your cleanup effort. The rate tells you whether it's a systemic problem or isolated incidents. ## Next Steps - [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/): how PII detection fits the bigger picture - [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/): complete deployment readiness guide # Uniqueness > All 6 uniqueness metrics DQS measures, the diagnostic flow for finding duplicates and repetitive content, and how to configure uniqueness analysis. Source: https://dataqualitysense.com/resources/data-quality/uniqueness/ Last updated: 2026-02-23 --- ## What is Uniqueness? Uniqueness measures whether your data values are distinct and non-duplicated. A field has high uniqueness when each record contains a different value. Uniqueness breaks down when the same value appears across multiple records, or when text fields contain repetitive templated content that adds no analytical value. Duplicate records cost your organization at every stage. Three Account records for the same company split your pipeline. Two Contact records for the same person get two marketing emails. Boilerplate text pasted into thousands of case descriptions makes it impossible to extract insights. Uniqueness analysis quantifies all of these problems. ``` Uniqueness Rate = (Records with Unique Values / Total Records) x 100 ``` If 7,800 of 10,000 Contact records have a distinct Email value, your Email uniqueness rate is 78%. The remaining 22% share email addresses with at least one other record. This single metric tells you whether a field that expects unique values actually has them. ## Why Uniqueness Matters ### Reporting Duplicate records inflate your numbers. When the same company appears as three Accounts, your Account count is overstated by two. Pipeline reports show three deals where one exists. Customer counts used for board presentations and investor reporting are wrong. ### Automation Salesforce automation treats each record independently. A duplicate Account triggers duplicate workflows, sends duplicate notifications, and creates duplicate tasks. A renewal process that fires on every Account matching a company name triggers three times instead of once. ### AI and Agentforce AI models process each record as a separate entity. Duplicate records fragment the model's view of a customer. Agentforce generates responses using your Salesforce data. When three Account records exist for the same company, Agentforce sees three customers, not one with a complete history. Repetitive boilerplate content in text fields teaches the model your templates, not your business patterns. | System | Uniqueness Impact | |--------|-------------------| | Reports | Inflated counts, fragmented metrics | | Workflows | Duplicate triggers, redundant notifications | | Duplicate Rules | Overwhelmed by existing duplicates if not detected | | Agentforce | Fragmented customer view, template-polluted learning | ## How DQS Measures Uniqueness DQS produces 6 uniqueness metrics organized around a diagnostic question: **"Is the data distinct, how is it distributed, and is the text content original?"** Think of these metrics as a diagnostic flow. Each layer builds on the previous one. ### Layer 1: Are Values Unique? **Uniqueness Rate** is the headline metric. It calculates the percentage of records where the field value is distinct (not duplicated anywhere else in the dataset). This is the number you put on a dashboard. You run a scan on the Contact object. The `Email` field shows a Uniqueness Rate of 78%. That means 22% of email addresses appear on more than one Contact. Some are legitimate (shared department emails like info@company.com), but most are likely duplicate contacts that need merging. This single number justifies a deduplication initiative. **Distinct Count** tells you the cardinality of the field: how many different values actually exist. If 10,000 Contact records contain 8,200 distinct email addresses, the Distinct Count is 8,200. **Example:** You expect the `Lead_Source` picklist to have about 12 values (your configured picklist options). But Distinct Count shows 87. Before the picklist was restricted, reps typed in free-text values. "Web", "web", "Website", "Webinar", "web form" all count as distinct. This metric reveals that your Lead Source data needs normalization, even though the picklist is now locked down. ### Layer 2: How Is the Data Distributed? Uniqueness Rate tells you how many values are unique. Distribution metrics tell you how those values are spread across records. Two fields can have the same Uniqueness Rate but very different distributions. **Entropy** measures how evenly values are distributed using Shannon entropy. The scale ranges from 0 (every record has the exact same value) to a maximum determined by the number of distinct values. Higher entropy means more diverse, more evenly spread data. Entropy alone means nothing. Compare it to the maximum possible entropy for that field. Maximum = log2(Distinct Count), which is the entropy you get if every distinct value appeared exactly the same number of times. The ratio (actual / max) gives you a normalized score from 0 to 1: | Normalized (actual / max) | Interpretation | |---------------------------|----------------| | 0.9 or above | Even distribution: values spread uniformly | | 0.7 to 0.9 | Moderate skew: some values appear more than others | | Below 0.7 | Dominated: a few values hold most of the records | **Example:** Your `Industry` field on Accounts has a Uniqueness Rate of 2% (expected for a picklist) and 24 distinct values. Looks fine. But entropy is 1.3, and maximum entropy for 24 values is 4.6. The normalized score is 0.28. The distribution is severely skewed: 60% of records are "Technology" and "Financial Services." Your industry-based segmentation is a two-bucket system dressed up as 24 categories. **Max Frequency** gives you the count of occurrences for the single most common value. If "London" appears 8,400 times in the `City` field, Max Frequency is 8,400. A single dominant value often signals a default value problem, a migration artifact, or a genuine business concentration that needs investigation. Max Frequency raises the question. A quick check of the actual value answers it. **Example:** The `Billing_Country` field has a Max Frequency of 34,000 out of 40,000 records. That is 85% of records with one country. Either your business is genuinely concentrated in one market, or someone set a default during migration. The metric surfaces the pattern; you determine the cause. ### Layer 3: Is the Text Content Original? The first two layers measure whether values are *identical*. Layer 3 asks a different question: is text content *substantially similar*? Two case descriptions can be 100% unique (different case numbers, dates) but 90% boilerplate (same template, same phrases). **Boilerplate Rate** is the headline metric for text content originality. It measures the percentage of content that is repetitive or templated. A higher score means more original content with less boilerplate. DQS detects common templates like email signatures, legal disclaimers, and repeated phrases. **Example:** Your organization is evaluating whether the `Description` field on Opportunities is suitable for AI-powered win/loss analysis. Uniqueness Rate is 99% (every description is technically different). But Boilerplate Rate reveals that 65% of the content follows the same template: "Customer: [name]. Need: [product]. Timeline: [date]." The AI model would learn your template structure, not your win patterns. Boilerplate Rate saves you from a garbage-in, garbage-out AI project. **Boilerplate Records Count** gives you the cleanup scope as an absolute number. If 12,400 records contain boilerplate, your data steward knows the size of the remediation project. She can estimate hours, assign resources, and set a realistic timeline. **Example:** Your support team logs every interaction in `Case Comments`. Boilerplate Records Count shows 12,400. Investigation reveals that agents paste a standard opening ("Thank you for contacting support. Your case number is...") and closing ("Please don't hesitate to reach out...") into every case. Before using AI to analyze support interactions, those 12,400 records need the boilerplate stripped. ### Three Angles of Analysis Uniqueness metrics cover three distinct concerns, each serving a different stakeholder: | Concern | Metrics | Question | Stakeholder | |---------|---------|----------|-------------| | **Duplication** | Uniqueness Rate, Distinct Count | Do we have repeated values? | Data stewards (merge candidates, dedup rules) | | **Distribution** | Entropy, Max Frequency | How is data spread across values? | Analysts and data scientists (segmentation, modeling) | | **Originality** | Boilerplate Rate, Boilerplate Records Count | Is text content genuinely original? | AI teams (training data quality, content extraction) | ## Metric Reference ### Foundation Metrics These 2 metrics form the base of every uniqueness analysis. They work across all 15 supported field types. | Metric | Type | What It Measures | |--------|------|-----------------| | Uniqueness Rate | Percentage | Share of records with non-duplicate values | | Distinct Count | Count | Total number of distinct values in the field | ### Advanced Metrics These 4 metrics go beyond "are values unique?" to analyze distribution patterns and text originality. They require the Advanced Uniqueness Analysis mode. | Metric | Type | What It Measures | |--------|------|-----------------| | Entropy | Decimal | How evenly values are distributed (Shannon entropy) | | Max Frequency | Count | Occurrence count of the single most common value | | Boilerplate Rate | Percentage | Degree of templated or repetitive content | | Boilerplate Records Count | Count | Number of records with boilerplate content | ### Field Type Coverage Different metrics apply to different field types based on what they measure. | Coverage Group | Field Types | Metrics Available | |---------------|-------------|-------------------| | All types (15) | String, TextArea, LongTextArea, Number, Currency, Percent, AutoNumber, Date, DateTime, Picklist, Email, Phone, URL, Lookup, Checkbox | Uniqueness Rate, Distinct Count | | Analysis types (9) | String, TextArea, Number, Picklist, Multiselect Picklist, Checkbox, Email, Phone, URL | Entropy, Max Frequency | | Text fields (3) | String, TextArea, Html | Boilerplate Records Count | | Long text fields (3) | TextArea, LongTextArea, Html | Boilerplate Rate | Core metrics work on all 15 field types because any field can have duplicates. Distribution metrics (Entropy, Max Frequency) work on 9 field types that produce countable frequency tables. Boilerplate metrics apply only to text fields because they detect repeated content patterns in free-text data. ## Two Analysis Modes DQS offers two uniqueness analysis modes: **Basic Uniqueness** answers the question: "Are values distinct?" It produces the 2 foundation metrics and covers the essentials for a quick duplicate detection check or baseline audit. **Advanced Uniqueness Analysis** goes deeper. It produces all 6 metrics, including distribution analysis, frequency patterns, and boilerplate detection. Use this mode when you need to understand the full picture of data distribution and text originality, not just the duplication rate. | Business Need | Recommended Mode | |---------------|-----------------| | Quick duplicate detection audit | Basic Uniqueness | | Data migration assessment | Advanced (Max Frequency catches default values, Entropy reveals skew) | | Picklist hygiene check | Advanced (Entropy + Max Frequency reveal skew and normalization needs) | | AI training data evaluation | Advanced (Boilerplate metrics assess content originality) | | Ongoing data governance | Start with Basic Uniqueness, move to Advanced for deeper analysis | ## Configuring Uniqueness DQS provides 2 configuration inputs for uniqueness. Each can be set at the global level (applies to all fields) and overridden at the individual field level. | Setting | What It Controls | |---------|-----------------| | **Case Sensitive** | Controls whether value comparison considers letter casing. When disabled (the default), "Apple" and "apple" count as the same value. When enabled, they count as two distinct values. | | **Include Blanks** | Controls whether null and blank records are counted in uniqueness calculations. When disabled (the default), blanks are excluded from evaluation. When enabled, all blank records share a single "blank" value, which can lower the uniqueness rate on fields with many empty records. | > **Tip:** Disable Case Sensitive (the default) for most fields. Enable it only when casing carries meaning, like product codes where "ABC-100" and "abc-100" are genuinely different items. ### When to Enable Include Blanks By default, DQS excludes blank and null records from uniqueness calculations. This makes sense for optional fields where blanks are expected. Enable Include Blanks when blanks themselves are the problem you want to measure. If 3,000 Contact records have no Email value, those 3,000 blanks share one "blank" value in the uniqueness calculation. This lowers the Uniqueness Rate and makes the blank problem visible in the headline metric. **Example:** You scan `Phone` on Contacts with Include Blanks disabled. Uniqueness Rate is 91%. You enable Include Blanks and re-scan. Uniqueness Rate drops to 72%. The difference reveals that a large portion of your Contact records share a common trait: no phone number. The field looked healthy when blanks were excluded, but the full picture tells a different story. ## Common Uniqueness Issues ### Duplicate Records from Bulk Imports Data migrations and list imports introduce duplicates when matching logic is insufficient. A purchased contact list creates new records for people who already exist. A legacy system export creates Accounts that overlap with current data. **Fix:** Audit imports before loading. Use DQS to establish a uniqueness baseline on key identifier fields (Email, Phone, Website) before and after each import. ### Default Values Masquerading as Data Integrations and migrations often write default values into fields. "Unknown", "N/A", or a company's own name appears on thousands of records. These inflate duplicate counts and distort distribution metrics. **Fix:** Run Advanced Uniqueness Analysis. Max Frequency reveals the dominant value. If one value appears on 85% of records, investigate whether it is real data or a default. ### Free-Text Fields with No Governance Text fields that lack picklist constraints accumulate variations over time. The `Job_Title` field on Contacts stores the same role 15 different ways. Distinct Count climbs while the actual business concept set remains small. **Fix:** Run Advanced Uniqueness Analysis on text fields you plan to standardize. Use Distinct Count and Entropy to scope the normalization effort. Convert high-value free-text fields to picklists. ### Boilerplate-Polluted Text Fields Support agents paste standard openings and closings into every case. Sales reps copy opportunity description templates. The fields are technically "unique" (different case numbers, dates), but the content is 90% identical. **Fix:** Run Advanced Uniqueness Analysis with boilerplate detection on text fields. Boilerplate Rate reveals the degree of template pollution. Address this before using these fields for AI training or analysis. ### Shared Identifiers That Look Like Duplicates Department emails (info@company.com), shared phone numbers, and company-wide fax numbers create legitimate duplicate values. Not every low Uniqueness Rate signals a problem. **Fix:** Evaluate uniqueness in context. An Email field with 78% uniqueness needs investigation. A Fax field with 40% uniqueness is expected. Set your monitoring thresholds based on what the field represents. ## Best Practices ### Choose the Right Headline by Field Type Uniqueness Rate is the right headline for identifier fields (Email, Phone, Account Name). For text content fields (Description, Notes, Comments), combine Uniqueness Rate with Boilerplate Rate to get the full picture. A field can score 99% Uniqueness Rate and still be 65% boilerplate. ### Use Distribution Metrics for Segmentation Fields For fields you use in segmentation, filtering, or reporting (Industry, Country, Lead Source), check Entropy and Max Frequency. Low entropy reveals that your "24-category" picklist is really a 2-bucket system. Max Frequency reveals default values that distort your segments. ### Track Trends Across Scans A single scan shows current state. Run scans regularly to detect new duplicate sources, measure the impact of deduplication initiatives, and identify integrations that introduce repetitive data. A field that drops from 90% to 75% uniqueness between scans has a new problem source. ### Prioritize by Business Impact Not every field needs high uniqueness. An Email field with duplicates signals a merge problem. A Country field with duplicates is normal. Focus uniqueness monitoring on fields that serve as identifiers, drive deduplication rules, or feed AI models. ### Address Root Causes Low uniqueness signals a process issue. Investigate whether users are creating records without checking for existing ones, imports lack deduplication logic, or integrations write default values. Fix the source, not just the symptom. ## Next Steps You now understand how to measure and diagnose uniqueness issues. Continue learning about the next dimension: - **In Salesforce:** [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/) - deduplicate Accounts, Contacts, and Leads - **Next:** [Timeliness](/resources/data-quality/timeliness/) - Measure data freshness and currency - **Previous:** [Validity](/resources/data-quality/validity/) - Ensure data follows expected formats - **Related:** [The Five Dimensions](/resources/data-quality/five-dimensions/) - Overview of all dimensions - **Action:** [AI Readiness Assessment](/ai-readiness/) - See your current uniqueness scores # Salesforce Data Quality Tools > Salesforce data quality tools fall into three layers: native prevention, measurement and monitoring, and specialized third-party. Match the tool to the job. Source: https://dataqualitysense.com/resources/salesforce/salesforce-data-quality-tools/ Last updated: 2026-07-23 --- > **TL;DR:** Yes, tools that improve data quality in Salesforce exist, and they fall into three layers. Native Salesforce features prevent bad data at entry. Measurement and monitoring tools like DQS show you how healthy your existing data is and whether it is improving. Specialized third-party categories handle remediation and enrichment. No single tool covers all three jobs, so match the tool to the job. ## Are There Tools That Improve Data Quality in Salesforce? Yes. The tools that improve data quality in Salesforce fall into three layers, and each does a different job. 1. **Native Salesforce features** prevent bad data as records are created and edited. 2. **Measurement and monitoring tools** scan the data already in your org, score its health, and trend that score over time. 3. **Specialized third-party categories** remediate known problems and enrich records with outside data. No single tool covers all three jobs well. A validation rule cannot tell you how bad your existing data is. A measurement tool does not merge duplicates for you. Understanding what each layer is for is how you avoid buying a tool that solves a problem you do not have. This article maps the landscape. For the step-by-step workflow that ties the layers together, see [How to Improve Data Quality in Salesforce](/resources/salesforce/improve-data-quality-in-salesforce/). ## Native Salesforce Data Quality Tools Salesforce ships five controls that improve data quality without any add-on. They share one strength and one limit. They prevent bad data at the point of entry, but they do not measure the health of data already in the org at scale, they do not trend quality over time, and rules like duplicate matching fire only on create or edit. | Native tool | What it does well | Its limit | |---|---|---| | Validation rules | Reject malformed values before save | Act only on records being edited, not the existing backlog | | Duplicate and matching rules | Block duplicate Accounts and Contacts at entry | Fire only on create or edit, not on data already loaded | | Required fields and picklists | Close completeness gaps and constrain values | Enforce structure, but do not report on historical gaps | | Flow automation | Standardize values as records change | Runs per record, with no health score or trend | | Reports and dashboards | Spot-check specific known problems | Manual, one query at a time, no composite score | ### Validation Rules Validation rules reject a value that breaks a defined format before the record saves. For example, a rule can require that a phone number matches a pattern, or that an Opportunity has an Amount above zero. They are the front line for validity. Their limit is scope: a validation rule evaluates the record in front of it, so records loaded before the rule existed keep their bad values untouched. ### Duplicate Rules and Matching Rules Matching rules define what counts as a duplicate, and duplicate rules decide whether to warn or block when a match is found. They are effective at stopping new duplicate Accounts and Contacts. The catch is timing: duplicate rules fire only when a record is created or edited. Thousands of duplicates already sitting in the org do not trigger them, so you still need a way to find and merge the existing set. ### Required Fields and Picklists Marking a field required, on the page layout or through a validation rule, closes completeness gaps at entry. Replacing a free-text field with a picklist removes an entire class of consistency problems, because users pick from controlled values instead of typing "USA", "US", and "U.S." into the same field. Both controls shape new data well. Neither reports on how many existing records already carry blanks or inconsistent values. ### Flow Automation for Standardization Flow can standardize data as records change: trimming whitespace, formatting phone numbers, or copying a value into a normalized field. This keeps new and updated records consistent. Flow runs record by record as part of a transaction, so it is a prevention and correction mechanism, not a way to score or trend the health of the whole object. ### Reports and Dashboards for Spot Checks Reports let you count records that match a condition, such as Accounts with a blank Industry. Dashboards surface those counts on a page. For a single known problem, this is a fast spot check. It does not scale into a health measure: every report is one hand-built query, there is no weighted composite score across dimensions, and nothing trends automatically as data changes. ## Measurement and Monitoring Tools Native controls answer "how do I stop bad data?" They do not answer "how bad is the data I already have, and is it getting better?" That is the job of a measurement and monitoring layer, and it is where Data Quality Sense (DQS) sits. DQS is a Salesforce-native application, delivered as a managed package, that scans any SObject in batch, either on demand or on a schedule. It measures the operational dimensions, completeness, validity, uniqueness, timeliness, and consistency, and adds AI readiness checks such as PII detection, content density, and language consistency. It rolls those results into a weighted score from 0 to 100, tracks that score as a trend, and lets you compare one scan against another to see the delta by dimension and field. What DQS produces is visibility you can act on: - A weighted **data quality score** with a field-level breakdown, so "the data is messy" becomes "completeness is 64 on Accounts, driven by a blank Industry field." - **Score trend** over time and **scan comparison**, so you can prove whether a fix worked. - **CSV violation export** for every dimension except Uniqueness, with PII values redacted as `[REDACTED]`. - **Actions on impacted records:** create Tasks or post Chatter messages so the right owner follows up. DQS detects and reports. It does not cleanse, merge, dedupe, or enrich records for you. That boundary is deliberate: measurement tells you where the problems are and how large they are, and human follow-up or a specialized tool does the fixing. For how the score itself is built, see [What is a Data Quality Score?](/resources/data-quality/what-is-a-data-quality-score/). ## Specialized Third-Party Tool Categories Once measurement shows a specific, sizeable problem, a specialized tool can do the heavy lifting. These are categories of tool, not recommendations of any product, and they complement measurement rather than replace it. You fix what you first measured. - **Deduplication and merge tools** find and consolidate the existing duplicate records that native duplicate rules never caught, then merge them in bulk. - **Data enrichment providers** fill missing firmographic or contact details by matching your records against an external data source. - **Address verification services** check and correct postal addresses against reference databases so mailing and billing data is deliverable. - **ETL and data loading tools** move, transform, and standardize records in bulk when you migrate data or correct large batches at once. Each of these does one job well. None of them tells you which job you actually need, which is why they sit downstream of measurement. ## How to Choose: Match the Tool to the Job Start from the problem, not the tool. Name what is wrong, then reach for the layer that addresses it. | Problem | Tool layer | Example | |---|---|---| | Bad data entering at creation | Native prevention | Validation rules, duplicate and matching rules | | You do not know how bad existing data is | Measurement and monitoring | A scanning tool like DQS | | Quality changes but you cannot see the trend | Measurement and monitoring | Scheduled scans with score trend | | Thousands of known duplicates to merge | Specialized third-party | Deduplication and merge tool | | Records missing firmographics | Specialized third-party | Data enrichment provider | | Addresses that fail delivery | Specialized third-party | Address verification service | Be honest about sequence. Most orgs need native rules plus a measurement layer first. Native rules keep new data clean, and measurement tells you where the existing backlog stands and whether it is improving. Add a specialized remediation or enrichment tool when the measured problem is large enough to justify the cost, not before. Buying a dedupe tool before you have measured how many duplicates you have is guessing. Want to know which layer your org needs first? Take the [AI Readiness Assessment](/ai-readiness/) to see where your Salesforce data stands, or [contact us](/contact/) to talk through your situation. ## Frequently Asked Questions ### Are there tools that improve data quality in Salesforce? Yes. They fall into three layers: native Salesforce features that prevent bad data at entry, measurement and monitoring tools that show you how healthy your existing data is, and specialized third-party tools that remediate or enrich data. Most orgs need native rules plus a measurement layer, and add specialized tools when a measured problem justifies it. ### What data quality tools are built into Salesforce? Salesforce ships validation rules, duplicate and matching rules, required fields and picklists, Flow automation for standardization, and reports and dashboards for spot checks. These controls prevent bad data as records are created and edited. They do not measure the health of data already in the org at scale or trend it over time. ### Do I need a third-party data quality tool for Salesforce? Native rules cover prevention, but they do not tell you how bad your existing data is or whether it is improving. A measurement and monitoring tool fills that gap. Specialized remediation or enrichment tools are worth adding once measurement shows a problem large enough to justify them. ### What is the difference between prevention and measurement tools? Prevention tools like validation rules stop bad data at the point of entry, but they act only on records being created or edited. Measurement tools scan the data already in your org, score its health across dimensions, and trend that score over time. You need both: prevention keeps new data clean, measurement tells you where the existing backlog stands. ## Next Steps - [How to Improve Data Quality in Salesforce](/resources/salesforce/improve-data-quality-in-salesforce/): the workflow that ties the tool layers together - [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/): the complete guide - [Salesforce Data Quality Dashboard](/resources/salesforce/salesforce-data-quality-dashboard/): the metrics worth tracking - [Data Quality KPIs](/resources/best-practices/data-quality-kpis/): the measures that prove a program is working # Uniqueness: Configuration Scenarios > Three practical walkthroughs showing how to configure DQS uniqueness analysis for different business needs. Source: https://dataqualitysense.com/resources/use-cases/uniqueness-scenarios/ Last updated: 2026-02-23 --- ## What These Scenarios Cover This page walks through three real-world configurations of DQS uniqueness analysis. Each scenario covers a specific business problem, shows the exact settings to use, and explains how to read the results. These walkthroughs build on the concepts from the main [Uniqueness](/resources/data-quality/uniqueness/) article. Read that first if you are new to uniqueness metrics, the diagnostic layers, or the difference between Basic Uniqueness and Advanced Uniqueness Analysis. ## Scenario 1: Email Deduplication Audit on Leads ### The Problem Your marketing team runs nurture campaigns through Salesforce. Open rates are declining, and the email platform reports a rising number of "duplicate sends": the same person receiving the same email twice. Your duplicate management rules catch exact-match records, but partial duplicates slip through. Two Lead records for the same person with the same email address both receive the campaign. You need a concrete number: how many Lead email addresses are shared across multiple records? ### Configuration This is a straightforward duplicate detection check. Use **Basic Uniqueness** mode on the Lead object, targeting the `Email` field. | Setting | Value | Why | |---------|-------|-----| | Analysis Mode | Basic Uniqueness | You need the duplication rate and distinct count, not distribution or boilerplate analysis | | Case Sensitive | OFF | Email addresses are case-insensitive. "John@Company.com" and "john@company.com" are the same address. | | Include Blanks | ON | A blank email on a Lead is a problem worth quantifying. Including blanks means all empty email records share one "blank" value, lowering the Uniqueness Rate and making the gap visible. | Case Sensitive OFF is the default and the correct choice for email. If two records store "jsmith@acme.com" and "JSmith@Acme.com", those are the same address. Enabling case sensitivity would count them as distinct and hide the duplicate. ### Sample Results **Foundation Metrics:** | Metric | Value | |--------|-------| | Uniqueness Rate | 74% | | Distinct Count | 18,500 | Total Lead records evaluated: 25,000. ### Reading the Results Start with the headline: 74% uniqueness. That means 26% of email addresses appear on more than one Lead record. Of 25,000 Leads, only 18,500 distinct email addresses exist. The gap of 6,500 records is shared email addresses. **What 26% duplicate emails look like in practice.** Some are legitimate: department addresses like info@company.com or sales@company.com shared across multiple contacts at the same company. Most are duplicate Leads created by different sources. A web form creates one Lead. A list import creates another. A sales rep creates a third from a business card. All three have the same email address. **Include Blanks ON reveals the full picture.** With Include Blanks enabled, Leads with no email address all share a single "blank" value. If 2,000 of the 25,000 Leads have no email, those 2,000 records count as duplicates of each other. This lowers the Uniqueness Rate compared to excluding blanks, but it gives you the honest number. Your campaign can reach 18,500 distinct addresses at best, not 25,000. **Why Basic Uniqueness is enough here.** The question is "how many emails are duplicated?" Uniqueness Rate and Distinct Count answer that question. You do not need Entropy or Rarity to decide whether to launch a deduplication project. If you later want to understand the distribution pattern (how many emails appear exactly twice vs ten times), switch to Advanced Uniqueness Analysis for the full picture. ### What to Do Next Use Distinct Count (18,500) as your real addressable audience for email campaigns. Scope a deduplication project for the records with shared emails. Start by exporting Leads grouped by email address, then merge or delete the duplicates. After cleanup, run the scan again and track Uniqueness Rate over time. If it drops between scans, a new duplicate source has appeared: a list import, a web form without dedup logic, or an integration creating records without checking for existing ones. --- ## Scenario 2: Industry Field Distribution on Accounts ### The Problem Your data team built an Account segmentation model that groups customers by Industry. The model uses 24 industry picklist values to create targeted segments. But the segments are uneven: two segments contain 70% of all Accounts, while the remaining 22 segments split the other 30%. The data science team suspects the Industry field has a distribution problem, not a model problem. You need to confirm whether the field's value distribution is genuinely skewed and identify the dominant values. ### Configuration Use **Advanced Uniqueness Analysis** mode on the Account object, targeting the `Industry` field. You need distribution metrics (Entropy, Max Frequency, Rarity) to answer questions about how values are spread. | Setting | Value | Why | |---------|-------|-----| | Analysis Mode | Advanced Uniqueness Analysis | You need Entropy, Max Frequency, and Rarity for distribution analysis | | Case Sensitive | OFF | Picklist values are controlled. Case sensitivity is not relevant here. | | Include Blanks | OFF | Blank Industry values are a completeness problem, not a uniqueness problem. Exclude them to focus on the distribution of populated values. | Include Blanks OFF is the right choice for this scenario. You are analyzing how the existing data is distributed across categories. Adding blanks into the calculation would distort the distribution metrics without answering your segmentation question. If you want to know how many Accounts have no Industry value, run a [completeness analysis](/resources/use-cases/completeness-scenarios/) instead. ### Sample Results **Foundation Metrics:** | Metric | Value | |--------|-------| | Uniqueness Rate | 0.16% | | Distinct Count | 24 | **Advanced Metrics:** | Metric | Value | |--------|-------| | Entropy | 2.18 | | Max Frequency | 5,200 | | Rarity | 0% | Total Account records evaluated: 15,000. ### Reading the Results **Uniqueness Rate (0.16%) is expected and irrelevant here.** Industry is a picklist with 24 values across 15,000 records. Almost every value is shared by hundreds of records. A low Uniqueness Rate on a picklist field is normal. This metric is not the point of this analysis. **Distinct Count (24) confirms your picklist is intact.** All 24 configured values appear in the data. No rogue free-text entries exist. The data is clean from a consistency standpoint. **Entropy (2.18) reveals the skew.** Maximum entropy for 24 distinct values is log2(24) = 4.58. Your actual entropy is 2.18. The normalized score is 2.18 / 4.58 = 0.48. That falls well below the 0.7 threshold for "dominated" distributions. A few values hold most of the records. Your data science team's suspicion is confirmed: the segmentation problem is in the data, not the model. **How to interpret normalized entropy:** | Normalized (actual / max) | Interpretation | |---------------------------|----------------| | 0.9 or above | Even distribution: values spread uniformly | | 0.7 to 0.9 | Moderate skew: some values appear more than others | | Below 0.7 | Dominated: a few values hold most of the records | Your score of 0.48 is in the "dominated" range. **Max Frequency (5,200) identifies the dominant value.** One industry value appears on 5,200 of 15,000 records, or 34.7% of the dataset. A quick check reveals it is "Technology." The second most common value is likely responsible for most of the remaining concentration. Together, two values account for the 70% clustering your team observed. **Rarity (0%) confirms there is no long tail.** Every one of the 24 distinct values appears more than once. No singleton values exist. This is expected for a well-controlled picklist field. On a free-text field, you would want to see Rarity to catch typos and one-off entries, but on a picklist, 0% Rarity is normal. **The segmentation verdict:** Your 24-category model is really a 2-category system. "Technology" and one other industry dominate the dataset. The remaining 22 categories share 30% of records, giving each category an average of about 200 records. Some segments are too small for meaningful analysis. ### What to Do Next Present Entropy and Max Frequency to your data science team. The numbers confirm the distribution problem. Two options: (1) Redesign the segmentation model to use fewer, broader categories that reflect the actual distribution. Group the 22 smaller industries into 4-5 macro-categories. (2) Enrich the Industry data. If the concentration in "Technology" is inflated because reps default to it during record creation, investigate whether a large portion of those 5,200 records belong to a different industry. Run a periodic scan and track Entropy over time. As you correct misclassified records, Entropy rises toward a healthier distribution. --- ## Scenario 3: Case Description Boilerplate Detection for AI Readiness ### The Problem Your company is evaluating AI-powered case summarization for the support team. The AI tool reads the `Description` field on Cases and generates a summary for the next agent who picks up the case. Before investing, you need to assess whether your case descriptions contain enough original content for the AI to produce useful summaries. The field is populated on 95% of cases, so completeness is not the concern. The concern is that support agents copy-paste standard templates into every case. ### Configuration Use **Advanced Uniqueness Analysis** mode on the Case object, targeting the `Description` field. You need the boilerplate metrics to evaluate content originality. | Setting | Value | Why | |---------|-------|-----| | Analysis Mode | Advanced Uniqueness Analysis | Enables boilerplate detection (Boilerplate Rate, Boilerplate Percentage, Boilerplate Records Count) | | Case Sensitive | OFF | Template detection does not depend on casing | | Include Blanks | OFF | Empty descriptions are a completeness problem. Exclude them to focus on the quality of populated content. | Include Blanks OFF makes sense here because you are evaluating the content that exists, not counting the content that is missing. The 5% of cases with empty descriptions are already handled by your completeness analysis. ### Sample Results **Foundation Metrics:** | Metric | Value | |--------|-------| | Uniqueness Rate | 97% | | Distinct Count | 29,100 | **Advanced Metrics:** | Metric | Value | |--------|-------| | Entropy | 14.8 | | Boilerplate Rate | 42% | | Boilerplate Percentage | 68% | | Boilerplate Records Count | 20,400 | Total Case records evaluated: 30,000. ### Reading the Results **Uniqueness Rate (97%) looks healthy, but it is misleading.** Nearly every case description is technically different because each contains unique case numbers, customer names, and dates. The field passes a basic duplication check. But "unique" does not mean "original." **Boilerplate Rate (42%) tells the real story.** 42% of the text content across case descriptions is repetitive or templated. Agents paste standard openings ("Thank you for contacting support. Your case number is..."), standard closings ("Please do not hesitate to reach out if you have further questions."), and standard diagnostic checklists into every case. The case-specific details fill the middle, but nearly half of every description is copy-paste content. **Boilerplate Percentage (68%) shows how widespread the problem is.** 68% of case records contain templated text. That is 20,400 out of 30,000 cases. The boilerplate is not limited to a few agents or one team. It is a systemic pattern embedded in your support process. **Boilerplate Records Count (20,400) is your scope number.** If you need to estimate the effort to clean up templates before feeding data to the AI, this is the starting point. 20,400 records contain content that the AI will learn as patterns, but those patterns are your templates, not your customer issues. **The AI readiness verdict:** The AI summarization tool will process templated content on 68% of cases. It will learn to summarize your templates, not your customer problems. On the 32% of cases with original content, the AI will perform well. On the 68% with boilerplate, the summaries will echo back the standard phrases agents already know by heart. **Entropy (14.8) is high, confirming that the text is diverse at the character level.** This aligns with the 97% Uniqueness Rate: each description is different. Entropy is not the relevant metric here because the duplication problem is not identical values. The problem is repeated content patterns within otherwise unique text. That is exactly what the boilerplate metrics are designed to catch. ### What to Do Next Present Boilerplate Rate (42%) and Boilerplate Percentage (68%) to your AI project stakeholders. The numbers make the case: the AI project needs a content quality improvement phase before deployment. Three approaches to reduce boilerplate: - Remove the templates. If agents are pasting standard openings and closings, build those elements into the case layout or a screen flow so they do not pollute the description field. The description then captures only case-specific information. - Train agents on effective descriptions. Share examples of high-quality descriptions (from the 32% that are original) and explain why template-free entries produce better AI summaries. - Strip boilerplate from historical data. Before feeding existing cases to the AI, run a text processing job that removes known template patterns from the description field. Run the scan again after each improvement cycle. Track Boilerplate Rate and Boilerplate Percentage as your primary AI readiness metrics for this field. Your target: Boilerplate Percentage below 30% and Boilerplate Rate below 20% before deploying the AI summarization tool. --- ## Choosing Your Configuration Use this table to pick the right starting point for your uniqueness analysis. | If You Need To... | Start With | Key Settings | |--------------------|------------|--------------| | Audit duplicate values on an identifier field (Email, Phone, Account Name) | Basic Uniqueness | Case Sensitive: OFF, Include Blanks: ON to reveal blank volume | | Size a deduplication project with a concrete record count | Basic Uniqueness | Use Distinct Count to calculate the gap between total records and unique values | | Analyze value distribution on a picklist or categorical field | Advanced Uniqueness Analysis | Review Entropy (normalized against max), Max Frequency, and Rarity | | Detect templated content in text fields before an AI project | Advanced Uniqueness Analysis | Review Boilerplate Rate, Boilerplate Percentage, and Boilerplate Records Count | | Determine whether a "healthy" uniqueness score hides deeper problems | Advanced Uniqueness Analysis | Pair Uniqueness Rate with Entropy (for distribution skew) or Boilerplate Rate (for content originality) | For a full reference of all 8 uniqueness metrics, the three diagnostic layers, and configuration details, return to the main [Uniqueness](/resources/data-quality/uniqueness/) article. Ready to measure your own data quality? Take the [AI Readiness Assessment](/ai-readiness/) to see your uniqueness scores and more. # Agentforce Data Quality: Preparing Salesforce Data for AI > Improve Agentforce data quality and data readiness. A practical guide to preparing your Salesforce data for AI agents with DQS — completeness, consistency, and PII detection. Source: https://dataqualitysense.com/resources/ai-readiness/agentforce-preparation/ Last updated: 2026-07-15 --- Agentforce agents are only as reliable as the Salesforce data behind them. Agentforce data readiness comes down to data quality — complete records, consistent values, and no PII in the fields your agents read. This guide shows how to assess and prepare your Salesforce data for AI, phase by phase. ## What Is Agentforce? Agentforce is Salesforce's AI platform for creating autonomous agents. These agents retrieve information from your Salesforce records, generate responses based on your data, and take actions on behalf of users. The quality of your data determines the quality of agent behavior. Agents work with whatever they find. If the data is incomplete, inconsistent, or contains PII, the agent produces incomplete, inconsistent, or non-compliant outputs. Most organizations start further from ready than they assume. In the [Precisely and Drexel University LeBow College of Business data integrity survey](https://www.precisely.com/press-release/new-global-research-points-to-lack-of-data-quality-and-governance-as-major-obstacles-to-ai-readiness), only 12% of organizations reported that their data is of sufficient quality and accessibility for effective AI implementation — while 64% named data quality their top data integrity challenge. Preparation is what closes that gap. ## Why Data Quality Matters for Agentforce Three data problems create three distinct failures in Agentforce. **Incomplete data produces vague responses.** When Agentforce retrieves a Case record with an empty Description, it has nothing to work with. The agent generates a generic reply because there is no context to draw from. Completeness Rate tells you how many records have this problem across every field in scope. **Inconsistent data produces contradictory answers.** When the Country field contains "US", "USA", "United States", and "U.S.A.", the agent treats them as four different values. A customer asking about US operations gets a different answer depending on which record the agent retrieves. Conformance Rate reveals how fragmented your data is. **PII in text fields creates compliance exposure.** When an agent retrieves a Case comment containing a Social Security Number, that PII enters the AI context. The agent can surface it in a response. PII Exposure Rate shows how widespread this risk is across your text fields. ## The Agentforce Data Readiness Timeline Plan your Agentforce data readiness in four phases. ### Phase 1: Assessment (3+ Months Before) Run DQS scans across all objects Agentforce will access. Measure baseline metrics for each dimension. | Dimension | Key Metric | What It Tells You | |-----------|-----------|-------------------| | Completeness | Completeness Rate | Percentage of fields with data | | Consistency | Conformance Rate | Percentage matching expected values | | Validity | Validity Rate | Percentage passing format rules | | Timeliness | Timeliness Rate | Percentage of current records | | Uniqueness | Duplicate Rate | Percentage of duplicate records | | PII Detection | PII Exposure Rate | Percentage of records containing PII | Document these baselines. You need them for comparison after remediation. ### Phase 2: Remediation (2 Months Before) Work through dimensions in priority order. PII first, then the dimensions that affect AI context quality. **1. PII (Week 1-2).** Remediate SSN and credit card findings first. Use the Critical preset scan to isolate financial PII. Review matches, then mask, delete, or exclude confirmed findings. Rerun the scan to validate cleanup. **2. Completeness (Week 2-4).** Focus on fields Agentforce will use for responses: Description, Comments, Notes. Missing data means missing AI context. Target the fields with the lowest Completeness Rate first. **3. Consistency (Week 3-5).** Standardize picklist and reference fields. Use Import from Field to discover existing variants, then define your canonical values and normalize. The fewer variants per field, the more reliable the agent's responses. **4. Validity (Week 4-6).** Fix format issues on structured fields (email, phone, dates). Invalid formats create unreliable data for AI retrieval. Focus on fields where Validity Rate is below 90%. **5. Timeliness and Uniqueness (Week 5-8).** Address stale records and duplicates. Old data teaches agents outdated patterns. Duplicates create contradictory responses when the agent retrieves different versions of the same record. ### Phase 3: Validation (1 Month Before) Rerun all DQS scans. Compare results against Phase 1 baselines. | Metric | Baseline | Post-Remediation | Target | |--------|----------|------------------|--------| | Completeness Rate (key fields) | ___% | ___% | 85%+ | | Conformance Rate (picklists) | ___% | ___% | 90%+ | | Validity Rate (structured fields) | ___% | ___% | 90%+ | | PII Exposure Rate | ___% | ___% | Below 1% | Test agent responses on remediated data. Verify that agents return accurate, appropriate outputs and that no PII appears in generated content. Get compliance team sign-off before deployment. ### Phase 4: Monitoring (Ongoing) Schedule recurring DQS scans. Data quality degrades as users enter new records, so one-time remediation is not enough. Suggested cadence: | Scan | Frequency | Objects | |------|-----------|---------| | PII Detection | Weekly | Cases, Leads (high-volume text fields) | | Completeness + Consistency | Monthly | All objects in Agentforce scope | | Full scan (all dimensions) | Quarterly | Entire org | Track metric trends over time. Regular scanning catches regression early, before it affects agent performance. For a field-level view of which objects to clean first, see the [Salesforce data cleanup guide for Agentforce](/resources/ai-readiness/salesforce-data-cleanup-for-agentforce/). If agents are already live and giving wrong answers, start with the [data quality root causes](/resources/ai-readiness/why-agentforce-agents-fail/) instead. ## Pre-Deployment Checklist **Data Quality** - [ ] All objects in Agentforce scope scanned with DQS - [ ] Completeness Rate above 85% on fields Agentforce uses - [ ] Conformance Rate above 90% on picklist and reference fields - [ ] Validity Rate above 90% on structured fields (email, phone, date) **PII Safety** - [ ] PII Exposure Rate below 1% on text fields Agentforce accesses - [ ] Zero SSN or credit card matches on Case Description and Comments - [ ] Per-field pattern overrides configured for expected-content fields **Operations** - [ ] Recurring scan schedule configured - [ ] Baseline metrics documented for trend tracking - [ ] Remediation ownership assigned per dimension ## Common Pitfalls **1. Deploying without assessment.** Run DQS scans before any deployment planning. Most orgs discover issues they did not expect. A 15-minute scan reveals problems that take months to find manually. **2. Underestimating PII exposure.** PII hides in Description, Notes, and Comments fields where users paste customer communications. Email-to-case captures SSNs and credit card numbers from incoming messages. Scan all text fields, not dedicated PII fields alone. **3. One-time remediation.** Data quality degrades as users enter new records. A clean dataset today accumulates new issues within weeks. Schedule recurring scans and monitor metric trends to catch regression before it reaches your agents. ## Next Steps - [Agentforce Readiness](/resources/ai-readiness/agentforce-readiness/): The wider org assessment this data work sits inside - [Agentforce Data Readiness Checklist](/resources/ai-readiness/agentforce-data-readiness-checklist/): Confirm every item before you deploy - [Why Agentforce Agents Give Wrong Answers](/resources/ai-readiness/why-agentforce-agents-fail/): Map agent failures to data root causes - [Agentforce and PII](/resources/ai-readiness/agentforce-pii-compliance/): Protect sensitive data before AI deployment - [Salesforce Data Cleanup for Agentforce](/resources/ai-readiness/salesforce-data-cleanup-for-agentforce/): Object-by-object field guide - [Agentforce Data Quality FAQ](/resources/ai-readiness/agentforce-data-quality-faq/): Ten questions answered before you deploy - [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/): the complete guide to AI-ready Salesforce data - [PII Detection](/resources/ai-readiness/pii-detection/): Configure PII scanning for Agentforce data - [Completeness](/resources/data-quality/completeness/): Ensure fields have data for AI to work with - [Consistency](/resources/data-quality/consistency/): Standardize values AI will retrieve - [The Five Dimensions](/resources/data-quality/five-dimensions/): Full overview of all data quality dimensions - [AI Readiness Assessment](/ai-readiness/): Get your current readiness score # Timeliness > All 6 timeliness metrics DQS measures, the diagnostic flow for finding stale and anomalous dates, and how to configure freshness analysis. Source: https://dataqualitysense.com/resources/data-quality/timeliness/ Last updated: 2026-07-15 --- ## What is Timeliness? Timeliness measures whether your date values are current enough for their intended use. A date field is timely when it falls within your acceptable freshness window. A date field is stale when it sits beyond that window, meaning the data no longer reflects present reality. Every date field in your CRM carries a time-based expectation. A `LastActivityDate` that is 18 months old signals a dead lead. A `Contract_End_Date__c` set to 2099 is a placeholder, not a real deadline. A `Date_of_Birth__c` in the future is a data entry error. Timeliness analysis catches all of these. Staleness accumulates faster than most teams expect. B2B contact data decays at roughly 2.1% per month — about 22.5% per year — as people change jobs, companies merge, and contact details go dead, according to [industry research on data decay compiled by ZoomInfo](https://pipeline.zoominfo.com/marketing/b2b-data-decay). A dataset that was clean at import drifts out of date on its own, which is why timeliness needs a recurring measurement, not a one-time cleanup. ``` Freshness Rate = (Records with Date in Freshness Window / Total Records) x 100 ``` If 659 of 1,000 records have a `Last_Certification_Date__c` within the last 90 days, your freshness rate is 65.9%. The remaining 34.1% are either stale, null, or future-dated. This single number tells you how current a field is across your dataset. ## Why Timeliness Matters ### Reporting Stale dates distort your analytics. When 30% of your Opportunity `CloseDate` values are in the past on open deals, your pipeline reports show deals that are stuck, ignored, or already lost but never updated. Forecasts built on these dates mislead leadership. ### Automation Salesforce automation depends on date values. A renewal workflow that triggers 30 days before `Contract_End_Date__c` fails when the date is five years old. An SLA escalation that fires on `Due_Date__c` triggers false alarms when the date was never updated after resolution. ### AI and Agentforce AI models treat your date values as current truth. Agentforce uses dates to prioritize actions, schedule follow-ups, and assess urgency. When your dates are stale, the model recommends contacting leads who left two years ago, flags contracts that were renewed months ago, and misses the ones that actually need attention. | System | Timeliness Impact | |--------|-------------------| | Reports | Stale close dates skew pipeline and forecast accuracy | | Workflows | Outdated dates trigger false or missed automation | | Duplicate Rules | Stale modification dates make recency-based matching unreliable | | Agentforce | Old dates produce outdated prioritization and recommendations | ## How DQS Measures Timeliness DQS produces 6 timeliness metrics organized around a diagnostic question: **"Is the data current, how old is it, and are there dates that do not make sense?"** Think of these metrics as a diagnostic flow. Each step builds on the previous one. ### Step 1: Is the Data Current? **Freshness Rate** is the headline metric. It calculates the percentage of records where the date field value falls within your configured freshness window (for example, the last 90 days). This is the number you put on a dashboard. You run a scan on the `LastActivityDate` field for Opportunities with a 30-day freshness window. Freshness Rate comes back at 41%. That means 59% of your open Opportunities have had no activity in the last month. Pipeline reviews, forecast accuracy, and sales coaching are all working with stale signals. **Staleness Rate** quantifies the problem side. It measures the percentage of records where the date field is null or older than the freshness window. Future-dated records are excluded from staleness because they are a different type of problem (captured by Future Rate). **Example:** `Contract_End_Date__c` on Accounts shows 28% Staleness Rate with a 365-day window. Nearly a third of your contracts show end dates more than a year in the past. These are either expired contracts still marked active, or contracts that were renewed but never updated. Either way, your renewal pipeline is inaccurate. ### The Three-Way Decomposition Every record falls into exactly one of three categories. The rates always sum to 100%: | Category | Definition | Example (90-day window) | |----------|-----------|------------------------| | Fresh | Date within the freshness window | 65.9% | | Stale | Null or past beyond the window | 32.6% | | Future | Date after today | 1.5% | | **Total** | | **100.0%** | This decomposition gives each category a distinct meaning. A stakeholder asking "what percentage is stale?" gets a number that means "outdated or missing," not "outdated or missing or impossibly future-dated." ### Step 2: How Old Is It? Freshness Rate is binary: a record is either fresh or stale. **Average Age** adds nuance. Average Age calculates the mean number of days between each past-dated record's value and today, divided by total records. Nulls and future dates contribute 0 to the sum but are counted in the denominator. Two fields can both show 60% freshness, but one has an average age of 15 days (mostly recent, a few outliers) while the other has an average of 90 days (staleness spread evenly). The remediation strategy differs. A field with a low average age needs targeted cleanup of a few old records. A field with a high average age needs a broader refresh effort. **Example:** `Last_Contacted_Date__c` on Leads has 55% freshness (30-day window) and an average age of 45 days. The staleness is not severe, as most stale records sit slightly outside the window. A quick outreach campaign can move the freshness rate significantly. ### Step 3: Are There Anomalies? Two metrics catch dates that do not belong. **Future Rate** measures the percentage of records where the date value is in the future. For historical date fields like `Created Date`, `Last Modified Date`, or `Date_of_Birth__c`, future dates are almost always errors: timezone issues, data entry mistakes, or placeholder values like 2099-12-31. **Example:** `Date_of_Birth__c` on Contacts shows a Future Rate of 0.8%. That is 400 records out of 50,000 with birth dates in the future. These break age-based segmentation, compliance checks, and marketing campaigns that filter by age group. **Operational Range Rate** measures the percentage of records where the date value falls within a defined operational boundary (a minimum date and maximum date you configure). Dates outside this range are flagged as anomalies. Some date fields have natural boundaries. A `Hire_Date__c` before 1950 is wrong. A `Project_Deadline__c` set to 2099 is a placeholder. Operational Range Rate catches these outliers that pass basic freshness checks because the field is populated, just with unrealistic values. **Example:** You set an operational range of 365 days in the past to 0 days in the future on `Close_Date__c` for Opportunities. Operational Range Rate is 84%. Investigation reveals 200 records with close dates from 2005 (migrated from a legacy system) and 50 records with close dates in 2099 (placeholder from an integration). Both groups distort your pipeline analytics. > **Note:** When your operational range maximum is set to 0 (today), all future dates are also out of range. Future Rate and Operational Range Rate overlap on future-dated records. They are complementary views, not additive. ### Step 4: Are Deadlines Being Met? **Overdue Rate** measures the percentage of records where the date field is past today's date, with an optional grace period. It is purpose-built for deadline-type fields where "past due" has business meaning. Overdue Rate differs from Staleness Rate in two ways. First, it adds a configurable grace period buffer (for example, 14 days) so the scan does not flag records as overdue the day after the deadline. Second, it targets fields like renewal dates, certification dates, and contract end dates where a past date means action is needed. **Example:** `Renewal_Date__c` on Contracts with a 30-day grace period shows an Overdue Rate of 12%. That means 12% of contracts are more than 30 days past their renewal date without being renewed or closed. These are revenue leakage risks. ### "Last Event" vs "Deadline" Fields Not every timeliness metric fits every field. Overdue Rate reads tautologically high on "last event" fields because most events are, by definition, in the past. Choose your headline metric based on the field type: | Field Type | Example Fields | Headline Metric | Why | |-----------|---------------|-----------------|-----| | Last event | `LastActivityDate`, `Last_Certification_Date__c` | Freshness Rate | "When was this last updated?" is the relevant question | | Deadline | `Renewal_Date__c`, `Contract_End_Date__c`, `Due_Date__c` | Overdue Rate | "Is this past due?" is the relevant question | ### Why All Metrics Use Total Records All 6 timeliness metrics use the same denominator: total records, including nulls. This keeps every metric comparable within the same scan. If one metric excluded nulls and another included them, a stakeholder comparing "freshness 66% vs future 1.6%" would be comparing two different universes without knowing it. When Null As Stale is enabled, null records count against freshness (they are in the denominator but not the freshness numerator). When disabled, nulls are excluded from both numerator and denominator, and freshness is calculated over populated records only. ## Metric Reference ### Foundation Metrics These 2 metrics form the base of every timeliness analysis. They answer the core question: is this data current? | Metric | Type | What It Measures | |--------|------|-----------------| | Freshness Rate | Percentage | Share of records with dates within the freshness window | | Staleness Rate | Percentage | Share of records with null or expired dates beyond the window | ### Advanced Metrics These 4 metrics go beyond "is it current?" to analyze age distribution, date anomalies, and deadline compliance. They require the Advanced Data Freshness analysis mode. | Metric | Type | What It Measures | |--------|------|-----------------| | Average Age | Days | Mean age of date values across all records | | Future Rate | Percentage | Share of records with dates after today | | Overdue Rate | Percentage | Share of records past due (with optional grace period) | | Operational Range Rate | Percentage | Share of records with dates inside the configured boundary | ### Field Type Coverage DQS measures timeliness on Date and DateTime fields only. Timeliness is inherently temporal. Unlike completeness (which works on all 20+ field types), timeliness applies only to fields that represent points in time. | Metric | Date | DateTime | |--------|:----:|:--------:| | Freshness Rate | X | X | | Staleness Rate | X | X | | Average Age | X | X | | Future Rate | X | X | | Overdue Rate | X | X | | Operational Range Rate | X | X | ## Two Analysis Modes DQS offers two timeliness analysis modes: **Data Freshness** answers the question: "Is the data current or stale?" It produces the 2 foundation metrics and covers the essentials for any org with date-sensitive processes. Use this mode for quick hygiene checks and baseline audits. **Advanced Data Freshness** goes deeper. It produces all 6 metrics, including average age, future-date anomalies, overdue tracking, and operational range compliance. Use this mode when you need to understand the full picture of date quality, not just the freshness score. | Business Need | Recommended Mode | |---------------|-----------------| | Quick date hygiene check or baseline audit | Data Freshness | | Data migration assessment | Advanced (operational range catches legacy date anomalies) | | SLA or deadline monitoring | Advanced (overdue tracking with grace periods) | | Pipeline accuracy audit | Advanced (future rate + operational range catch placeholder dates) | | Ongoing data governance | Start with Data Freshness, move to Advanced when date quality is a priority | ## Configuring Timeliness DQS provides five configuration inputs for timeliness. Each can be set at the global level (applies to all fields) and overridden at the individual field level. | Setting | What It Controls | |---------|-----------------| | **Freshness Window** | The number of days a date is considered "fresh." A window of 90 means any date within the last 90 days counts as fresh. Required: you must set this before running a scan. Range: 1 to 9,999 days. | | **Null As Stale** | When enabled, null date values count as stale (they are in the denominator and penalize freshness). When disabled, nulls are excluded from evaluation. Default: disabled. | | **Overdue Tracking** | Enables the Overdue Rate metric. When disabled, Overdue Rate is not computed. Default: disabled. | | **Grace Period** | The number of days after a deadline before DQS flags a record as overdue. Visible only when Overdue Tracking is enabled. Range: 0 to 365 days. | | **Operational Range** | Defines the minimum and maximum date boundaries as days in the past and days in the future from today. DQS converts these to absolute dates at scan time. Visible only when enabled. | > **Tip:** Different date fields have different freshness expectations. A `LastActivityDate` on open Opportunities needs a 30-day window. A `Contract_End_Date__c` on Accounts needs 365 days. Use field-level overrides to set the right window for each field. ### Choosing Your Freshness Window The freshness window is the most important configuration decision for timeliness. Here are starting points by field type: | Date Field | Suggested Window | Rationale | |------------|-----------------|-----------| | LastActivityDate | 30 days | Active deals need recent engagement | | LastModifiedDate | 90 days | Records touched within a quarter are generally current | | Contract_End_Date__c | 365 days | Contracts renew annually | | Last_Verified_Date__c | 90-180 days | Verification cadence varies by org | | Created Date | Not applicable | Creation date never changes; use completeness, not timeliness | ### Operational Range Configuration Operational range uses "days in past" and "days in future" instead of absolute dates. DQS converts these to absolute dates at scan time using today's date. **Example:** You set 365 days in the past and 0 days in the future. On February 22, 2026, DQS converts this to the range February 22, 2025 through February 22, 2026. Any date before February 22, 2025 or after today is out of range. This means the range shifts forward each day. A record that is in range today can fall out of range tomorrow as the window moves. ## Common Timeliness Issues ### Stale Activity Dates on Open Opportunities Sales reps stop updating Opportunities but leave them in an "Open" stage. The `LastActivityDate` ages silently. Your pipeline reports show active deals, but the dates reveal that nobody has touched them in months. **Fix:** Set a 30-day freshness window on `LastActivityDate` for open Opportunities. Use the Staleness Rate to scope how many deals need follow-up or stage correction. ### Placeholder Future Dates Integrations and bulk imports often use placeholder dates like 2099-12-31 for fields that require a value. These placeholders look like populated data but distort any time-based analysis. **Fix:** Use Future Rate to identify records with dates after today. Use Operational Range Rate to catch both far-future placeholders and ancient legacy dates in a single metric. ### Expired Contracts Never Updated Contracts renew, but the `Contract_End_Date__c` never gets updated to the new expiration. Your system shows expired contracts alongside active ones with no way to tell the difference without checking dates. **Fix:** Enable Overdue Tracking with a grace period that matches your renewal cycle (for example, 30 days). Overdue Rate shows you exactly how many contracts are past due and unrenewed. ### Null Dates Hiding Staleness When Null As Stale is disabled (the default), null dates are excluded from evaluation entirely. If 20% of your records have null dates, your Freshness Rate is calculated over only the remaining 80%. This can make your numbers look healthier than they are. **Fix:** Enable Null As Stale if null dates represent missing data that needs attention. This includes records where no activity has ever occurred or fields that were never populated during migration. ## Best Practices ### Choose the Right Headline Metric Freshness Rate is the right headline for "last event" fields (when was this last updated?). Overdue Rate is the right headline for deadline fields (is this past due?). Presenting Overdue Rate on a `LastActivityDate` produces a misleadingly high number because most activities are, by nature, in the past. ### Set Field-Specific Windows A single freshness window across all date fields misses the point. Activity dates need tight windows (30 days). Contract dates need wider windows (365 days). Certification dates depend on your industry's renewal cycle. Use field-level overrides to match each field's business context. ### Use Average Age to Plan Remediation Freshness Rate tells you how big the problem is. Average Age tells you how bad. A field with 40% staleness and an average age of 45 days needs a quick outreach campaign. A field with 40% staleness and an average age of 400 days needs a data enrichment project. Same percentage, different fix. ### Track Trends Across Scans A single scan shows current state. Run scans regularly to detect freshness degradation, measure the impact of cleanup initiatives, and identify data sources that introduce stale records. A field that drops from 80% to 60% freshness between scans has a new problem source. ### Combine Timeliness with Completeness A date field can be 95% complete but only 50% fresh. Completeness tells you the field has a value. Timeliness tells you whether that value is current. Run both dimensions on your date fields to get the full picture. ## Next Steps You now understand how to measure and diagnose date freshness issues. Continue learning about the next dimension: - **In Salesforce:** [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/) - keep Salesforce records fresh and current - **Next:** [Consistency](/resources/data-quality/consistency/) - Ensure uniform data standardization - **Previous:** [Uniqueness](/resources/data-quality/uniqueness/) - Detect and prevent duplicates - **Related:** [The Five Dimensions](/resources/data-quality/five-dimensions/) - Overview of all dimensions - **Action:** [AI Readiness Assessment](/ai-readiness/) - See your current timeliness scores # Who Owns Data Quality in Salesforce? > Nobody owns Salesforce data quality by default. A practical ownership model: one accountable owner, named stewards per object, and producers held to entry standards. Source: https://dataqualitysense.com/resources/salesforce/who-owns-data-quality-in-salesforce/ Last updated: 2026-07-23 --- Ask three people who owns data quality in your Salesforce org and you will usually get three answers: "the admin," "sales ops," and "well, everyone, really." All three are wrong in the same way — they describe who *touches* the data, not who is *accountable* for its state. And data without an accountable owner degrades on schedule: records go stale at roughly [2.1% per month](https://pipeline.zoominfo.com/marketing/b2b-data-decay), duplicates accumulate, and every fix is a one-off favor rather than part of a program. This guide lays out the ownership candidates, why the default arrangements fail, and a working model you can put in place this quarter. ## Why Nobody Owns It by Default Salesforce data quality falls into an organizational gap because every plausible owner has a reason it is not their job: - **Sales reps** are measured on pipeline and quota, not field completeness. Every minute spent fixing records is a minute not selling. - **The Salesforce admin** controls the mechanisms — rules, layouts, automations — but has no authority over business definitions or rep behavior. - **Marketing** cares about lead data until handoff, then inherits whatever sales writes back. - **Leadership** consumes reports built on the data but rarely sees the record-level rot until a forecast misses. The result is a commons problem: everyone benefits from clean data, everyone contributes to its decay, and no one is answerable for the trend. ## The Candidates, Honestly Assessed | Candidate | What they can own | What they cannot | |---|---|---| | Salesforce admin | Controls: validation rules, duplicate rules, layouts, integration hygiene | Business definitions, priorities, rep behavior | | RevOps / Sales Ops | The overall program: standards, priorities, reporting, cadence | Hands-on config in every org; domain detail for service or marketing data | | Data steward (per object/domain) | What "good" means for their object; triage of issues found there | Org-wide priorities and tooling | | Leadership | Sponsorship: making quality a stated priority with resourcing | Anything operational | | "Everyone" | Meeting entry standards on records they create | Accountability — shared ownership is no ownership | The pattern worth noticing: no single role can carry the whole thing. Admins have the tools but not the mandate. RevOps has the mandate but not the domain detail. That is why the answer is a small structure, not a name. ## A Working Ownership Model The model that holds up in practice has three layers and fits on one slide: 1. **One accountable owner.** A single named person answers for the state of CRM data and its trend. In most mid-size orgs this is the RevOps lead; in larger orgs, a data governance lead. Their job is not to fix records — it is to set standards, prioritize, and report the score to leadership on a fixed cadence. 2. **Named stewards per object or domain.** The person who knows what a complete Account looks like is rarely the person who knows the same for Cases. Assign a steward for each core object — Accounts, Contacts, Leads, Opportunities, and whatever your org lives on. Stewards define field-level standards and triage issues in their area. 3. **Producers held to entry standards.** Everyone who creates or edits records — reps, SDRs, support agents, integrations — is responsible for meeting the standards at entry. Not for the org-wide score; for their own records. This is enforced by [prevention controls](/resources/salesforce/improve-data-quality-in-salesforce/), not memos. The Salesforce admin sits alongside this structure as the implementer: stewards decide *what* the rules should be, the admin builds them. ### The RACI, Compressed | Activity | Accountable | Responsible | Consulted | Informed | |---|---|---|---|---| | Set field-level standards | Owner | Stewards | Admin, teams | All producers | | Implement controls | Owner | Admin | Stewards | Producers | | Fix existing backlog | Owner | Stewards + admin | Teams | Leadership | | Meet standards at entry | Owner | Every producer | — | — | | Report the trend | Owner | Owner | Stewards | Leadership | ## Making Ownership Operational An ownership chart changes nothing on its own. Three mechanisms turn it into behavior: - **A number someone reports.** The owner needs a [Data Quality Score](/resources/data-quality/what-is-a-data-quality-score/) they present on a recurring basis — monthly to leadership, weekly within RevOps. What gets reported gets resourced. Without a number, ownership is a vibe. - **Standards written down per object.** One page per core object: which fields are required, which formats are enforced, what freshness means. Stewards own these pages. Vague standards produce vague data. - **A feedback loop to producers.** When a team's records consistently fail standards, the steward raises it with that team's manager — with field-level evidence, not accusations. Most entry problems are process problems (a missing picklist, an unclear stage definition) and disappear once named. Start small: one owner, stewards for your two worst objects, standards for the ten fields that drive revenue reporting. Expand after the first quarter of trend data. A program that starts with a 40-page governance framework usually ends there; if you want the fuller structure later, see [Building a Data Governance Framework](/resources/best-practices/data-governance-framework/). ## How DQS Helps Ownership needs evidence, and evidence is what Data Quality Sense produces. The owner gets a weighted Data Quality Score with trend lines in Insight Studio — the number they report. Stewards encode their standards as rules in the Definition Builder, so "what good looks like" is executable, not a wiki page. And because scans break results down by object and field, the feedback loop to producers runs on specifics: which team, which field, how often. All of it inside Salesforce, with no data export. ## FAQ **Who should own data quality in Salesforce?** One named person should be accountable for the overall state of CRM data — usually the RevOps lead in mid-size orgs, or a data governance lead in larger ones. The Salesforce admin implements controls, object stewards define what good looks like for their area, and everyone who creates records is responsible for meeting entry standards. Accountability sits with one person; responsibility is distributed. **Is the Salesforce admin responsible for data quality?** The admin is responsible for the mechanisms — validation rules, duplicate rules, page layouts, integrations — but not for the business decisions behind them. An admin cannot decide which fields matter for forecasting or what a complete Account looks like. Treating the admin as the owner of data quality is one of the most common reasons programs stall. **Why does "everyone owns data quality" fail?** Because shared ownership without a named accountable person means no one is answerable when quality degrades. Everyone contributing to data quality is the goal; everyone owning it is the anti-pattern. The working model is one accountable owner, named stewards per object or domain, and clear entry standards for everyone who touches records. ## Next Steps - [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/): the complete guide - [Building a Data Quality Culture](/resources/best-practices/building-data-quality-culture/): making the model stick beyond the org chart - [Data Quality KPIs and Metrics](/resources/best-practices/data-quality-kpis/): what the owner should report - [How to Measure Data Quality in Salesforce](/resources/salesforce/measure-data-quality-in-salesforce/): getting the baseline number # PII Detection: Configuration Scenarios > Three practical walkthroughs showing how to configure DQS PII detection for different scanning needs. Source: https://dataqualitysense.com/resources/use-cases/pii-detection-scenarios/ Last updated: 2026-06-03 --- ## What These Scenarios Cover This page walks through three real-world configurations of DQS PII detection. Each scenario covers a specific scanning need, shows the exact settings to use, and explains how to read the results. These walkthroughs build on the concepts from the main [PII Detection](/resources/ai-readiness/pii-detection/) article. Read that first if you are new to PII detection patterns, presets, or the diagnostic flow. ## Scenario 1: Pre-AI Audit on Case Comments ### The Business Context Your company is rolling out Agentforce on the Service Cloud. Before connecting Case data to AI, the compliance team requires a PII exposure report. You need to scan Case free-text fields (Description, Internal Comments) to know whether PII is present and how widespread it is. ### Configuration Use the Standard preset with PII Detection Analysis mode. This gives you both metrics: the count and the exposure rate. | Setting | Value | Why | |---------|-------|-----| | Preset | Standard (SSN, Credit Card, Email, US Phone) | Covers the four most common PII types without noise from high-FP patterns | | Analysis Mode | PII Detection Analysis | You need both Records with PII (count) and PII Exposure Rate (percentage) for the compliance report | | Fields | Description (LongTextArea), Internal_Comments__c (LongTextArea) | Free-text fields where agents paste customer communications | ### Sample Results (for Description field) | Metric | Value | |--------|-------| | Records with PII | 1,247 | | PII Exposure Rate | 15.6% | Total Case records scanned: 8,000. ### Reading the Results Start with PII Exposure Rate: 15.6%. Roughly 1 in 6 Case descriptions contains PII. This is above any reasonable threshold for AI processing. Records with PII gives the cleanup scope: 1,247 cases need review. This number tells the compliance team how large the remediation effort is. The Standard preset scans for SSN, Credit Card, Email, and US Phone. High matches on a Description field likely come from email addresses (agents pasting customer emails) and phone numbers (callback details). SSN and credit card matches are the compliance-critical findings. To break down the exposure by PII type, run separate scans with individual patterns enabled. First, scan with only SSN + Credit Card (the Critical preset) to isolate the high-severity findings. Then compare against the full Standard scan to see how much of the exposure is contact information vs. financial PII. ### Next Action Present the compliance team with two numbers: 1,247 records affected, 15.6% exposure rate. If the SSN/credit card subset is non-zero, those records need remediation before AI deployment. The email and phone matches need a policy decision: are those PII types acceptable in the AI context, or do they also need masking? --- ## Scenario 2: Financial Compliance Quick Check on Leads ### The Business Context Your data team is migrating 50,000 Lead records to a new marketing automation platform. The vendor's DPA (Data Processing Agreement) prohibits transferring SSNs or credit card numbers. You need a fast yes/no answer: does the Lead data contain financial PII? ### Configuration Use the Critical preset with PII Scan mode. Two patterns, fast scan, count-only output. | Setting | Value | Why | |---------|-------|-----| | Preset | Critical (SSN, Credit Card) | Only two patterns. Minimum scan for financial PII. Near-zero false positive rate. | | Analysis Mode | PII Scan | You need a count, not a percentage. Fast scan for a go/no-go decision. | | Fields | Description (LongTextArea), Notes__c (TextArea), Company (String) | Free-text fields where financial PII can appear | ### Sample Results (for Description field) | Metric | Value | |--------|-------| | Records with PII | 23 | Total Lead records scanned: 50,000. ### Reading the Results 23 records out of 50,000. The SSN pattern (NNN-NN-NNNN) and credit card pattern (13-16 digit sequences) found matches in 23 Lead descriptions. This is a small number, but for a migration governed by a DPA, even one record matters. These 23 records need manual review before export. Some matches are likely false positives, especially from the credit card pattern. Long numeric sequences in Lead descriptions (tracking numbers, invoice IDs) can trigger the 13-16 digit regex. Review the 23 records to separate confirmed PII from false matches. If the Notes__c and Company fields also show matches, add those to the review list. The Company field (String type) is short text, so false positives from the credit card pattern are less likely but still possible. ### Next Action Pull the 23 records for manual review. Confirm which are actual SSNs or credit card numbers vs. false positives. Remediate confirmed PII: delete, mask, or exclude from export. Rerun the scan after remediation to verify zero matches. Document the clean scan result for the vendor's DPA compliance file. --- ## Scenario 3: Per-Field Override Strategy for a Support Org ### The Business Context Your support org has 6 text fields across Case and Contact objects. Each field has different PII risk characteristics. A single global pattern set produces too many false positives on some fields and misses risk on others. You need field-specific pattern configurations. ### Configuration Start with a global baseline, then override per field. **Global configuration:** | Setting | Value | Why | |---------|-------|-----| | Preset | Standard (SSN, Credit Card, Email, US Phone) | Reasonable default for most fields | | Analysis Mode | PII Detection Analysis | Exposure rates needed for the quarterly governance report | **Per-field overrides:** | Field | Object | Type | Override Patterns | Rationale | |-------|--------|------|-------------------|-----------| | Email | Contact | Email | SSN, Credit Card only | The Email field contains email addresses by design. Scanning for the email pattern produces 100% matches. Only scan for financial PII that does not belong in this field. | | Description | Case | LongTextArea | Extended (all 8) | Free text where anything can appear. Agents paste full customer communications. Use the widest net. | | Subject | Case | String | Critical (SSN, Credit Card) | Short text field. High false-positive risk for patterns like DOB. Only scan for the two highest-severity types. | | Internal_Comments__c | Case | LongTextArea | Standard (4 patterns) | Keep the global default. Internal comments have moderate PII risk. | | Phone | Contact | Phone | SSN, Credit Card only | The Phone field contains phone numbers by design. Same logic as Email: only scan for PII types that do not belong. | | Notes__c | Contact | TextArea | Standard + IP Address | Notes field gets the default plus IP Address. Support contacts sometimes include server/network information in notes. | ### Sample Results | Field | Records with PII | PII Exposure Rate | |-------|:----------------:|:-----------------:| | Email (Contact) | 3 | 0.04% | | Description (Case) | 1,847 | 23.1% | | Subject (Case) | 0 | n/a | | Internal_Comments__c (Case) | 412 | 5.2% | | Phone (Contact) | 0 | n/a | | Notes__c (Contact) | 89 | 2.8% | ### Reading the Results **Email field: 3 records, 0.04%.** Three Contact email fields contain something matching the SSN or credit card pattern. This is unexpected and worth investigating. Likely a data entry error where someone put an SSN in the email field. **Description field: 1,847 records, 23.1%.** Nearly a quarter of Case descriptions contain PII. The Extended preset catches everything. The high count is expected on a free-text field where agents paste customer communications. This field is your highest-priority target for remediation. **Subject field: 0 records.** Clean. The Critical preset on a short text field produces zero noise. **Internal Comments: 412 records, 5.2%.** Moderate exposure. The Standard preset catches the common patterns without the noise of DOB false positives. 412 records is a manageable review scope. **Phone field: 0 records.** Clean. No SSNs or credit cards in the phone field. **Notes field: 89 records, 2.8%.** Low exposure. The IP Address pattern addition caught some matches in the notes. Review whether these are actual IP addresses from server configurations pasted by support staff. ### Next Action Focus remediation on the Description field first (highest exposure). Use the per-field results to prioritize: Description (23.1%) > Internal Comments (5.2%) > Notes (2.8%) > Email (0.04%). The Subject and Phone fields are clean. Run this scan quarterly. The per-field overrides stay in place, so each subsequent scan uses the same targeted configuration. --- ## Choosing Your Configuration | If You Need To... | Start With | Key Settings | |--------------------|------------|--------------| | Run a PII audit before an AI project | Standard preset, PII Detection Analysis | Both metrics give count + exposure rate for compliance reports | | Check for financial PII before a data migration | Critical preset, PII Scan | Two patterns, fast scan, near-zero false positives | | Maximize detection coverage for a first-time audit | Extended preset, PII Detection Analysis | All 8 patterns. Higher false-positive rate but nothing is missed. | | Tune detection per field to reduce false positives | Standard global + per-field overrides | Remove expected-content patterns (email on Email fields, phone on Phone fields) | | Run a targeted compliance check for specific PII types | Custom pattern set, PII Scan | Toggle only the specific patterns relevant to your compliance framework | For a full reference of all 8 detection patterns, three presets, and how the diagnostic flow works, return to the main [PII Detection](/resources/ai-readiness/pii-detection/) article. To see how PII detection fits into the broader AI readiness picture, take the [AI Readiness Assessment](/ai-readiness/). # Agentforce Data Readiness Checklist > A practical Agentforce data readiness checklist. Assess whether your Salesforce data is ready for AI agents across completeness, consistency, PII, and more. Source: https://dataqualitysense.com/resources/ai-readiness/agentforce-data-readiness-checklist/ Last updated: 2026-07-15 --- Agentforce data readiness is the state in which your Salesforce records are complete, consistent, valid, fresh, deduplicated, and free of exposed PII, so that AI agents retrieve accurate context and generate trustworthy responses. Your data is ready for Agentforce when each of those six conditions is measured and meets a defined threshold, not assumed. This checklist gives you the items to verify, the reason each one matters, and the DQS metric that measures it. Agentforce agents retrieve Salesforce records, generate responses grounded in CRM data, and take actions on behalf of users. Every one of those steps reads your data as the source of truth. If a field is blank, the agent has no context. If a value is spelled four ways, the agent treats it as four facts. If a Case comment holds a Social Security Number, the agent can surface it. Readiness means closing those gaps before deployment, not after an agent gives a wrong answer in production. For the full phased plan behind this list, see [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/). ## How Do You Know If Your Salesforce Data Is Ready for Agentforce? You know by measuring, not by inspecting records by hand. Run a [DQS scan](/resources/using-dqs/running-scans/) across every object the agent will access, then compare each metric against a target threshold. Work through the six areas below. Each checkbox is something you can verify with a scan result, so the answer to "is my data ready" becomes a number instead of an opinion. The measuring step is the one most organizations skip. In [Accenture's research on AI-ready data](https://www.accenture.com/us-en/insights/ai-data/ai-ready-data), 61% of CXOs acknowledged their data assets are not yet ready for generative AI, and only 7% of companies had reached the level of data readiness required to scale advanced AI. A checklist verified against scan results is how you find out which side of that line you are on. Copy the checklist into your project notes and check items as you confirm them. ## Scope and Access Define what the agent touches before you measure anything. An agent that reads the wrong objects fails no matter how clean the rest of your org is. - [ ] **List every object Agentforce will read or write.** The agent only retrieves what its topics and actions allow. Scope your scans to that exact set so you measure the data the agent actually sees. - [ ] **List the fields within each object the agent uses for responses.** Description, Comments, Notes, and key picklists carry the context. Scanning all fields wastes effort; scan the ones that ground answers. - [ ] **Confirm field-level security matches intent.** An agent inherits the running user's access. A field hidden from the user is invisible to the agent, so a "missing" answer is sometimes a permission gap, not a data gap. - [ ] **Record which integrations write to those fields.** Integrations are the most common source of inconsistent and duplicated values. Knowing the writers tells you where to fix the intake, not just the data. ## Completeness Agents generate vague responses when the fields they read are empty. Completeness is the first thing to measure because missing context is the most common cause of weak agent output. - [ ] **Completeness Rate is 85% or higher on every field the agent uses for responses.** A blank Description gives the agent nothing to ground an answer on. The **Completeness Rate** reports the percentage of records where the field holds a value. - [ ] **Critical context fields have no systemic blanks from a single source.** A field left empty by one integration is a process fix, not a record-by-record cleanup. Field-level Completeness Rate isolates the source. - [ ] **Required-for-the-business fields are populated, even when not required in the schema.** Agentforce treats a blank field as absence of fact. See [Completeness](/resources/data-quality/completeness/) for how DQS scopes "should be filled" per object. ## Consistency and Validity When the same real-world value appears in several forms, the agent treats each as distinct and answers inconsistently. When a value breaks its expected format, downstream retrieval becomes unreliable. - [ ] **Conformance Rate is 90% or higher on picklist and reference fields.** A Country field holding "US", "USA", and "United States" splits one fact into three. The **Conformance Rate** reports the percentage of values matching your canonical set. Use Import from Field to discover existing variants, then define the canonical values. See [Consistency](/resources/data-quality/consistency/). - [ ] **Validity Rate is 90% or higher on formatted fields.** An email with no `@`, a phone number containing letters, or an impossible date is something the agent cannot act on — it can't send, dial, or schedule. The **Validity Rate** reports the percentage of values passing your format rules. See [Validity](/resources/data-quality/validity/). - [ ] **Cross-field contradictions are resolved.** A Billing State that contradicts its Billing Country teaches the agent a false relationship. Consistency checks surface values that disagree with each other. ## Freshness and Duplicates Stale data grounds answers in facts that are no longer true. Duplicate records give the agent two versions of one entity, so the response depends on which copy it retrieves. - [ ] **Timeliness Rate meets your target on date-sensitive fields.** A Last Activity from two years ago or a Close Date in the past misleads the agent. The **Timeliness Rate** reports the percentage of records current within your defined window. See [Timeliness](/resources/data-quality/timeliness/). - [ ] **Duplicate Rate is low on the objects the agent reads.** When the agent retrieves one of three records for the same customer, it answers from partial history. The **Duplicate Rate** reports the percentage of records that duplicate another. See [Uniqueness](/resources/data-quality/uniqueness/). - [ ] **Merge or flag duplicates before deployment, not after.** Duplicates created across forms, imports, and manual entry multiply without monitoring. Resolve them so the agent reads one record per entity. ## PII and Compliance PII in the text fields an agent reads enters the AI context and can appear in a generated response. This is the area where a readiness gap becomes a compliance incident. - [ ] **PII Exposure Rate is below 1% on text fields the agent accesses.** SSNs and credit-card numbers accumulate in Description, Comments, and Notes through copy-paste and email-to-case. The **PII Exposure Rate** reports the percentage of records containing a pattern match. See [PII Detection](/resources/ai-readiness/pii-detection/). - [ ] **Zero SSN or credit-card matches on Case Description and Comments.** Financial PII is the highest-severity finding. Run the Critical preset scan to isolate it, then mask, delete, or exclude confirmed matches. - [ ] **Per-field pattern overrides are configured for expected-content fields.** An Email field matches the email pattern by design, which is noise, not exposure. Per-field overrides remove that noise so the rate reflects real risk. - [ ] **Compliance team has signed off on the post-remediation PII scan.** GDPR, CCPA, HIPAA, and PCI DSS require identifying and protecting PII. DQS runs entirely inside Salesforce, so no records leave the org during detection. See [Agentforce PII Compliance](/resources/ai-readiness/agentforce-pii-compliance/). ## Operations and Monitoring Data quality degrades as users enter new records. A dataset that passes today accumulates new issues within weeks, so readiness is a state you maintain, not a milestone you pass once. - [ ] **Baseline metrics are documented for every dimension in scope.** You need the starting numbers to prove remediation worked and to detect regression later. - [ ] **A recurring scan schedule is configured.** Scheduled scans turn a one-time snapshot into a trend line. Run PII weekly on high-volume text objects, completeness and consistency monthly, and a full scan quarterly. - [ ] **Remediation ownership is assigned per dimension.** A metric with no owner does not improve. Name the person responsible for completeness, for PII, and so on. - [ ] **Agent responses are tested against remediated data.** A passing scan predicts good behavior; a test confirms it. Verify outputs are accurate and that no PII appears in generated content. ## Readiness Thresholds at a Glance Use this table as the pass criteria for each area. The targets match the [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/) plan. | Checklist area | DQS metric | Target threshold | |---|---|---| | Completeness | Completeness Rate (key fields) | 85% or higher | | Consistency | Conformance Rate (picklists, references) | 90% or higher | | Validity | Validity Rate (formatted fields) | 90% or higher | | Timeliness | Timeliness Rate (date-sensitive fields) | Meets your defined window | | Uniqueness | Duplicate Rate (agent-read objects) | Low and trending down | | PII and compliance | PII Exposure Rate (agent-read text fields) | Below 1% | ## What If My Org Fails Several Items? A failing checklist is the expected starting point, not a reason to delay. Most orgs discover issues they did not expect on the first scan. Prioritize in this order: PII first, because it carries compliance risk; then completeness and consistency, because they shape the quality of agent context; then validity, timeliness, and uniqueness. Fix the highest-impact, lowest-effort items first, rerun the scan, and compare against your baseline. For a step-by-step remediation path, see [Salesforce Data Cleanup for Agentforce](/resources/ai-readiness/salesforce-data-cleanup-for-agentforce/) and [Why Agentforce Agents Fail](/resources/ai-readiness/why-agentforce-agents-fail/). ## Next Steps - [Agentforce Readiness](/resources/ai-readiness/agentforce-readiness/): the five-pillar org assessment this data checklist is one pillar of - [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/): the full phased readiness plan behind this checklist - [Salesforce Data Cleanup for Agentforce](/resources/ai-readiness/salesforce-data-cleanup-for-agentforce/): how to remediate failing items - [PII Detection](/resources/ai-readiness/pii-detection/): configure PII scanning for the fields agents read - [Why Agentforce Agents Fail](/resources/ai-readiness/why-agentforce-agents-fail/): the data problems behind weak agent output - [Agentforce Data Quality FAQ](/resources/ai-readiness/agentforce-data-quality-faq/): quick answers to common readiness questions - [How to Measure Data Quality in Salesforce](/resources/salesforce/measure-data-quality-in-salesforce/): the Data Quality Score in depth - [AI Readiness Assessment](/ai-readiness/): get your current readiness score # Consistency > All 6 consistency metrics DQS measures, the diagnostic flow for finding value fragmentation, and how to configure conformance analysis. Source: https://dataqualitysense.com/resources/data-quality/consistency/ Last updated: 2026-02-25 --- ## What is Consistency? Consistency measures whether your data values conform to an agreed-upon standard. A field is consistent when every record uses the same term for the same concept. A field is inconsistent when variations exist that mean the same thing but are expressed differently. "USA", "United States", and "US" all refer to the same country. To Salesforce, they are three distinct values. A report grouped by Country produces three rows instead of one. An automation filtering for "USA" misses 230 records containing "United States." ``` Conformance Rate = (Conforming Records / Total Records) x 100 ``` If 850 of 1,000 Account records have a Country value that matches your allowed values list, your Country conformance rate is 85%. The remaining 15% contain variations that need standardization. ## Why Consistency Matters ### Reporting Inconsistent data fragments your reports. When your Country field contains five different spellings of the same country, a report grouped by Country shows five rows instead of one. The total is correct, but the grouping is wrong. Executive dashboards built on these reports tell a misleading story. ### Automation Salesforce automation depends on exact value matches. A workflow filtering for `Country = "USA"` misses records with "United States" and "US." The automation runs correctly on matching records but silently skips everything else. ### AI and Agentforce AI models treat each variation as a separate concept. "USA" and "United States" become two different countries in the model's view. Agentforce generates responses using your field values. Inconsistent values produce inconsistent AI outputs. | System | Consistency Impact | |--------|-------------------| | Reports | Fragmented groupings, misleading totals | | Workflows | Filters miss non-matching variations | | Duplicate Rules | Variations prevent correct matching | | Agentforce | Inconsistent field values produce unreliable AI responses | ## How DQS Measures Consistency DQS produces 6 consistency metrics organized around a diagnostic question: **"Do your field values conform to a standard, and if not, what are they doing instead?"** Think of these metrics as a diagnostic flow. Each step reveals a different layer of the problem. ### Step 1: How Consistent Is It? **Conformance Rate** is the headline metric. It calculates the percentage of records where the field value matches one of your defined allowed values. This is the number you put on a dashboard. You run a scan on the Account object. The `Country` field shows a Conformance Rate of 72%. That means 28% of your Accounts contain country values outside your allowed list. Your territory assignment rules, regional dashboards, and localization logic all operate on incomplete data. Every other consistency metric exists to explain *what* the non-conforming 28% looks like. ### Step 2: What Is the Scale? Rates tell you severity. Counts tell you workload. Two metrics answer the scale question: | Metric | What It Tells You | |--------|-------------------| | **Conformance Count** | How many records match your allowed values. Use this for coverage reporting. | | **Non-Conforming Count** | How many records fall outside your allowed values. Use this to scope cleanup projects. | These two numbers always add up to total records. If your Conformance Count is 720 and Non-Conforming Count is 280, you have exactly 1,000 records evaluated. **Example:** Your data steward needs to clean up the `Industry` field. Non-Conforming Count is 3,400. She now knows the scope of the project, can assign resources, and can set a realistic timeline for standardization. ### Step 3: How Fragmented Is the Data? **Variant Count** measures the number of distinct values found in a field across all records. It answers: "How many different ways are people expressing this data?" This metric works as a schema health indicator. A Country field with 5 distinct values is likely well-controlled. A Country field with 47 distinct values signals serious fragmentation, even before you check conformance. | Field | Total Records | Variant Count | Assessment | |-------|---------------|---------------|------------| | Country | 1,000 | 5 | Well-controlled, likely consistent | | Country | 1,000 | 47 | Highly fragmented, needs standardization | | Industry | 500 | 12 | Reasonable, probably picklist-constrained | | Industry | 500 | 89 | Free-text chaos, needs immediate attention | **Example:** During an org audit, you scan `Lead_Source__c` on Leads. Variant Count returns 34. Your marketing team defined 8 lead sources. The remaining 26 variants are misspellings, abbreviations, and ad-hoc entries from integrations. The picklist is technically enforced at the UI, but API-created records bypass it. ### Step 4: What Are the Actual Values? **Dominant Values** returns the top N most frequent values in the field, along with each value's frequency count. This tells you what your data actually looks like, not what you expect it to look like. | Rank | Value | Count | Percentage | |------|-------|-------|------------| | 1 | United States | 450 | 45% | | 2 | USA | 230 | 23% | | 3 | US | 180 | 18% | | 4 | U.S.A. | 45 | 4.5% | | 5 | United States of America | 15 | 1.5% | This table reveals three things. First, the de facto standard: "United States" at 45% is what most users enter. Second, the common variations: "USA" and "US" account for another 41%. Third, the long tail: "U.S.A." and "United States of America" are rare but present. **Example:** Your team is debating whether to standardize Country values to ISO codes ("US") or full names ("United States"). Dominant Values shows that 45% of records already use "United States." Standardizing to that value requires changing 55% of records. Standardizing to "US" requires changing 82%. The data tells you the cheaper path. ### Why Rates and Counts Come in Pairs Conformance metrics come as a rate (Conformance Rate) and its inverse (Non-Conformance Rate), plus absolute counts for both sides. This is intentional: - **Rates** are for dashboards, executive reporting, and trend tracking. "Conformance improved from 72% to 94% this quarter." - **Counts** are for project planning, workload estimation, and cleanup scoping. "We have 3,400 non-conforming records to fix." Use rates to communicate progress. Use counts to plan work. ## Metric Reference ### Foundation Metrics These 2 metrics form the base of every consistency analysis. They tell you the conformance rate and the number of records that match. | Metric | Type | What It Measures | |--------|------|-----------------| | Conformance Rate | Percentage | Share of records matching your allowed values | | Conformance Count | Count | Number of records matching your allowed values | ### Advanced Metrics These 4 metrics go beyond "does it match?" to ask "what does the non-matching data look like?" They require the Advanced Conformance Analysis mode. | Metric | Type | What It Measures | |--------|------|-----------------| | Non-Conforming Count | Count | Records with values outside your allowed list | | Non-Conformance Rate | Percentage | Share of records outside your allowed list | | Variant Count | Count | Total distinct values found in the field | | Dominant Values | List | Top N most frequent values with frequency counts | ### Field Type Coverage DQS supports consistency checks on the following Salesforce field types: | Field Type | Consistency Focus | |------------|-------------------| | String (Text) | Abbreviations, spelling, casing | | TextArea | Free-text standardization | | Picklist | Validating actual values against expected options | | Email | Domain standardization, format consistency | | Phone | Format standardization (area codes, separators) | | URL | Protocol and path consistency | ## Two Analysis Modes DQS offers two consistency analysis modes: **Conformance Check** answers the question: "Do field values match my allowed list?" It produces the 2 foundation metrics and covers the essentials for a quick conformance audit. **Advanced Conformance Analysis** goes deeper. It produces all 6 metrics, including non-conforming counts, variant detection, and dominant value distribution. Use this mode when you need to understand the full landscape of value fragmentation, not just the conformance score. | Business Need | Recommended Mode | |---------------|-----------------| | Quick conformance audit or baseline check | Conformance Check | | Data migration cleanup | Advanced (variant count reveals imported chaos) | | AI readiness evaluation | Advanced (dominant values show what the AI will learn from) | | Ongoing data governance | Start with Conformance Check, move to Advanced when ready for deeper analysis | ## Configuring Consistency DQS provides four configuration inputs for consistency. Each can be set at the global level (applies to all fields) and overridden at the individual field level. | Setting | What It Controls | |---------|-----------------| | **Expected Values** | The list of values DQS treats as "conforming." Any field value not on this list is flagged as non-conforming. Required: you must define at least one value before running a scan. | | **Case Sensitive** | Controls whether value matching considers letter casing. When disabled (the default), "Premium", "PREMIUM", and "premium" all match the allowed value "Premium." When enabled, only an exact case match counts. | | **Top N** | How many dominant values to return (1 to 100). Controls the size of the Dominant Values output. Default: 5. | | **Min Frequency** | The minimum number of times a value must appear to be included in the Dominant Values output (1 to 1,000). Filters out ultra-rare values that add noise. Default: 1. | > **Tip:** Start by using Import from Field to see what values actually exist in your data before defining your allowed values list. ### Import from Field: Discovery-First Configuration A common challenge with consistency is knowing which values to expect. You cannot define allowed values if you do not know what your data contains. Import from Field solves this. It queries the actual field data, groups values by frequency, and displays the results as a checklist. **How it works:** 1. Open the Expected Values configuration. 2. Click **Import from Field**. DQS queries the live data and returns distinct values sorted by frequency. 3. Review the checklist. Each value shows how many records contain it. 4. Check the values you consider correct. Leave incorrect, malformed, or placeholder values unchecked. 5. Click **Add Selected**. The checked values populate your allowed values list. **Example:** You configure consistency for a `Rating__c` field. Import from Field returns: | Value | Records | |-------|---------| | Hot | 284 | | Warm | 198 | | Cold | 156 | | Very High | 23 | | 240 km/h | 12 | | N/A | 8 | The first three values are your real ratings. You check those. "Very High" is a data entry error. "240 km/h" is clearly wrong-field data. "N/A" is a placeholder. You leave those unchecked. When the scan runs, those 43 records appear as non-conforming, and your allowed values list is built from what your data actually contains. This workflow inverts the traditional "guess first, fix later" approach. You discover first, then define your standard. ## Common Consistency Issues ### Country and State Variations The most common inconsistency in Salesforce data. Without standardization, a single concept like "United States" appears as 5 or more distinct values. Reports fragment. Filters miss records. Territory rules fail. **Fix:** Enable Salesforce State and Country Picklists for all address fields. Use DQS to find and clean up existing non-conforming values. ### Free-Text Fields Without Governance Text fields that lack picklist constraints accumulate variations over time. Industry, Job Title, Lead Source, and Department fields are frequent offenders when implemented as free text. **Fix:** Convert high-value free-text fields to picklists. Use Import from Field to see your current value distribution before defining the picklist options. ### Integration-Created Variations External systems and APIs write records that bypass Salesforce UI validation. A marketing automation platform writes "Info Technology" while your standard is "Information Technology." These variations accumulate silently. **Fix:** Apply value mapping rules in your integration layer. Run periodic consistency scans to catch new variations from data sources you do not control. ### Casing Inconsistencies Users enter "Active", "active", and "ACTIVE" across different records. With case-sensitive matching disabled, DQS counts all three as conforming. But the field still contains three different spellings in the raw data. **Fix:** Decide whether casing matters for your use case. For display-facing fields, standardize casing through data cleanup. For matching purposes, disable case sensitivity in your DQS configuration. ## Best Practices ### Define Standards Before Scanning Document the expected value for each constrained field before running your first scan. Without a clear standard, you have no baseline to measure against. | Field | Standard | Rationale | |-------|----------|-----------| | Country | ISO 3166-1 alpha-2 codes (US, CA, DE) | Industry standard, compact | | Industry | 15-value custom taxonomy | Matches reporting categories | | Lead Source | 8 marketing-defined sources | Aligns with campaign tracking | ### Use the Discovery Workflow for Unknown Fields For fields where you do not have a predefined standard, use Import from Field first. Let the data tell you what the de facto standard is. The value with the highest frequency is often the right choice as your canonical value. ### Track Conformance Over Time A single conformance score is a snapshot. Track scores across multiple scans to detect degradation early, measure cleanup progress, and identify data sources that introduce new variations. ### Use Variant Count as an Early Warning Monitor Variant Count across scans. A field that jumps from 12 to 28 distinct values between scans has a new source of variation. Investigate before the problem scales. ### Prioritize by Business Impact Not every field needs 100% conformance. Focus on fields that drive reporting (Country, Industry), feed automation (Status, Stage), or supply data to AI and Agentforce. ## Next Steps You have now completed all five data quality dimensions. Continue your learning: - **In Salesforce:** [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/) - standardize picklist and reference values in Salesforce - **Next:** [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/) - Learn about AI-specific data requirements - **Previous:** [Timeliness](/resources/data-quality/timeliness/) - Measure data freshness and currency - **Overview:** [The Five Dimensions](/resources/data-quality/five-dimensions/) - Review all dimensions together - **Action:** [AI Readiness Assessment](/ai-readiness/) - See your consistency scores and more # The Real Cost of Bad Salesforce Data > Bad CRM data has a price: rep hours lost to record archaeology, wasted marketing spend, missed forecasts, and AI that answers from fiction. Here is the math. Source: https://dataqualitysense.com/resources/salesforce/cost-of-bad-salesforce-data/ Last updated: 2026-07-23 --- Bad Salesforce data does not send an invoice. It bills you in small, distributed charges — a rep retyping a phone number, a bounced email, a duplicate account worked twice, a forecast off by a stale amount — and none of those charges is large enough to trigger an alarm. Added up, they are one of the most expensive line items nobody budgets for: Gartner estimates poor data quality costs organizations an average of [$12.9 million per year](https://www.gartner.com/smarterwithgartner/how-to-improve-your-data-quality). You do not need to trust an industry average, though. The costs of bad CRM data fall into four buckets, and each of them can be estimated for your org with numbers you already have. ## Where the Money Actually Goes ### 1. Seller time Salesforce's own [State of Sales research](https://www.salesforce.com/resources/research-reports/state-of-sales/) consistently finds reps spending roughly 70% of their time on non-selling work — and record archaeology is a steady share of it: hunting for the right account among duplicates, fixing contact details mid-call, reconstructing history a previous owner never logged. The math is uncomfortable at any team size: > 20 minutes per rep per day on data cleanup × 20 reps × $60 loaded hourly cost ≈ **$100,000 per year** — before counting a single lost deal. ### 2. Wasted marketing and outreach spend B2B contact data decays at about [2.1% per month — roughly 22.5% per year](https://pipeline.zoominfo.com/marketing/b2b-data-decay). People change jobs, companies merge, emails die. Every stale or duplicated contact in a campaign is spend with a guaranteed zero return: emails that bounce, ads served to duplicates, SDR sequences aimed at people who left 18 months ago. If a fifth of your database is stale, a fifth of database-driven spend is burned before the campaign starts — and the sender-reputation damage from bounces taxes the deliverability of everything else. ### 3. Forecast and reporting errors This is the bucket executives feel first. A pipeline report is only as good as the Amount, Stage, and Close Date fields underneath it — and those decay like everything else. Stale opportunities inflate the pipeline; missing amounts deflate it; duplicated accounts double-count it. The cost is not the wrong number itself but the decisions made on it: hiring against pipeline that is not real, cutting spend because real pipeline was invisible, quarter-end surprises that were knowable in week two. When the [six dimensions of data quality](/resources/data-quality/five-dimensions/) slip on Opportunity records specifically, the forecast is where it surfaces. ### 4. Automation and AI acting on fiction Flows, assignment rules, and scoring models execute on field values without judgment — bad value in, wrong action out, at machine speed. A wrong Industry misroutes a hot lead; a missing Amount silently drops a deal from a territory calculation. AI raises the stakes: an agent answering customer questions from incomplete or contradictory records produces [confidently wrong answers](/resources/ai-readiness/why-agentforce-agents-fail/), and PII sitting in free-text fields becomes compliance exposure the moment an AI reads it. This bucket is why data quality has moved from an ops concern to a launch-blocker for [Agentforce initiatives](/resources/ai-readiness/agentforce-preparation/). ## Why the Cost Compounds: the 1-10-100 Rule Quality management research (Labovitz and Chang, *Making Quality Work*, 1992) established the ratio that still governs data economics: an error costs about **$1 to prevent** at entry, **$10 to correct** once stored, and **$100 once it reaches a customer or a decision**. A malformed email is nearly free to block with a validation rule, cheap to fix in a cleanup sweep, and expensive once a sequence has bounced off it and the domain's sender score has paid the price. The rule's practical meaning: every month a known issue sits unfixed, it migrates toward the expensive end. [Prevention controls](/resources/salesforce/improve-data-quality-in-salesforce/) are not a nice-to-have; they are the only point where the fix costs a dollar. ## Estimate It for Your Org Four line items, one afternoon: | Line item | Formula | You need | |---|---|---| | Seller time | min/day on cleanup × reps × loaded rate × 220 days | A quick poll of 5 reps | | Wasted outreach | stale+duplicate share × database-driven spend | Bounce and duplicate rates | | Forecast at risk | pipeline value in records with missing/stale Amount, Stage, or Close Date | A report on those fields | | Rework and incidents | incidents/quarter traced to bad data × hours × rate | Ops ticket history | The [ROI calculator](/roi-calculator/) runs this arithmetic for you — enter team size, database size, and spend, and it produces the annual figure. The stale-share and missing-field inputs are guesses until you measure them; a [Data Quality Score](/resources/salesforce/measure-data-quality-in-salesforce/) per object replaces the guesses with evidence. ## How DQS Helps Data Quality Sense turns the cost argument from anecdote into a number. A scan gives you the measured inputs — completeness of forecast-critical fields, duplicate rates, stale-record share, PII exposure — broken down by object and field, entirely inside Salesforce. Paired with the ROI calculator, that is a business case an executive can act on: this is what bad data costs us, these five fields drive most of it, here is the trend since we started fixing it. ## FAQ **How much does bad data cost a company?** Gartner puts the average cost of poor data quality at $12.9 million per year per organization. For a single Salesforce org, the visible costs concentrate in four places: seller time lost to fixing and hunting records, marketing spend wasted on undeliverable or duplicate contacts, forecast and reporting errors that misdirect decisions, and rework caused by automation and AI acting on wrong values. **How do I calculate the cost of bad data in my Salesforce org?** Estimate four line items: rep time (minutes per day spent on record cleanup × loaded hourly cost × team size), wasted outreach (share of contacts that are stale or duplicated × campaign spend), forecast risk (pipeline value sitting in records with missing or stale amounts and dates), and rework from failed automations. A measured Data Quality Score per object turns these from guesses into evidence. **Why does bad data cost more the longer it stays?** The 1-10-100 rule from quality management: an error costs about $1 to prevent at entry, $10 to fix once stored, and $100 when it reaches a customer or a decision. Bad data compounds — a wrong email is cheap until a sequence sends to it, a duplicate is harmless until two reps work the same account, a stale amount is invisible until the quarter misses. ## Next Steps - [ROI Calculator](/roi-calculator/): put your own numbers on it - [How to Measure Data Quality in Salesforce](/resources/salesforce/measure-data-quality-in-salesforce/): replace estimates with a baseline - [How to Improve Data Quality in Salesforce](/resources/salesforce/improve-data-quality-in-salesforce/): the detect–fix–prevent loop - [Why Agentforce Agents Give Wrong Answers](/resources/ai-readiness/why-agentforce-agents-fail/): the AI cost bucket in detail # Why Agentforce Agents Give Wrong Answers: Data Quality Root Causes > Why Agentforce gives wrong answers: 6 data quality root causes behind inaccurate responses and hallucinations, the DQS metric that diagnoses each, and the fix. Source: https://dataqualitysense.com/resources/ai-readiness/why-agentforce-agents-fail/ Last updated: 2026-07-15 --- Most Agentforce wrong answers trace back to the data the agent retrieves, not the model that generates the text. Agentforce agents read your Salesforce records, ground their responses in what they find, and act on it — so when the underlying records are incomplete, inconsistent, stale, or duplicated, the agent produces inaccurate responses from accurate retrieval of bad data. This is a troubleshooting guide. Each section maps a failure symptom you can observe to the data problem causing it, the DQS metric that diagnoses it, and the remediation step that fixes it. If you are planning a deployment rather than debugging one, start with the [Agentforce data quality guide](/resources/ai-readiness/agentforce-preparation/) and the [data readiness checklist](/resources/ai-readiness/agentforce-data-readiness-checklist/). ## Why Does Agentforce Give Wrong Answers at All? An agent does not invent facts in a vacuum. It retrieves records that match a request, reads the fields it has access to, and assembles a response from that context. The model is consistent; the data underneath it is not. What looks like a hallucination is often the agent faithfully reporting what your records say. A blank field gives the agent nothing to ground on. Four spellings of the same country give it four answers. A duplicate record gives it a second version of the truth. Fix the data and most of these failures disappear without touching the agent configuration. The pattern is industry-wide, not specific to your org. [Gartner predicted in 2024](https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025) that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, naming poor data quality as a leading cause. And in [Salesforce's own State of Data and Analytics research](https://www.salesforce.com/news/stories/data-analytics-trends/), data and analytics leaders rated 26% of their data as untrustworthy — roughly one record in four feeding wrong context to any agent built on top of it. The six failure modes below cover the data root causes you can measure and correct in Salesforce. ## Why Are Agentforce Responses Vague or Generic? **Symptom.** The agent answers a specific question with a generic reply. A user asks why a Case was escalated and gets "the issue was reviewed and addressed" instead of the actual reason. **Root cause.** Incomplete records. When the agent retrieves a Case with an empty Description, Comments, or Resolution field, it has no context to ground a specific answer. It falls back to a vague summary because there is nothing concrete to read. **Diagnosis.** Completeness Rate, broken down by field, shows how many records in the agent's scope are missing the fields it needs for context. A high overall score hides the problem if the empty fields are the ones the agent reads. Check Completeness on Description, Notes, Comments, and Resolution specifically. **Fix.** Raise Completeness on the fields the agent uses for responses. Backfill from a trusted source, make critical fields required at entry, and rerun the scan to confirm. See [Completeness](/resources/data-quality/completeness/) for the field-level diagnostic flow. ## Why Does Agentforce Contradict Itself Across Conversations? **Symptom.** The same question returns different answers in different sessions, or two users get conflicting facts about the same account. **Root cause.** Inconsistent values and duplicate records. When the Country field holds "US", "USA", "United States", and "U.S.A.", the agent treats them as four distinct values and segments its answers by whichever it retrieved. When two Account records describe the same company with different data, the agent answers from whichever one it found first. **Diagnosis.** Conformance Rate measures how many values match your canonical set, so a low rate exposes fragmented picklist and reference fields. Duplicate Rate measures how many records are duplicates of another, which is the second half of this failure. Run both across the objects the agent reads. **Fix.** Standardize values to a controlled set and merge duplicates. Use Import from Field in the Definition Builder to discover the variants already in your data, define the canonical value, and normalize. Then merge duplicate records and configure matching rules to block new ones. See [Consistency](/resources/data-quality/consistency/) and [Uniqueness](/resources/data-quality/uniqueness/). ## Why Does Agentforce Return Outdated Information? **Symptom.** The agent reports a closed deal as open, names a contact who left the company a year ago, or quotes a price from a superseded record. **Root cause.** Stale records. The agent has no concept of "old." It reads the most relevant record by content match, regardless of when the data was last touched. A record that has not been updated since the facts changed feeds the agent obsolete context. **Diagnosis.** Timeliness Rate measures how many records fall within a freshness threshold you define on a date field such as LastModifiedDate or a business date. A declining Timeliness Rate on the agent's objects means the agent is increasingly likely to surface outdated facts. See [Timeliness](/resources/data-quality/timeliness/). **Fix.** Flag records past your freshness threshold and route them to re-engagement or archival workflows. Archive or exclude records that should no longer inform answers, so the agent stops retrieving them. Schedule the Timeliness scan to repeat so staleness stays visible. ## Why Does Agentforce Surface Sensitive Data It Should Not? **Symptom.** A generated response includes a Social Security Number, a credit card number, or another piece of PII that has no business appearing in agent output. **Root cause.** PII sitting in free-text fields. Email-to-case, chat transcripts, and manual notes capture personal data into Description and Comments fields. When the agent retrieves one of those records, the PII enters the AI context and can appear in a response. **Diagnosis.** PII Exposure Rate measures how many records in scope contain detectable PII across your text fields. Scan every text field the agent can read, not the fields named for PII, because the exposure hides in general-purpose comment and description fields. See [PII Detection](/resources/ai-readiness/pii-detection/). **Fix.** Identify findings with a PII scan, then mask, delete, or restrict the confirmed matches. Configure per-field pattern overrides for fields where a matching pattern is expected and legitimate, so you act on real exposure. Rerun the scan to validate, and review the [PII compliance guide](/resources/ai-readiness/agentforce-pii-compliance/) before deployment. ## Why Can't Agentforce Find the Right Record? **Symptom.** The agent reports it cannot find a customer who exists, or retrieves the wrong record entirely. A user searches by email and the agent returns nothing. **Root cause.** Invalid formats and unsearchable values. An email stored as "john [at] company dot com", a phone number with inconsistent punctuation, or an ID in the wrong format does not match the lookup the agent runs. The record is there, but the agent cannot resolve it. **Diagnosis.** Validity Rate measures how many values pass the format rules you define on structured fields such as email, phone, and identifiers. A low Validity Rate on a key lookup field predicts retrieval failures. See [Validity](/resources/data-quality/validity/). **Fix.** Mass-correct malformed values on the fields the agent searches, then add a validation rule to enforce the format on new records. Focus on the fields that drive lookups and matching, where a format error breaks retrieval outright rather than just degrading a response. ## Why Do Agentforce Answers Get Worse Over Time? **Symptom.** The agent performed well at launch and degrades over weeks. Vague answers, contradictions, and stale facts reappear after a clean deployment. **Root cause.** Data quality regression with no monitoring. Records you cleaned before launch decay as users enter new data, integrations write new records, and the agent itself updates fields. A one-time cleanup is a snapshot, and the snapshot ages out. **Diagnosis.** No single metric catches regression. You catch it by trend. Schedule recurring scans across all six dimensions and watch each rate as a line over time, so a dip surfaces within days of a new integration or process change introducing bad data. See [Understanding Results](/resources/using-dqs/understanding-results/). **Fix.** Configure scheduled, recurring scans on the objects in the agent's scope and track metric trends in Insight Studio. Set a cadence by risk: weekly PII scans on high-volume text fields, monthly Completeness and Consistency, a quarterly full scan. Catch regression on the dashboard before it reaches an answer. ## Symptom-to-Fix Reference | Symptom | Root cause | DQS metric | Fix | |---|---|---|---| | Vague or generic responses | Incomplete records (empty Description, Notes) | Completeness Rate | Backfill context fields; require them at entry | | Contradictory answers across conversations | Inconsistent values and duplicate records | Conformance Rate, Duplicate Rate | Standardize values; merge duplicates; add matching rules | | Outdated information | Stale records | Timeliness Rate | Flag and archive records past a freshness threshold | | Surfaces sensitive data | PII in free-text fields | PII Exposure Rate | Scan text fields; mask, delete, or restrict findings | | Cannot find the right record | Invalid formats, unsearchable values | Validity Rate | Mass-correct formats; add validation rules on lookup fields | | Answers degrade over time | Data quality regression, no monitoring | All six (trend) | Schedule recurring scans; track trends in Insight Studio | ## How to Run This Diagnosis Run a DQS scan across every object the agent reads and review the six metrics together. The scan runs entirely inside Salesforce, so no data leaves the org. Match each weak metric to its symptom in the table above, remediate in priority order, and schedule the scan to repeat so the fix holds. For the full preparation workflow, see the [data cleanup guide for Agentforce](/resources/ai-readiness/salesforce-data-cleanup-for-agentforce/). ## Next Steps - [Agentforce Data Quality](/resources/ai-readiness/agentforce-preparation/): the full preparation guide and timeline - [Agentforce Data Readiness Checklist](/resources/ai-readiness/agentforce-data-readiness-checklist/): pre-deployment verification - [Salesforce Data Cleanup for Agentforce](/resources/ai-readiness/salesforce-data-cleanup-for-agentforce/): the remediation workflow - [Agentforce Data Quality FAQ](/resources/ai-readiness/agentforce-data-quality-faq/): common questions answered - [The Five Dimensions](/resources/data-quality/five-dimensions/): overview of every data quality dimension - [AI Readiness Assessment](/ai-readiness/): get your current readiness score # Salesforce Data Cleansing: A Complete Guide > How to clean Salesforce data end to end: audit first, then deduplicate, standardize, complete, refresh, and secure — and the prevention that keeps it clean. Source: https://dataqualitysense.com/resources/salesforce/salesforce-data-cleansing/ Last updated: 2026-07-23 --- Every Salesforce org accumulates sediment: duplicate accounts from list imports, contacts whose owners left two jobs ago, Industry fields holding seventeen spellings of "Financial Services," phone numbers in five formats, and PII pasted into description fields where no one intended it to live. Data cleansing is the systematic removal of that sediment — and done properly, it is a sequenced program, not a heroic weekend with a spreadsheet. This guide covers the full sequence: audit, prioritize, then six cleansing operations in the order that makes each one easier, and the prevention layer that keeps you from doing it all again next year. ## Before You Clean: Audit and Prioritize Cleansing without measurement is guesswork with extra steps. Start with a baseline: [measure your data quality](/resources/salesforce/measure-data-quality-in-salesforce/) across the [six dimensions](/resources/data-quality/five-dimensions/) to learn which objects are worst, which fields drive the failures, and how big the backlog actually is. Two rules of thumb for scoping what the audit surfaces: - **Clean by business impact, not by alphabet.** The fields that feed forecasting, routing, and reporting come first. A blank Industry on active pipeline matters; a blank fax number does not. - **Fix causes before symptoms where you can.** If an integration writes malformed values daily, cleaning its output before stopping the source is bailing with the tap open. ## The Six Cleansing Operations ### 1. Deduplicate Duplicates first, because every other operation is wasted on records you are about to merge. The native toolkit: **matching rules** define what counts as the same Account or Contact (exact or fuzzy), **duplicate jobs** find existing pairs at scale, and **merge** consolidates them while keeping related activities, opportunities, and cases. Merging is judgment work — which values survive, which owner keeps the record — so route candidate pairs through someone who knows the accounts, not a blind bulk job. For large backlogs, a dedicated deduplication tool from the [Salesforce data quality tool landscape](/resources/salesforce/salesforce-data-quality-tools/) pays for itself in matching sophistication. ### 2. Standardize Inconsistent values break grouping everywhere downstream — reports, territories, automations. The pattern: pick the canonical value list, bulk-update existing records to it, and convert the field from free text to a **picklist** so the drift cannot recur. Standardize country and state values (state and country picklists exist natively), naming conventions, and the handful of fields your reporting groups by. This is the highest-leverage operation per hour spent: one afternoon on one field can fix every report that groups by it. ### 3. Complete For [missing values](/resources/data-quality/completeness/), work from most trustworthy source to least: internal systems you already run (billing, product, marketing automation often hold what the CRM lacks), then enrichment providers for firmographics, then — last — asking the record owner. Bulk-fill with Data Loader or Data Import Wizard once you have the source. Resist the urge to fill fields no process reads; completeness of unused fields is cosmetics. ### 4. Refresh or archive stale records Contact data goes stale at about [2.1% per month](https://pipeline.zoominfo.com/marketing/b2b-data-decay), so [timeliness](/resources/data-quality/timeliness/) is a permanent workstream, not a one-off. Define freshness thresholds per object — say, Contacts untouched for 18 months, Opportunities with Close Dates six months in the past — then split what crosses them: re-engage or re-verify what still matters, archive the rest out of active views. Deleting is rarely necessary; getting stale records out of reports, routing, and AI retrieval usually is. ### 5. Fix invalid formats Emails without @, phone numbers with letters, dates that cannot parse — [validity](/resources/data-quality/validity/) failures are the most mechanical fix: find with a report or scan, correct in bulk, then lock the format with a **validation rule** so the same malformation bounces at entry next time. Formats without validation rules regress within weeks. ### 6. Secure exposed PII Cleansing is the natural moment to deal with sensitive data sitting where it should not be — personal identifiers pasted into description and notes fields. Find it with [PII detection](/resources/ai-readiness/pii-detection/), then mask, move, or delete per your compliance rules. This step becomes non-optional before any AI rollout: an agent will read whatever the record holds. If Agentforce is the driver for your cleanup, the [object-by-object cleanup guide](/resources/ai-readiness/salesforce-data-cleanup-for-agentforce/) sequences this work for AI readiness specifically. ## Bulk Tooling, Briefly **Data Loader** (and third-party loaders) for mass update, upsert, and export-fix-reimport cycles; **Data Import Wizard** for smaller, simpler loads with built-in duplicate handling; **Flow** for ongoing transformations; reports for surfacing the work queues. Whatever the tool: export a backup before every bulk operation, test on a sandbox or a 50-record slice first, and keep an audit trail of what changed. A bulk fix applied wrong is just bad data with better formatting. ## Keep It Clean: Prevention and Cadence A cleanup without prevention has a half-life of months. As each operation finishes, install the control that stops the reissue: duplicate rules behind the dedup, picklists behind the standardization, validation rules behind the format fixes, required fields behind the completeness work — the full set is covered in [How to Improve Data Quality in Salesforce](/resources/salesforce/improve-data-quality-in-salesforce/). Then put the whole thing on a schedule. Re-scan weekly or monthly, watch the trend, and treat a dipping score as an early warning, not a quarterly surprise. The 1-10-100 economics of data errors reward catching problems while they are cheap. ## How DQS Helps Data Quality Sense runs the audit that scopes the cleanup and the monitoring that protects it. Scans score every dimension covered above — completeness, consistency, timeliness, uniqueness, validity, and PII exposure — down to the field level, entirely inside Salesforce, so your prioritized work queue comes from evidence rather than instinct. After the cleanup, scheduled scans in Insight Studio turn the score into a trend line, and the Mentor Panel points at what to fix next. The cleansing itself stays in your hands and your tools; DQS tells you where to aim and whether it worked. ## FAQ **What is Salesforce data cleansing?** Data cleansing is the systematic correction of the records already in your org: merging duplicates, standardizing inconsistent values, filling or sourcing missing fields, refreshing or archiving stale records, fixing invalid formats, and securing exposed PII. It differs from prevention, which stops new bad data at entry — a durable program needs both. **How do I clean up duplicate records in Salesforce?** Configure matching rules to define what counts as a duplicate, run duplicate jobs (or a deduplication tool) to find existing ones, and merge them — native merge for Accounts, Contacts, and Leads keeps the related history. Then set duplicate rules to block or alert on new duplicates at entry, or the same records will be back within a quarter. **How often should Salesforce data be cleaned?** Continuously, not annually. Contact data decays at roughly 2% per month, so a yearly cleanup spends most of the year out of date. The workable cadence is a measured baseline, an initial focused cleanup, prevention rules to slow new decay, and scheduled scans — weekly or monthly — that catch regressions while they are small. ## Next Steps - [How to Measure Data Quality in Salesforce](/resources/salesforce/measure-data-quality-in-salesforce/): the audit that scopes the cleanup - [Salesforce Data Quality Tools](/resources/salesforce/salesforce-data-quality-tools/): native features vs. third-party, by layer - [Salesforce Data Cleanup for Agentforce](/resources/ai-readiness/salesforce-data-cleanup-for-agentforce/): the AI-driven variant, object by object - [The Real Cost of Bad Salesforce Data](/resources/salesforce/cost-of-bad-salesforce-data/): the business case for doing this at all # Agentforce and PII: Protecting Sensitive Data Before AI Deployment > Agentforce reads PII hidden in Salesforce text fields. Learn how to find and remediate sensitive data before deployment to reduce compliance risk. Source: https://dataqualitysense.com/resources/ai-readiness/agentforce-pii-compliance/ Last updated: 2026-06-12 --- When Agentforce retrieves a record, everything in the fields it reads enters the AI context. That includes any personally identifiable information (PII) hiding in free-text fields, even when those fields were never meant to hold sensitive data. A Social Security Number pasted into a case comment becomes part of what the agent reads, reasons over, and can surface in a generated response. This guide explains how PII reaches the Agentforce context, where it accumulates in Salesforce, and how to find and remediate it before go-live. It builds on two related guides: the [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/) hub for full deployment readiness, and [PII Detection](/resources/ai-readiness/pii-detection/) for how DQS pattern matching works. ## How Does PII Enter the Agentforce Context? Agentforce agents follow a consistent flow: they retrieve Salesforce records, ground their reasoning in the field values they read, and generate a response from that context. PII enters at the retrieval step. The agent does not distinguish between a field meant for sensitive data and a free-text field where sensitive data landed by accident. It reads both. Three sources fill text fields with PII over time: - **Email-to-case.** Incoming messages get captured into Case Description and Comments verbatim. Customers include SSNs, account numbers, and card details when they describe a problem. All of it lands in a text field. - **Support and sales notes.** Agents paste identity-verification details, payment information, and contact data into notes during a call. The note persists long after the interaction. - **Imported and integrated data.** Migrations and integrations write contact details, dates of birth, and identifiers into description and comment fields where no validation runs. Once that data sits in a retrievable field, any agent scoped to read the object can pull it into context. The exposure exists before you deploy a single agent. Deployment turns a dormant data problem into an active one. ## Where Does PII Hide in Salesforce? PII concentrates in unstructured text fields. Structured fields (Email, Phone) contain PII by design and are governed accordingly. The risk lives in the free-text fields users treat as scratch space. | Object | High-Risk Fields | Why It Accumulates | |--------|-----------------|--------------------| | Case | Description, Comments | Email-to-case writes customer messages verbatim | | Lead | Description | Imported lists and form submissions land here | | Contact | Description | Notes about verification and account details | | Account | Description | Relationship notes and billing context | | Task / Event | Description, Comments | Call notes capturing verification data | | Opportunity | Description | Deal notes referencing payment terms | | Note (Content) | Body | Free-form attachments to any record | Description and Comments fields on Case carry the highest risk because email-to-case feeds them automatically and at volume. Treat those two fields as your first priority in any scan. For the full set of where-it-hides scenarios, see [PII Detection Scenarios](/resources/use-cases/pii-detection-scenarios/). ## Which Regulations Apply? PII in retrievable fields can implicate the privacy and security frameworks your organization already operates under. The specifics depend on your data, your jurisdiction, and your contractual obligations, so treat the points below as a starting list to review with your compliance team, not legal advice. - **GDPR.** Principles such as data minimization and purpose limitation typically mean PII should not sit in fields beyond its intended use. An agent reading a birth date out of a description field may fall outside the purpose for which that data was collected. - **HIPAA.** Where protected health information (PHI) appears in support notes or case text, handling rules may apply to any system that processes those fields, including an AI agent. - **PCI DSS.** Card data in free-text fields typically falls under storage and handling requirements. Card numbers in Case Comments are a common and high-priority finding. Because DQS runs entirely inside Salesforce, scanning for PII does not create a new data transfer or move data to an external service. No data leaves your org. That keeps the discovery step itself out of scope for cross-border transfer and processor concerns. Confirm the regulatory mapping for your situation with your compliance team before deployment. ## How Do You Scan for PII With DQS? DQS scans text fields with eight predefined regex patterns and reports exposure as a single metric. Detection is deterministic and transparent: you see every pattern applied, and the same input always returns the same result. The eight patterns cover four categories: | Category | Patterns | |----------|----------| | Financial | Social Security Number, Credit Card Number, IBAN | | Contact | Email Address, US Phone Number, International Phone | | Technical | IP Address | | Identity | Date of Birth | Configure scans with three controls: - **Presets.** The **Critical** preset activates SSN and Credit Card only. Use it for a fast financial-PII check with near-zero false positives. The **Standard** preset adds Email and US Phone. The **Extended** preset runs all eight. - **Per-field overrides.** Apply different pattern sets to different fields. Scan an Email field for SSN and Credit Card only, since email matches there are expected. Scan Description and Comments with the full Extended set, since any PII type can appear. - **PII Exposure Rate.** This is the headline metric: the percentage of scanned records containing at least one pattern match. Pair it with the Records with PII count to scope your cleanup. Build a definition for each high-risk object in the [Definition Builder](/resources/using-dqs/running-scans/), point it at the Description and Comments fields, and run the Critical preset first to isolate financial PII. Then run Extended for a complete inventory. ## What Does the Remediation Playbook Look Like? A PII scan produces a list of matches. Remediation turns that list into resolved findings. Work through it in order. 1. **Review the matches.** Some patterns carry false-positive risk. Date of Birth matches any US-formatted date, and Credit Card can match long order numbers. Confirm each match before treating it as PII. Use the pattern category to triage: Financial findings come first. 2. **Decide the action per field.** For each confirmed finding, choose one of three responses: - **Mask.** Replace the sensitive value while keeping the surrounding text usable for the agent. - **Delete.** Remove the value where it serves no business purpose. - **Exclude the field from agent scope.** Where a field reliably holds PII the agent does not need, remove it from the agent's retrieval scope so the data never enters context. 3. **Rerun to validate.** After remediation, run the same scan again. Compare PII Exposure Rate against your pre-remediation baseline. The number confirms cleanup worked. For a structured cleanup sequence across all dimensions, follow the [Salesforce Data Cleanup for Agentforce](/resources/ai-readiness/salesforce-data-cleanup-for-agentforce/) guide. Excluding a field from agent scope is the fastest control when a field has no AI value. Masking and deletion address fields the agent still needs to read. ## Pre-Deployment PII Safety Targets Hold deployment until your data meets these targets on every text field Agentforce will access: - **PII Exposure Rate below 1%** on text fields in agent scope. - **Zero SSN matches** on Case Description and Comments. - **Zero credit card matches** on Case Description and Comments. - **Per-field overrides configured** for expected-content fields so Email and Phone fields do not inflate the rate. These thresholds come from the [Agentforce Data Readiness Checklist](/resources/ai-readiness/agentforce-data-readiness-checklist/). Get compliance team sign-off against them before go-live, and test agent responses on remediated data to confirm no PII appears in generated content. ## How Do You Keep PII Out After Go-Live? PII exposure is not a one-time cleanup. Email-to-case keeps writing customer messages into Case fields, and users keep pasting verification details into notes. A clean dataset accumulates new exposure within weeks. Schedule recurring scans to catch regression early: | Scan | Frequency | Objects | |------|-----------|---------| | PII Detection (Critical preset) | Weekly | Cases, Leads (high-volume text fields) | | PII Detection (Extended preset) | Monthly | All objects in agent scope | Track PII Exposure Rate over time so a rising trend triggers review before it reaches your agents. Weekly scans on Case and Lead cover the fields where new PII lands fastest. Assign ownership for reviewing findings so the scan results turn into action. Undetected PII is one of the most common reasons agents produce non-compliant output. For the broader failure patterns, see [Why Agentforce Agents Fail](/resources/ai-readiness/why-agentforce-agents-fail/). ## Next Steps - [PII Detection](/resources/ai-readiness/pii-detection/): the eight patterns, presets, and per-field configuration in detail - [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/): full deployment readiness across all six dimensions - [Agentforce Data Readiness Checklist](/resources/ai-readiness/agentforce-data-readiness-checklist/): the complete pre-deployment target list - [Agentforce Data Quality FAQ](/resources/ai-readiness/agentforce-data-quality-faq/): common questions on preparing data for agents - [AI Readiness Assessment](/ai-readiness/): score your current readiness # Salesforce Data Cleanup for Agentforce: Object-by-Object Guide > A field-level Salesforce data cleanup playbook for Agentforce. Which objects and fields to clean first for service and sales agents, mapped to DQS. Source: https://dataqualitysense.com/resources/ai-readiness/salesforce-data-cleanup-for-agentforce/ Last updated: 2026-07-15 --- Which Salesforce objects you clean first depends on which agents you deploy. Service agents read Case and Knowledge; sales agents read Lead, Opportunity, Account, and Contact. This guide covers the where of Salesforce data cleanup for Agentforce — the specific objects and fields to clean, the dimension at risk on each, and the cleanup actions to run. For the when — the four-phase timeline that surrounds this work — see [Agentforce Data Quality: Preparing Salesforce Data for AI](/resources/ai-readiness/agentforce-preparation/). This article fits inside Phase 2 of that timeline, where you remediate object by object. Run a [DQS scan](/resources/using-dqs/running-scans/) on each object before you start so you know which fields actually fail, rather than cleaning fields that are already fine. Cleanup at this level is not optional groundwork. In [Salesforce's State of Data and Analytics research](https://www.salesforce.com/news/stories/data-analytics-trends/), 84% of data and analytics leaders said their data strategy needs a complete overhaul before their AI ambitions can succeed. Object-by-object remediation is what that overhaul looks like in practice inside a CRM. ## Account Sales agents read Account to ground responses about a customer's industry, location, and relationship. When the agent answers "what do we know about this account," it draws from these fields. | Priority field | Dimension at risk | What bad data does to the agent | |---|---|---| | `Name` | Uniqueness | Duplicate accounts split history, so the agent retrieves a partial record | | `Industry` | Consistency | "Tech", "Technology", and "IT" read as three segments, breaking grounded answers | | `BillingCountry` | Consistency | "US", "USA", "United States" fragment geographic context | | `Phone` / `Website` | Validity | Malformed values produce unusable contact details in responses | Cleanup actions: - Run a Uniqueness scan to find duplicate Accounts before deployment. Duplicates teach the agent contradictory facts about the same customer. See [Uniqueness](/resources/data-quality/uniqueness/). - Use Import from Field on `Industry` and `BillingCountry` to discover every variant that exists, then define canonical values in the [Definition Builder](/resources/using-dqs/definition-builder/) and normalize. - Run a Validity scan on `Phone` and `Website` to catch malformed entries. Target fields where Validity Rate falls below 90%. ## Contact Agents read Contact to identify who they are dealing with and how to reach them. A sales agent drafting an outreach message pulls the name, title, and email from here. | Priority field | Dimension at risk | What bad data does to the agent | |---|---|---| | `Email` | Validity | Invalid addresses make agent-suggested outreach fail | | `Phone` | Validity | Malformed numbers surface as broken contact details | | `Title` | Completeness | Empty titles remove the role context the agent uses to personalize | | `MailingCountry` | Consistency | Inconsistent country values misroute region-specific answers | Cleanup actions: - Run a Validity scan on `Email` and `Phone`. These are the fields an agent acts on, so format errors turn into failed actions. See [Validity](/resources/data-quality/validity/). - Run a Completeness scan on `Title` and measure Completeness Rate. Missing titles strip the agent of the role context it needs to tailor a message. - Standardize `MailingCountry` with Import from Field, matching the canonical list you defined on Account so the two objects agree. ## Case Service agents work primarily from Case. The agent reads the Subject and Description to understand the issue, then grounds its reply in that context. This is the highest-leverage object for a service deployment. | Priority field | Dimension at risk | What bad data does to the agent | |---|---|---| | `Description` | Completeness | An empty Description leaves the agent no context, so it returns a generic reply | | `Subject` | Completeness | Missing subjects weaken case classification and routing | | `Status` / `Origin` | Consistency | Variant values fragment the agent's view of case state and channel | | `Description` / Comments | PII Detection | SSNs and card numbers pasted from email enter the AI context | Cleanup actions: - Run a Completeness scan on `Description`. Description completeness equals agent context; a blank field is the most common reason a service agent answers vaguely. See [Completeness](/resources/data-quality/completeness/). - Standardize `Status` and `Origin` using Import from Field to surface every existing value, then normalize to your canonical picklist. - Run a PII scan on `Description` and Case Comments. Email-to-case captures customer messages that contain PII, and the agent can surface that PII in a response. See [PII Detection](/resources/ai-readiness/pii-detection/) and the [Agentforce PII compliance guide](/resources/ai-readiness/agentforce-pii-compliance/). ## Lead Sales agents read Lead to qualify and route inbound interest. The agent decides next actions from the company, source, and status, so gaps here send leads down the wrong path. | Priority field | Dimension at risk | What bad data does to the agent | |---|---|---| | `Email` | Validity | Invalid addresses break agent-driven follow-up | | `Company` | Completeness | Missing company data blocks qualification logic | | `LeadSource` | Consistency | Inconsistent sources distort the agent's routing decisions | | `Status` | Consistency | Variant statuses confuse where the lead sits in the funnel | Cleanup actions: - Run a Validity scan on `Email` and a Completeness scan on `Company`. These two fields drive whether the agent can act on a lead at all. - Use Import from Field on `LeadSource` and `Status` to find drift, then constrain to a defined value set. See [Consistency](/resources/data-quality/consistency/). - Run a PII scan on any notes or description fields where reps paste raw inbound messages. ## Opportunity Sales agents read Opportunity to answer pipeline and forecast questions. A stale stage or missing amount produces a confidently wrong answer about deal status. | Priority field | Dimension at risk | What bad data does to the agent | |---|---|---| | `StageName` | Consistency | Non-standard stages misrepresent where deals stand | | `CloseDate` | Timeliness | Past close dates on open deals teach the agent outdated pipeline facts | | `Amount` | Completeness | Missing amounts distort any forecast the agent reports | Cleanup actions: - Run a Timeliness scan to flag open Opportunities with `CloseDate` in the past. Stale dates make the agent report a pipeline that no longer exists. See [Timeliness](/resources/data-quality/timeliness/). - Run a Completeness scan on `Amount`. An agent summarizing pipeline value cannot do so reliably when amounts are blank. - Confirm `StageName` matches your defined sales process with a Consistency scan. ## Knowledge Service agents ground answers in Knowledge articles. The agent retrieves an article and presents its content as the authoritative answer, so a stale or thin article becomes a wrong answer delivered with confidence. | Priority field | Dimension at risk | What bad data does to the agent | |---|---|---| | Last modified date | Timeliness | Stale articles produce outdated answers the agent presents as current | | `Title` / `Summary` | Completeness | Thin metadata weakens retrieval, so the agent cites the wrong article | | Article body | PII Detection | Embedded customer data can leak into a generated answer | Cleanup actions: - Run a Timeliness scan against the last modified date to surface articles past your freshness threshold. Outdated articles are the leading source of confidently wrong service answers. - Run a Completeness scan on `Title` and `Summary`. The agent uses these for retrieval, so weak metadata leads it to the wrong source. - Run a PII scan on the article body to confirm no customer-specific data was pasted into a published article. ## Which objects should you clean first? Clean the objects your agents actually read, in the order their answers depend on them. The matrix below maps cleanup priority to agent type. | Object | Service agent | Sales agent | Employee-facing agent | |---|---|---|---| | Case | Priority 1 | Low | Medium | | Knowledge | Priority 1 | Low | Priority 1 | | Account | Medium | Priority 1 | Medium | | Contact | Medium | Priority 1 | Medium | | Lead | Low | Priority 1 | Low | | Opportunity | Low | Priority 2 | Medium | For a service deployment, start with Case Description completeness and Knowledge timeliness, because those two fields determine whether the agent has correct context to answer from. For a sales deployment, start with Account and Contact, then move to Lead and Opportunity. Across every agent type, run PII scans first on the text fields the agent reads, since a PII finding is a compliance issue rather than a quality one. The [Agentforce data readiness checklist](/resources/ai-readiness/agentforce-data-readiness-checklist/) lists the pre-deployment thresholds to hit on each object. ## Next Steps - [Agentforce Data Quality: Preparing Salesforce Data for AI](/resources/ai-readiness/agentforce-preparation/): the four-phase timeline this cleanup fits inside - [Why Agentforce Agents Fail](/resources/ai-readiness/why-agentforce-agents-fail/): the data problems behind unreliable agent output - [Agentforce Data Readiness Checklist](/resources/ai-readiness/agentforce-data-readiness-checklist/): pre-deployment thresholds per object - [How to Improve Data Quality in Salesforce](/resources/salesforce/improve-data-quality-in-salesforce/): the detect, fix, prevent, monitor loop - [Agentforce Data Quality FAQ](/resources/ai-readiness/agentforce-data-quality-faq/): common questions answered - [AI Readiness Assessment](/ai-readiness/): get your current readiness score # Agentforce Data Quality: Frequently Asked Questions > Answers to common Agentforce data quality questions: does Agentforce need clean data, what data it reads, readiness thresholds, PII risk, and how to prepare. Source: https://dataqualitysense.com/resources/ai-readiness/agentforce-data-quality-faq/ Last updated: 2026-07-15 --- Teams ask the same questions before connecting Agentforce to their Salesforce data. This page answers ten of them directly. Each answer is built for quick reference and links to deeper guidance where you need it. ## Does Agentforce need clean data? Yes. Agentforce needs clean data because agents ground their responses in the Salesforce records they retrieve. An agent works with whatever it finds in the fields within its scope. When those fields are incomplete, inconsistent, or invalid, the agent produces incomplete, inconsistent, or invalid outputs. Clean data is the difference between an agent that helps users and one that misleads them. The stakes are documented: [Gartner predicted in 2024](https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025) that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, with poor data quality among the leading causes. See [why Agentforce agents fail](/resources/ai-readiness/why-agentforce-agents-fail/) for the specific failure modes poor data creates. ## What data does Agentforce use? Agentforce uses your Salesforce records. Agents retrieve information from objects you grant them, generate responses based on that data, and take actions on behalf of users. The fields that matter most for response quality are free-text fields such as Description, Comments, and Notes, along with picklists and reference fields that drive context. If a field sits in an agent's scope, its contents become input to the agent's answers. For the full picture of how CRM data feeds AI, read [Data Quality in Salesforce](/resources/salesforce/data-quality-in-salesforce/). ## How do I know if my Salesforce data is ready for Agentforce? You know your data is ready when it meets defined readiness thresholds across completeness, consistency, validity, and PII exposure. Readiness is measurable, not a feeling. Run a DQS scan across every object an agent will access, record a baseline rate for each dimension, and compare those rates against your targets. The [Agentforce data readiness checklist](/resources/ai-readiness/agentforce-data-readiness-checklist/) walks through each item you confirm before deployment. ## What happens if Agentforce reads incomplete records? When Agentforce reads incomplete records, it generates vague or generic responses because it has no context to draw from. An empty Description field gives the agent nothing specific to reference, so it falls back on broad language that adds little value. The problem scales with volume. Completeness Rate tells you how many records carry this gap across the fields an agent uses, so you can prioritize the worst fields first. Completeness is the first of the [five data quality dimensions](/resources/data-quality/five-dimensions/). ## Can Agentforce expose PII? Yes. Agentforce can surface personally identifiable information that exists in the Salesforce fields it reads. PII hides in free-text fields where users paste customer communications. Email-to-case, for example, captures Social Security Numbers and credit card numbers from incoming messages and stores them in Case Description and Comments. When an agent retrieves one of those records, the PII enters the AI context and can appear in a generated response. DQS [PII Detection](/resources/ai-readiness/pii-detection/) ships eight patterns to find this data, and the [Agentforce PII compliance](/resources/ai-readiness/agentforce-pii-compliance/) guide covers how to handle it. ## How do I measure Salesforce data quality before deploying Agentforce? You measure Salesforce data quality with DQS, which scans your records inside Salesforce and reports a rate for each dimension. In Definition Builder, select the objects and fields an agent will access, then run a scan. Insight Studio returns Completeness Rate, Conformance Rate, Validity Rate, Timeliness Rate, Duplicate Rate, and PII Exposure Rate for that scope. The entire scan runs in your org, so no data leaves Salesforce. For a step-by-step method, see [how to measure data quality in Salesforce](/resources/salesforce/measure-data-quality-in-salesforce/). ## How clean does my data need to be? Aim for a Completeness Rate of 85% or higher on key fields, a Conformance Rate of 90% or higher on picklist and reference fields, a Validity Rate of 90% or higher on structured fields, and a PII Exposure Rate below 1% on text fields. These thresholds give agents enough complete, consistent, and valid data to respond reliably while keeping sensitive data out of the AI context. Raise the targets for regulated or customer-facing fields where errors carry more risk. The [Agentforce preparation guide](/resources/ai-readiness/agentforce-preparation/) explains how to validate each rate against these targets before go-live. ## How long does data preparation for Agentforce take? Plan roughly three months for data preparation before go-live. Run your assessment about three months out to establish baselines. Complete remediation about two months out, working through PII first, then completeness and consistency. Validate about one month out by rerunning every scan and comparing the new rates against your baselines. After deployment, move into ongoing monitoring. Org size and the number of objects in scope shift the timeline, but the sequence holds. For the remediation phase in detail, see [Salesforce data cleanup for Agentforce](/resources/ai-readiness/salesforce-data-cleanup-for-agentforce/). ## Does data quality monitoring matter after go-live? Yes. Data quality monitoring matters after go-live because data degrades as users enter new records. A dataset you cleaned for launch accumulates fresh gaps, inconsistencies, and PII within weeks. One-time remediation does not hold. Schedule recurring DQS scans, weekly for high-volume text fields and monthly for objects in agent scope, and track the metric trends. Regular scanning catches regression early, before it reaches your agents and reaches your users. ## What is the difference between data quality and data readiness? Data quality measures whether your records are fit for their intended purpose. Data readiness measures whether those same records are prepared for a specific use, in this case Agentforce. Readiness builds on the five data quality dimensions and adds one concern that traditional quality work ignores: sensitive data exposure. A record can be complete, consistent, and valid yet still hold a Social Security Number that an agent must never surface. Readiness combines both checks. Start with the foundation in [what is data quality](/resources/data-quality/what-is-data-quality/). ## Next Steps - [Agentforce Preparation](/resources/ai-readiness/agentforce-preparation/): the full phase-by-phase readiness guide - [Agentforce Data Readiness Checklist](/resources/ai-readiness/agentforce-data-readiness-checklist/): confirm every item before you deploy - [PII Detection](/resources/ai-readiness/pii-detection/): find sensitive data before agents can read it - [Measure Data Quality in Salesforce](/resources/salesforce/measure-data-quality-in-salesforce/): run your first baseline scan - [AI Readiness Assessment](/ai-readiness/): get your current readiness score in 3 minutes