Salesforce Data Architect Mock Exam: Key Concepts by Domain

Lookup vs. Master-Detail: Master-detail cascades deletion, inherits the parent's sharing, and unlocks roll-up summaries; a required lookup still blocks parent deletion while keeping separate sharing models, the answer whenever child objects need their own visibility.

Independent-Visibility Children: Objects like an Account Plan that must be shared differently from Account get a lookup relationship plus a validation rule to enforce the association, never master-detail.

Junction Objects & Hierarchies: Two master-details on one custom object model many-to-many; self-relationships and standard hierarchies cover multi-level structures like conference sessions and venues.

Person Accounts: The standard feature for consumer (B2C) models, merging account and contact into one record. Know when they beat a plain Contact model and their storage and sharing implications at millions of records.

Standard First, Custom Second: Extend standard objects and use record types for categorization (Gold/Silver/Bronze customers) before inventing custom objects; custom is for genuinely new entities like product designs or shipments.

Keep External Data External: External objects via Salesforce Connect virtualize ERP or IoT data on demand instead of copying millions of rows into the org, the right call when data is mastered elsewhere and needed only for viewing.

Matching & Duplicate Rules: Native matching rules define what counts as a duplicate; duplicate rules block or alert at entry. AppExchange dedup apps add fuzzy matching and mass merge. 'Two reps called the same customer' is always a duplicate-records symptom.

Measuring Quality: Data quality dashboards and report packs score completeness and consistency; enrichment and cleansing should run on a schedule with monitored metrics, not as a one-time fix.

Golden Records: When multiple sources feed customer data, define survivorship rules that decide which system's value wins per attribute, then standardize before load.

Archive Before You Delete: Identify records untouched for years, archive them to an enterprise data warehouse or big objects, then remove them with Bulk API hard delete so they skip the recycle bin.

Where History Lives: Big objects keep billions of rows queryable on-platform (async SOQL) for compliance-grade history; off-platform archives fit data that is rarely accessed; both beat paying for storage you never query.

Selectivity Wins: Indexed fields plus bounded filters make queries selective; custom indexes on common filter fields and formula fields that avoid cross-object joins are the standard fixes for reports that time out.

Skinny Tables: Fast because they exclude soft-deleted records, avoid joins, and stay auto-synced with their source tables. The go-to for wide objects like a Case object with 80 fields and 30 million rows.

PK Chunking: Splits a 100-million-record extract into ID-ranged batches processed in parallel through the Bulk API, avoiding the timeouts a single monster query would hit.

Big Objects: The on-platform answer for 100M+ records; created through the Metadata API or the Big Object setup page, never through Object Manager or DX.

Ownership & Sharing Skew: Load with an integration user holding no role (or the top role) to minimize sharing recalculation, and use Defer Sharing Rules during mass group or role changes to dodge lock contention.

Serial vs. Parallel Bulk API: Parallel mode is faster until child records hit the same parents; then locks pile up. Load parents first, sort children by parent ID, and switch to serial mode when lock exceptions persist.

Turn Off What Fights You: Disable validation rules, triggers, and automation not designed for loads, and defer sharing calculation for big cutovers; re-enable and recalculate once the load is verified.

External IDs: Upsert against a unique external ID to avoid duplicates across repeated loads; at very large volume, splitting into separate insert and update jobs is faster than upsert's conflict resolution.

Preserving History: 'Set Audit Fields upon Record Creation' keeps original created/modified dates; 'Update Records with Inactive Owners' preserves legacy ownership, the two permissions behind every migration-fidelity question.

Cleanse Before Load: Profile and standardize legacy data (formats, duplicates, orphans) in a staging area before it touches Salesforce; fixing it in-org after the fact is always the wrong answer.

Data Classification Metadata: Built-in field-level classification (data owner, sensitivity level, compliance categorization) on standard and custom objects, the declarative backbone of a GDPR classification policy.

Consent Tracking: The Individual object stores privacy and contact preferences with built-in relationships to leads, contacts, person accounts, and users, so consent lives in one standard place.

Layered Auditing: Setup Audit Trail for configuration changes, Field History Tracking for record values (with a per-object field cap; Field Audit Trail via Shield extends it), and Event Monitoring for user actions like report exports.

Encryption Choices: Classic encrypted fields are custom-text-only with heavy functional limits; Shield Platform Encryption covers standard fields while preserving most functionality, the compliance-grade default.

Program First Steps: A governance program aims at data integrity and usability: start with executive sponsorship for the enterprise data strategy, then assess current systems and data models with business and IT.

MDM as Customer Master: A dedicated MDM hub with centralized integrations fixes cross-system inconsistency; improving point-to-point links or one-time syncs never does, because drift resumes immediately.

Survivorship Rules: Golden-record consolidation defines which system's value wins per attribute when Billing, Support, and CRM all hold different versions of the same customer.

One System of Record per Entity: Declare which system owns each entity (Salesforce for leads, the OMS for orders, the ERP for invoices) and make every other system a consumer through a canonical data model.