Data-Architect Practice Test Questions

Use the Consent Management Feature to validate consent provide under the person Account and Contact that is provided by the customer.

Explanation:

Option C (✔️ Best Practice) – Salesforce’s native Consent Management feature (part of Data Protection & Privacy) is designed for GDPR compliance and:
1. Centralizes consent tracking for Person Accounts and Contacts (using the Individual object).
2. Automates validation (e.g., checks ConsentDate and ExpirationDate before emails/calls).
3. Integrates with Marketing Cloud and Service Cloud for enforcement.

Why Not the Others?

Option A (❌ Manual & Risky) – Custom fields work but lack automation (e.g., no expiration checks) and require custom code for validation.
Option B (❌ Redundant) – A custom object duplicates the Individual object’s functionality and adds maintenance overhead.
Option D (❌ Non-Compliant) – Deleting data violates GDPR’s "right to access" (records must be retained for audits).

Explanation:

Option B (✔️ Sustainable Solution) – This approach:
1. Standardizes the process: Provides clear guidelines for mapping Excel columns to Salesforce fields (e.g., "Excel 'Deal Size' → Salesforce 'Amount'").
2. Empowers users: Training sales teams to self-import data (via Data Import Wizard or Data Loader) reduces dependency on IT.
3. Encourages adoption: Users retain control over their data while transitioning to Salesforce.

Why Not the Others?

Option A (❌ Fragile) – Excel connectors require manual file maintenance and risk data silos (e.g., outdated/local Excel files).
Option C (❌ Counterproductive) – External databases defeat the purpose of Salesforce and create new silos.
Option D (❌ Inefficient) – Uploading Excel files to Chatter does not migrate data to Salesforce objects.

Partner community.

Explanation:

Option D (✔️ Best Fit) – Partner Community licenses are designed for external resellers and support:
1. Authentication: Secure logins for partners/resellers.
2. Access to Leads, Opportunities, Orders: Full CRUD access (critical for channel sales).
3. Reports & Dashboards: Run and customize reports (not available in lighter licenses).
4. Custom Objects: Supports up to 10 custom objects (matches requirements).

Why Not the Others?

Option A (❌ Too Limited) – Customer Community lacks Opportunity/Order access and reporting features.
Option B (❌ Not a Portal) – Lightning External Apps Starter is for limited API access, not full portal UIs.
Option C (❌ Partial Fit) – Customer Community Plus grants more access than standard Customer Community but still lacks Opportunity/Order access for partners.

Create a custom field as external id to maintain the customer Id from the MDM solution.

Explanation:

Option D (✔️ Best Practice) – Using the MDM’s customer ID as an external ID in Salesforce ensures:
1. Single Source of Truth: MDM is the authoritative system for customer identity.
2. Cross-System Sync: Salesforce and other systems (contracts, marketing) can reference the same ID.
3. Integration Flexibility: Enables easy matching during data loads (e.g., using upsert with the external ID).

Why Not the Others?

Option A (❌ Salesforce-Centric) – Storing Salesforce IDs in other systems creates dependency on Salesforce (MDM should own the master ID).
Option B (❌ Overhead) – A cross-reference object adds complexity and risks sync delays.
Option C (❌ Redundant) – Creating a new database for IDs contradicts the purpose of an existing MDM.

Use selective queries to reduce the amount of data being returned.

De-normalize the data by reducing the number of joins.

Reduce the amount of data queried by archiving unused opportunity records.

Explanation:

Option A (✔️ Query Optimization) – Selective queries use indexed fields (e.g., CreatedDate, AccountId) to avoid full table scans:
Example:
SELECT Id FROM Opportunity WHERE AccountId = '001xx00000123ABC' AND CloseDate = THIS_QUARTER
Avoid non-selective filters (e.g., Status = 'Open' if 90% of records match).

Option B (✔️ Reduce Joins) – De-normalize data to minimize complex joins across 100M+ records:
Flatten data (e.g., store AccountName directly on Opportunity to avoid Account joins).
Use formula fields or roll-up summaries (e.g., DLRS) for aggregated values.

Option E (✔️ Data Archival) – Archive old/unused opportunities (e.g., closed >5 years ago) to:
Reduce query volume (e.g., exclude archived records from dashboards).
Use Big Objects or external databases for historical data.

Why Not the Others?

Option C (❌ UI Fix, Not Root Cause) – Fewer widgets may slightly improve load time but won’t fix query timeouts.
Option D (❌ Workaround, Not Solution) – Email solves the CEO’s frustration but ignores systemic performance issues.

Data flows should be reviewed with the business users to determine the system of record per object or field.

Explanation:

✅ D. Review data flows with business users to determine the system of record per object or field

The system of record (SOR) is the authoritative source for a specific piece of data.

Business context is essential in deciding the SOR—it’s not just about where the data originates or which integration runs last.
Collaborating with business users helps identify:
1. Who owns the data
2. Which system has the most accurate or trusted version
3. What the operational workflows require
Often, different systems may be the SOR for different fields within the same object (e.g., billing address vs. sales territory on an Account).

