10.3 Data Quality and Analytics Integrated Lab

Lab scenario: clean data before executive reporting

An executive team wants a weekly revenue dashboard, but the current org has duplicate accounts, inconsistent industry values, missing opportunity next steps, and stale close dates. Sales managers do not trust the numbers. The admin must create a cleanup plan, apply data controls, import corrected values, and build reports that expose both pipeline and data quality exceptions. This lab is about judgment: sometimes the right admin answer is to delay a dashboard until the source data is fit for purpose.

Start by profiling the data. Use reports, list views, and exports to identify missing values, duplicate patterns, inactive owners, invalid picklist values, and records outside expected date ranges. Create reports such as Opportunities with Close Date in the Past and Not Closed, Accounts Missing Industry, Opportunities Missing Next Step, Contacts Without Email, and Accounts Created This Month by Source if fields allow. Export samples for offline review only when the data handling location is approved. Expected observation: you can describe the data quality problem with counts, owners, and business impact.

Failure mode: users argue from anecdotes because no one quantified the issue.

Design controls in layers. Use Setup > Duplicate Management for matching rules and duplicate rules when the problem is likely duplicate records. Use Object Manager > Object > Validation Rules when the organization has a hard business rule at save time. Use required fields when the value is always mandatory for the object, and Dynamic Forms or page layout requiredness when the requirement is more about a specific user interface. Use picklists, restricted values, and dependent picklists when consistency matters. Use reports and dashboards when the right answer is monitoring, not blocking.

Build a duplicate rule lab using accounts. Create a matching rule that compares Account Name and Billing Postal Code, then a duplicate rule that warns or blocks depending on risk. In a practice org, create two similar accounts and observe whether the warning appears. Then test a legitimate exception, such as two branches with similar names but different postal codes. Expected observation: the rule catches likely duplicates without blocking obvious legitimate records. Failure mode: fuzzy matching is treated as proof, and users cannot create valid records.

Build validation rules sparingly. For example, require Next Step when an opportunity is open and Amount is above a threshold, or require Loss Reason when Stage is Closed Lost. Test with a sales rep, a manager, an import update, and an automation path if one exists. Good error messages tell users what to fix. Weak messages say only invalid value or contact your admin. Keep a register of active validation rules, the business owner, the exception path, and the last reviewed date. This matters when integrations or new processes arrive later.

Plan the cleanup import. Before changing data, export the affected records with IDs and current field values. Create a corrected CSV with only fields that should change. Use a small test update in a sandbox or Trailhead Playground if possible. For production-like work, use Data Loader when record IDs, external IDs, larger volumes, or repeatable mappings are needed. Save success and error files. Expected observations include changed records, rejected bad rows, and no unexpected automation side effects.

Failure modes include overwriting fields with blanks, changing the wrong records because of name matching, and triggering email alerts or flows unintentionally.

Build analytics after controls and cleanup are understood. Choose the right report type first. Standard opportunity reports may be enough for pipeline, while account with opportunities or custom report types are needed when the question spans parent and child records. Apply filters intentionally: open pipeline, close date range, owner role, stage, record type, and amount thresholds. Group rows by Stage and Owner, summarize Amount, and add conditional highlighting where useful. Create a data quality dashboard alongside the executive revenue dashboard so managers see the work needed to keep numbers reliable.

Test sharing. Put reports in a folder shared to sales managers and executives. Decide whether dashboards should run as a specific user or as the logged-in user, depending on whether leaders need a common executive view or each viewer should see only their own accessible records. Then compare dashboard totals with a known export or source report. If numbers do not match, investigate report type, filters, row limits, dashboard component settings, folder access, running user, role hierarchy, sharing rules, and whether records are owned by inactive users.

Review prompts before the quiz:

• Which data issues should be blocked at save time and which should be reported for cleanup?
• What export would you keep before a bulk update, and why?
• Which dashboard components are vulnerable to record sharing differences?
• How do duplicate rules and validation rules solve different problems?
• How would you explain to executives that a dashboard is not ready until source data is corrected?