Plat-Arch-201 Practice Questions

A data dictionary documents the metadata, or "data about the data." An Entity Relationship Diagram (ERD) is a fundamental technique used to visually model the business entities, their attributes, and the relationships between them, forming the conceptual and logical basis of the dictionary. The Salesforce Metadata API is a programmatic tool used to retrieve the technical definitions of objects, fields, and other configurations directly from the Salesforce platform. Using the Metadata API allows for the automated extraction of the physical schema to populate and maintain the data dictionary, ensuring it accurately reflects the system's current state.

A. Salesforce Object Query Language (SOQL) is used to query and retrieve data records, not to define or describe the structure (metadata) of the data entities.

B. A data definition language (DDL) is the set of commands (e.g., CREATE TABLE) used to build the database structure, not a technique for documenting it in a dictionary.

1. Salesforce Developers, Metadata API Developer Guide - Introduction to Metadata API, "You can use Metadata API to retrieve, deploy, create, update, or delete customization information, such as custom object definitions... for your organization."

2. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2019). Database System Concepts (7th ed.). McGraw-Hill. Chapter 7, "Database Design and the E-R Model," explains the use of ERDs for modeling entities and their attributes, which is a core component of a data dictionary's content.

3. Salesforce Architects, Salesforce Well-Architected - Data Architecture: Data Modeling, "Data modeling is the process of creating a visual representation of an information system... Common artifacts include Entity Relationship Diagrams (ERDs)." (https://architect.salesforce.com/well-architected/framework/data/data-modeling)

The goal is to automate a process that aggregates detailed records into a summary, stores the summary in Salesforce, and purges the original details. A third-party ETL (Extract, Transform, Load) tool is designed for such data operations and can be scheduled to run automatically. It can extract data, perform the aggregation transformation, load the summary back, and then delete the source records. Schedulable Batch Apex is a native Salesforce solution for processing large data sets asynchronously. It can be coded to query records, calculate summaries, create summary records, and delete the detailed transactional records on a recurring schedule.

C. Third-party Business Intelligence system: BI systems are primarily for data analysis and visualization, not for data transformation and purging within the source system (Salesforce).

D. Apex Triggers: Triggers are not designed for large-scale, scheduled data processing. They execute on DML events and would be inefficient and likely hit governor limits.

1. Salesforce Developer Documentation, "Batch Apex". Batch Apex is designed for processing large numbers of records and can be scheduled. (See "Using Batch Apex" section).

2. Salesforce Developer Documentation, "Schedulable Interface". This interface allows developers to schedule Apex classes, such as a Batch Apex class, to run at a specific time.

3. Salesforce Architects, "Architect's Guide to Data Management". This guide discusses various data management strategies, including using ETL tools for data integration and archival processes (See "Data Archiving Strategies").

Salesforce’s native Merge Contacts only merges records that share the same Account. Because UC needs one Contact shared by several departments (different Accounts), they must (1) use a tool that can merge across-account duplicates, and (2) improve matching accuracy by standardizing key fields such as address. Data.com Clean provides postal-address standardization that makes cross-account duplicate detection far more reliable.

C. Workflow/field updates can’t parse, cleanse, or compare multi-account records; duplicates would still exist.

D. Native Merge Contacts is limited to Contacts under a single Account, so cross-account duplicates remain.

1. Salesforce Help “Merge Duplicate Contacts in Lightning Experience”, Limitations section, DOC-ID: 000334409.

2. Salesforce Help “Data.com Clean: How Address Standardization Works”, Address Standardization subsection.

3. Trailhead Module “Improve Your Data Quality”, Unit: Prevent and Merge Duplicate Data.

Workflow-triggered Outbound Messaging pushes a SOAP payload containing chosen Opportunity fields to an external endpoint immediately after the record reaches Closed/Won. The call is asynchronous, retried on failure, one-way, and keeps Salesforce as the system of record while making the ERP copy read-only—meeting the requirement for an optimal real-time solution.

A. MDM governs data quality; it is not a transport mechanism for real-time replication.

C. Nightly polling is batch, not real-time, and burdens the ERP with unnecessary queries.

D. Hourly jobs are scheduled batch processes and fail the real-time requirement.

1. Salesforce Integration Patterns & Practices v2 (2022), §3.2.1 “Outbound Message—Remote Process Invocation.”

2. Salesforce Help, “Outbound Messaging,” Workflow Guide, Winter ’24 (“delivers messages as they occur, with automatic retry”).

Maintaining data quality involves preventing incorrect or duplicate data from being entered and identifying existing issues. Salesforce Duplicate Management (B) provides a native framework with matching and duplicate rules to identify and manage duplicate records as they are created or updated. Validation Rules (C) are a powerful declarative tool to enforce data integrity and business logic, ensuring that fields meet specific criteria (e.g., format, required values) before a record is saved. These two features are fundamental to a proactive data quality strategy.

A. Use the private sharing model: This controls record visibility and access, not the accuracy or completeness of the data within the records.

D. Use workflow to delete duplicate records: Workflows cannot delete records. Furthermore, automatically deleting potential duplicates is a risky practice that can lead to data loss.

1. Salesforce Help, Manage Duplicate Records: "Customize Salesforce to detect and handle duplicate records as they're created or updated. Define logic that determines what happens when a user tries to save a duplicate record."

2. Salesforce Help, Validation Rules: "Validation rules verify that the data a user enters in a record meets the standards you specify before the user can save the record."

3. Salesforce Architects, Architect's Guide to Data Governance and Management, Section: Data Quality: "Key Salesforce Platform features that help with data quality include validation rules, duplicate management, and required fields."

Custom metadata type records are treated as metadata. They can be included in managed or unmanaged packages, change sets, and Metadata API deployments, allowing configuration data to move between orgs—something list or hierarchy custom settings cannot do without additional tooling.

A. Custom metadata records are copied to sandboxes during refresh like other metadata.

B. Custom metadata types are not reportable through Salesforce Reports UI.

D. Custom metadata records are read-only in Apex; they cannot be created or modified programmatically.

1. Salesforce Help, “Custom Metadata Types: Packaging and Deploying Records”, Summer ’24.

2. Metadata API Developer Guide v58, “CustomMetadata” section, p.112.

3. Salesforce Architects Blog, “Choosing Between Custom Settings and Custom Metadata Types”, 2023, para. “Deployability”.

1) Validation rules can display error text that is automatically translated through Translation Workbench. 2) An Apex trigger can call addError() with a Custom Label; Translation Workbench supplies label translations so users see the message in their language.