Why Not the Others?

❌ A. Salesforce is the system of record because data originates there
Just because a record is created in Salesforce doesn’t mean Salesforce is the SOR for all its fields.
Fields may be updated or owned by ERP, accounting, or commission systems after creation.

❌ B. The system that updates a field is the system of record
The update source is not always authoritative—the field could be overwritten accidentally or reflect stale data.
You need intentional data governance, not just technical update logic.

❌ C. The last system to update determines the SOR
This is a technical coincidence, not a governance decision.
It can lead to data conflicts or overwrites if multiple systems update without coordination.

Key stakeholders should review any fields that share the same purpose between systems to see how they will be used in Salesforce.

Explanation:

Option B (✔️ Best Practice) – Stakeholder alignment ensures:
1. Field-Level Ownership: Clarifies which system "owns" specific fields (e.g., "Billing Address" from System A vs. "Shipping Address" from System B).
2. Business Rules: Matches field usage to operational needs (e.g., System A’s "Customer Tier" is used for reporting, System B’s for billing).
3. MDM Integration: MDM systems enforce these rules but require human-driven decisions first.

Why Not the Others?

Option A (❌ Hands-Off Risk) – MDM systems execute rules but can’t define them without stakeholder input.
Option C (❌ Technical Overfocus) – Schema reviews are useful, but field names ≠ ownership. Business context matters more.
Option D (❌ Chaotic) – Letting the "last sync win" guarantees conflicts and data corruption.

Stakeholders should be brought together to discuss the appropriate data strategy moving forward.

Explanation:

Option D (✔️ Best Practice) – Stakeholder alignment is critical because:
1. MDM Strategy May Need Refinement: If the new system has valuable data, the "Salesforce as system of record" rule might require exceptions (e.g., certain Opportunity fields).
2. Conflict Resolution Rules: Business teams must define which fields prioritize Salesforce vs. the new system (e.g., "Salesforce owns Stage, but the new system owns Contract Terms").
3. Governance: Ensures compliance and avoids ad-hoc fixes.

Why Not the Others?

Option A (❌ Rigid) – Blindly favoring Salesforce ignores potentially critical data in the new system.
Option B (❌ Arbitrary) – "Last update wins" risks losing authoritative data (e.g., Salesforce may have older but more accurate values).
Option C (❌ Violates MDM Strategy) – Overriding the MDM strategy without review creates inconsistency.

If reporting is necessary, can the information be aggregated into fewer, summary records?

Will the data being archived need to be reported on or accessed in any way in the future?

Are there any regulatory restrictions that will influence the archiving and purging plans?

Explanation:

✅ C. Can the data be summarized?
If the data is only needed for reporting purposes, it may not be necessary to store the entire dataset.
Instead, summary records or analytics snapshots could be retained for long-term trend reporting, reducing storage while retaining business value.

✅ D. Will the archived data need to be accessed or reported on?
This determines how and where the archived data should be stored:
If frequent access is required: consider archiving within Salesforce or via Salesforce Connect.
If rarely accessed: consider off-platform archiving (e.g., external database or data lake).

✅ E. Are there regulatory restrictions?
Compliance requirements (e.g., GDPR, HIPAA, SOX) may dictate:
How long data must be retained
Where it must be stored
When it must be deleted
These rules are essential to shape the retention and deletion policies in the strategy.

Why Not the Others?

❌ A. How many fields are defined on the custom objects?
While this may affect storage size, it is not a critical factor in determining the overall archiving strategy.
Archiving strategy is more concerned with data volume, access patterns, and regulatory rules.

❌ B. Which profiles and users have access?
User access might influence security controls for archived data but is not central to defining an archiving and purging plan.
It becomes relevant after the archive location and method are chosen.

Create a custom object to store aggregate data and run reports.

Explanation:

✅ A. Create a custom object to store aggregate data

With 30 million Case records and 80 fields, querying and reporting on the full dataset in real time can be slow and inefficient.
Creating a custom reporting or summary object that stores pre-aggregated metrics (e.g., cases per product, cases by status, weekly case volumes) allows:
1. Faster report execution
2. Reduced load on the Case object
3. Better user experience for agents needing quick insights
These summary objects can be updated on a scheduled basis (e.g., nightly via batch jobs or dataflows).

Why Not the Others?

❌ B. Enable Skinny Table
Skinny tables help improve query performance, but:
They are managed by Salesforce Support
They are limited in flexibility (e.g., no formula, lookup, or long text fields)
They don't solve aggregation/reporting needs effectively
They're more suited to record retrieval, not summary-level reports.

❌ C. Move data off-platform
Off-platform reporting may work but comes with significant complexity:
ETL processes
Sync challenges
Licensing and access control issues
This is a heavier architectural solution not ideal for frontline users like agents who need native access.

❌ D. Custom Lightning components for reports
Custom components may enhance UI presentation, but they do not solve the root performance issue with reporting on massive data volumes.
They still depend on underlying SOQL and report engine performance.