A. Third-party tools add complexity and aren’t required; platform solutions exist.

C. Workflow field updates can’t surface UI error messages; ErrorMessage isn’t a writable field.

1. Salesforce Help, “Translate Validation Rule Error Messages with Translation Workbench” (Customization, Summer ’24).

2. Apex Developer Guide v58, “SObject.addError(message)” → recommends using Custom Labels for translations.

3. Salesforce Help, “Custom Labels Overview” → “Translations provided through Translation Workbench.”

The scenario involves a large data load into an object (Time Entry) that is a child in a master-detail relationship. The parent object (Project) has a private sharing model and Roll-Up Summary (RUS) fields. Each new Time Entry record will trigger a recalculation of the RUS fields on the Project. Because the Project's sharing model is private, these updates can trigger intensive sharing rule recalculations, leading to record lock contention on the parent Project record and significant performance degradation. Deferring sharing calculations is a standard Salesforce best practice to suspend this processing during large data loads, preventing these performance issues.

B. Calculate summary values instead of Roll-Up by using workflow.

Workflow rules are not designed for high-volume data processing and are less efficient than declarative Roll-Up Summary fields or Apex-based solutions.

C. Calculate summary values instead of Roll-Up by using triggers.

While triggers can perform roll-ups, this doesn't solve the core problem of parent record locking and sharing recalculations; it simply moves the logic into custom code.

D. Load all data using external IDs to link to parent records.

Using external IDs is a best practice for efficient data loading but does not mitigate the post-save performance impact caused by sharing rule recalculations.

1. Salesforce Architects, "Designing Record Access for Enterprise Scale": Under the section "Sharing Rule Calculation," the guide states, "When you’re performing large data loads or other operations that affect many records and could trigger sharing rule recalculation, you can suspend sharing rule calculation to speed up your operations." This directly supports deferring calculations as the primary consideration.

2. Salesforce Help, "Manage Sharing Settings": The documentation for sharing settings explains the feature to "Suspend" and "Resume" sharing calculations. It notes, "To improve performance when making large-scale changes... you can suspend sharing calculations." This confirms the mechanism for the strategy in option A.

3. Salesforce Developer Documentation, "Record Locking Cheat Sheet": This document explains how master-detail relationships and roll-up summary fields cause implicit locks on parent records when child records are modified. It highlights that this can be a major bottleneck during large data loads, reinforcing the need for a strategy like deferring sharing to minimize lock duration and contention.

When designing a field-level audit and recovery plan, the primary consideration is the significant increase in data volume. Solutions like Field Audit Trail or custom audit objects generate a large amount of historical data. Therefore, the architect must review and project the data storage needs to ensure the solution is sustainable, performant, and does not exceed Salesforce org limits. This analysis informs the choice of solution, data retention policies, and potential need for off-platform archiving of the audit data itself.

A. Reduce data storage by purging old data: Purging data is contrary to the goal of creating a robust audit and recovery plan which relies on retaining historical data.

B. Implement an AppExchange package: This is a potential solution, not a design consideration. The architect must first consider requirements like storage before selecting a tool.

D. Schedule a weekly export file: While a weekly export is part of a backup strategy, it is not a "field-level audit" and is a specific tactic, not a foundational design consideration like storage.

1. Salesforce Help, "Field Audit Trail". The documentation explicitly states, "Field Audit Trail lets you know the state and value of your data for any date, at any time. But it uses a lot of your data storage." (See "Considerations for Field Audit Trail").

2. Salesforce Architects, "Architect's Guide to Data Management". This guide emphasizes the importance of understanding data growth and storage implications when implementing data governance and retention policies. (See "Data Governance" section).

3. Salesforce Help, "Monitor Data and Storage Resources". Architects must be aware of how different features consume storage to plan effectively.

To manage and prevent duplicate data, Salesforce provides native Duplicate Management features. This allows administrators to define matching rules to identify duplicates and duplicate rules to block or alert users upon creation. Historically, Data.com Clean was a Salesforce product specifically designed to clean, de-duplicate, and enrich customer data by comparing it against external sources like Dun & Bradstreet. Although retired, it represents a valid approach for data quality improvement and is often tested as a concept.

B. An Enterprise Service Bus (ESB) is an integration architecture pattern, not a primary data quality or de-duplication tool within Salesforce itself.

D. A data warehouse is a system for reporting and analysis, not for preventing the creation of duplicate records in a transactional system like Salesforce.

1. Salesforce Help, Manage Duplicate Records with Duplicate Management. This document details how to use matching rules and duplicate rules to control duplicate creation. Section: "Duplicate Management Concepts".

2. Salesforce Help, Data.com Clean. While the product is retired, official documentation describes its function: "Clean your account, contact, and lead records... by filling in gaps and correcting outdated information." This confirms its role as a data quality tool.

3. Salesforce Architects, Data Governance and Management. This guide discusses strategies for maintaining data quality, including the use of duplicate prevention tools and data enrichment services.