Salesforce Certified Data Architecture and Management Designer (SF-Data-Arch) — Questions 76–150

A maintained data dictionary and metadata inventory directly address the gap: they record what each field means, where its data originates, and who owns it. Coupling the artifact with a recurring review cadence ensures the information stays accurate as teams and integrations change. This gives the CIO durable visibility and a basis for future deprecation decisions.

Duplicate Management allows you to define matching rules to identify duplicate records and duplicate rules to control what happens when duplicates are detected (e.g., alert, block, or allow). This proactively identifies and prevents duplicate data entry, which is a key aspect of data quality. It can be configured for standard and custom objects, and runs in real-time on record creation and edit, as well as via batch jobs for existing data.

A stored numeric field can be indexed, and Salesforce supports custom indexes on external IDs or fields requested through Support. Populating it with a before-save flow keeps it current without consuming additional DML, so filtering by risk score in list views and reports uses the index and performs well at scale.

Validation rules evaluate on insert and update regardless of channel, so the same REGEX-based rule applies to web, mobile, and integration writes. It provides one reusable definition of the format requirement and blocks invalid values at the point of entry. This directly satisfies the governance lead's request for consistency across all channels.

Metadata API exposes object definitions, including custom fields, descriptions, and custom metadata values, so a governance service can programmatically evaluate every object against the required attributes. Apex Metadata API allows the check to run inside Salesforce and to fail a deployment or raise an alert. This gives the automated, metadata-level enforcement the governance team asked for.

The charter is the formal document that defines the governance program's scope, mission, and organizational authority. It is the primary artifact that regulators look for to verify that an organization has officially committed to structured data management and compliance, providing the necessary high-level evidence of a sound governance framework.

Disabling automation is essential to prevent recursive triggers or unintended updates that degrade performance. When loading large volumes, automated processes can consume CPU and DML limits, causing the load to fail. Clearing the path allows the raw data to be inserted efficiently before re-enabling business logic later.

Global Value Sets provide a centralized, reusable list of picklist values. This ensures that the same set of options is available across multiple objects, guaranteeing data consistency. It simplifies administration because changes are propagated automatically, making it the best architectural choice for maintaining data integrity in global deployments.

Field Audit Trail provides long-term retention of field history for compliance, while a custom batch process can enforce region-specific retention by archiving and purging records. This combination addresses both the need for auditability and the requirement to delete data after the specified periods. It allows the company to tailor retention logic per region and maintain a clear audit trail.

Retention governance defines how long data is stored and when it should be moved or archived. Automating this phase ensures that production storage is kept clean and performant. By moving inactive data to archival storage, the organization balances regulatory requirements with the need for a lean, high-performing active Salesforce environment.

Master-Detail relationships force child records to inherit the sharing and security settings of the parent. In contrast, Lookup relationships allow the child to have its own independent sharing rules, making this a fundamental design decision for data access control and visibility across different user profiles.

Salesforce Data Mask is a powerful tool that automatically replaces sensitive information with random characters or mapped values during the sandbox creation or refresh. This allows developers to work with realistic data structures and volumes without being exposed to actual sensitive customer information.

Master-detail relationships feature cascading deletes, where child records are automatically removed when their parent is deleted. If the business requirement dictates that records should persist independently of the parent, a Lookup relationship is necessary to avoid data loss and maintain the integrity of the child records.

The governance policy explicitly requires review and approval by the data governance council before creating new custom objects or fields. Submitting a request with justification and impact analysis is the correct first step. It ensures the council can assess the need, check for redundancy, and maintain data standards. Only after approval should the developer proceed with creation.

Objects with many lookup relationships are problematic because every record update might involve locking multiple parent records. This leads to severe contention during large data imports and complex queries. These objects require careful planning, such as implementing indexing and optimizing batch processes to minimize the locking overhead.

An ETL tool can transform the legacy Lead Status values to match the Salesforce picklist values exactly. This ensures that the standard Lead Status field is populated correctly and avoids load errors. The mapping can be defined in the ETL tool's transformation logic. This is the most reliable method for ensuring data quality.

Without an index on the custom field, the query optimizer cannot efficiently narrow down the search space. When dealing with millions of records, the lack of an index forces the system to scan every row, which is the primary cause of slow query execution and potential timeout errors.

Field Audit Trail tracks changes to field values and can retain field history for up to 10 years, meeting the retention requirement. Event Monitoring captures access events, including who viewed or exported data, providing a comprehensive audit trail. Together, they address both change tracking and access tracking for PHI, ensuring HIPAA compliance.

Big Objects store billions of records on a separate, non-transactional index, so historical call detail records leave standard object storage and its limits. Asynchronous writes and indexed lookup keys keep queries performant while preserving the required access path.

Triggers run for every record processed, consuming CPU and database resources while creating row locks on parent or related objects. Disabling them allows the system to focus exclusively on record insertion, significantly increasing throughput and avoiding potential deadlocks caused by concurrent logic execution during the migration.

Bulk API 2.0 is purpose-built for high-volume data movement, handling large batches asynchronously to maintain system stability. It provides significant performance gains by allowing Salesforce to manage job batching internally. This minimizes the risk of hitting governor limits and ensures successful large-scale data migrations for enterprise environments.

Staging databases are essential for complex transformations that are difficult to perform within Salesforce or CSV tools. They enable SQL-based joins, cleansing scripts, and deduplication logic, ensuring that the data is perfectly structured and validated before it is uploaded to the final production instance for migration.

When teams rely on disparate, un-synchronized data sources, they often have different versions of the truth for a single customer. This lack of a unified golden record leads to disconnected customer experiences, such as marketing sending promotional emails to a customer who has already churned in the CRM.

Big Objects are purpose-built for massive scale, allowing storage and querying of billions of records. They do not count against the standard record count limits and offer optimized performance for analytical queries. This is the optimal architecture for data-intensive requirements, ensuring that the CRM platform remains fast and responsive.

This approach correctly separates the migration of Account data from the ownership assignment. Storing the legacy email in a custom field preserves the original data for audit, and a subsequent update using a User lookup (via ETL, Data Loader, or Apex) can accurately set OwnerId. This avoids load failures and ensures ownership is assigned to the correct active User. It also allows validation of email-to-user mappings before final assignment.

Salesforce Connect integrates external data into the org via external objects. This allows companies to keep data outside of the Salesforce database, preventing native performance degradation while ensuring users still have access to the information, which is a perfect pattern for large-scale data archival and management needs.

Survivorship rules should prioritize the source system that is most authoritative for a given attribute. For product data, the PIM system is typically the authority for marketing attributes, while the ERP is authoritative for pricing and inventory. This ensures the golden record reflects the most trusted value. It is the most critical factor because it directly determines trustworthiness.

This is the correct approach to maintain performance. Offloading data to an external repository or Big Object reduces the record count in the transactional object, keeping indexes lean and queries fast, while still allowing access to historical data when needed for compliance or analytical purposes.

A Chief Data Officer or senior executive provides the necessary mandate to enforce governance policies across diverse business units. Their involvement ensures that data governance is treated as a strategic business initiative, securing the executive-level support needed to manage organizational change and resource allocation effectively.

Caching related parent records in a Map ensures that SOQL queries are performed only once for the entire batch. This minimizes resource consumption and prevents governor limit violations, allowing developers to process thousands of records efficiently, which is vital for high-volume data operations in the Salesforce platform.

Conflicts often arise regarding who 'owns' a piece of data, leading to inconsistent definitions. The council acts as the final arbiter for these disputes, ensuring that roles are clearly defined and that business units agree on the sources of truth, which is essential for uniform reporting and data usage.

A Master-Detail model enforces referential integrity and allows for easy aggregation of data through roll-up summaries. This hierarchy is the most efficient way to store, query, and manage complex product data. It ensures that every component is correctly linked to its parent version, which is linked to its parent product.

Custom indexing and Skinny tables are the most effective native ways to optimize read performance. By providing the database with direct access paths or denormalized data sets, these features allow the query optimizer to return results rapidly, avoiding the performance pitfalls of full table scans.

Field Audit Trail provides the deep, long-term history tracking required for compliance. It supports up to 10 years of data and allows for tracking a significantly higher number of fields than standard history tracking. It is the architecturally correct choice for meeting stringent regulatory data retention and audit requirements.

Region-specific retention rules honor each jurisdiction's legal requirements while still operating under a single overarching governance framework. Enforcement requires segmenting records (for example, by region field or record type) and scheduling automated deletion or archival jobs per segment. This satisfies both the compliance mandate and the need for a consistent, documented policy.

Deterministic matching uses exact identifiers like email or ID, while probabilistic matching uses fuzzy logic to link records based on confidence scores. Combining both approaches maximizes the reach of the identity resolution process, ensuring that fragmented customer interactions are accurately linked into a single cohesive profile.

This configuration directly maps to the requirements. The 'Report' action allows users to proceed after an alert, facilitating manual data entry, while the 'Block' action on the API ensures that automated integration processes cannot bypass duplicate prevention, effectively maintaining high data quality across all system interaction types.

This is correct because Salesforce allows you to populate a lookup relationship using an external ID field. After Accounts are migrated, Contacts can be loaded with the Account's legacy ID in the Account lookup field, and Salesforce will resolve it to the correct Account record. This avoids the need for a second pass or manual mapping and is efficient for large volumes.

OpportunityLineItem records require a parent OpportunityId. By loading Opportunities first with an External ID, the architect can then load line items referencing that External ID, ensuring referential integrity. This two-pass approach is standard for parent-child migrations and avoids orphaned child records.

Lookup relationships are independent, allowing for granular sharing controls on both the parent and the child. If the business requirement demands that the child object has its own unique security rules separate from the parent, then a lookup relationship is the architecturally correct choice.

Record-Triggered Flows are the modern declarative automation tool in Salesforce. They can be triggered when a record is created or updated, and they can update related records regardless of whether the relationship is master-detail or lookup. This meets the requirement without code. Flows are more powerful and flexible than Workflow Rules or Process Builder, and they are the recommended approach for new automation.

Big Objects are designed for long-term retention of large data volumes and support custom indexes for efficient queries. Compliance officers can query them through Async SOQL or by exposing them via a Lightning component, and the data remains in Salesforce without consuming standard data storage.

When viewing a Case record, the related list of Log__c records is displayed by querying Log__c where Case__c equals the current Case Id. This filter is highly selective because it returns only the logs for one case. With a custom index on Case__c, the query optimizer can use the index to efficiently retrieve those records, significantly improving performance.

To maintain referential integrity, Cases must be loaded first to generate Salesforce IDs. Then, Case Comments can be loaded with the ParentId set to the corresponding Case ID. This requires mapping legacy Case IDs to Salesforce IDs, often via an External ID field on Case. This sequential approach ensures that each comment is linked to an existing Case.

Because each write requires an update to the corresponding index table, having many indexes adds cumulative overhead to every DML statement. This lengthens the time required to commit transactions, which can eventually lead to governor limit issues and performance bottlenecks in high-volume environments.

Moving the query outside the loop is the standard pattern for bulkifying Apex code. By fetching all necessary PricebookEntry records into a Map at once, the logic can access them in constant time without re-querying the database, effectively eliminating the risk of exceeding SOQL limits during bulk data processing.

The errors occur because the Bulk API expects numeric values for Currency fields, but the source data contains symbols and commas. Pre-processing the data to remove non-numeric characters and convert to decimal ensures the data matches the target format. This is the most efficient and reliable method, as it addresses the issue at the source and avoids repeated load failures.

Parallel processing attempts to update records as fast as possible. If multiple threads attempt to update or insert child records that share the same parent, they will contend for the parent record lock, resulting in 'UNABLE_TO_LOCK_ROW' errors that can stop the migration process.

Large-scale deletions cause intense row-level and table-level locking. Breaking this into stages—marking records first and deleting them in batches during off-peak windows—reduces the contention for system resources, ensuring that the database remains responsive for other users while the deletion operation progresses.

Data stewards are responsible for establishing the quality standards and resolving disputes that automated systems cannot handle. By managing the definitions and policies governing master data, they ensure that the organization maintains a clean, reliable, and trusted data foundation that supports informed business decision-making and efficient operations.

Metadata and custom settings are the 'brain' of the Salesforce organization. If these are lost or corrupted, the system's custom logic and configuration cease to function. Backing them up externally is critical because they represent the effort of years of development and are not easily restorable from standard platform backups.

Large result sets retrieved via nested queries consume significant heap space and CPU time. If the number of contacts associated with the queried accounts exceeds memory or CPU limits, the apex process will fail. Architects must use batch Apex or limit the result set to ensure reliability in large orgs.

Attribute-level survivorship lets each field be governed independently: billing fields are hard-coded to trust Oracle as the authoritative source, while other fields are resolved by comparing last-updated timestamps. The resulting golden record is then synchronised back to Salesforce and Oracle, keeping both systems consistent. This directly satisfies the stated business rules without relying on Salesforce-native duplicate detection, which cannot perform field-level conflict resolution.

Transforming data in the ETL layer is the industry standard for migration. It keeps the Salesforce org clean and prevents errors during ingestion. Using tools such as Informatica, Mulesoft, or custom scripts allows for robust validation and formatting, ensuring the incoming data meets all schema requirements before submission.

The '-i' flag (or --externalid) tells the Bulk API which field to use for matching the incoming data against existing Salesforce records. If a match is found based on this field, the record is updated; if no match is found, a new record is created.

Accounts serve as the foundation of the relational data model. By loading them first, you generate the Salesforce IDs necessary to map children (Contacts and Opportunities) correctly during subsequent loads. This top-down hierarchical approach is the industry-standard sequence for successful data migration projects in Salesforce.

Because formula fields are not indexed and must be calculated on the fly during a query, the Salesforce database engine must perform a full table scan to evaluate every record against the filter criteria. For objects with millions of records, this is a major performance bottleneck.

Parent-level row locks cascade to child records during master-detail updates, so the 15,000-child Account triggers lock contention across all dependent rows. This directly explains the severe locking and transaction failures described, since Salesforce acquires exclusive locks on the parent and its detail records within the same transaction.

Dependent picklists provide an intuitive UI experience by dynamically filtering available options based on the controlling field. This is the most efficient and standard way to restrict picklist values, ensuring users only select valid combinations without needing custom code or complex validation logic to maintain the data model.

Master-Detail makes the detail record dependent on the master, so a Shipment_Line__c cannot exist without a Shipment__c. The detail inherits the master's organization-wide defaults and sharing, and the detail's owner is effectively the master's owner, so it cannot be independently owned. This matches the stated requirements for containment, sharing inheritance, and ownership.

A Custom Setting (or Custom Metadata) provides a clean, highly performant way to toggle Apex execution logic. This allows developers to disable resource-intensive triggers temporarily for the duration of the data load and reactivate them immediately afterward without needing a full code deployment cycle.

When one user owns a large volume of child records, record locking can occur during updates to the parent record. Distributing ownership across multiple users helps alleviate contention, as the platform's locking mechanism is often tied to the parent record's owner and sharing rules in the underlying database.

A master data domain requires a golden record that is the single source of truth, survivorship rules to determine which source wins in conflicts, and stewardship to maintain quality. This ensures all transactional systems reference the authoritative Customer record. It directly addresses the need for a single, authoritative record.

Big Objects allow for the storage and querying of massive datasets without impacting performance or standard data storage limits. They are specifically engineered to handle high volumes, making them the optimal choice for weekly snapshots that need to be queried but not frequently updated or edited.

Big Objects are designed for large-scale archival and are queried using Async SOQL, which runs asynchronously and can handle massive datasets. Copying old records to a Big Object and deleting them from Asset__c reduces the size of the transactional object, improving performance. Async SOQL is the correct mechanism for querying Big Objects and can be invoked from a Lightning component, satisfying the audit requirement.

Salesforce provides Data Subject Request tooling that finds an individual's data across related records and supports erasure while producing a record of the action. It addresses the cross-object scope of the request and provides the evidence trail governance requires, unlike a manual delete.

Indexes function like a book index, allowing the database to jump straight to the data rows that match the filter criteria. This eliminates the need for full table scans, which are prohibitively slow on tables with millions of records, and is vital for maintaining responsive application performance.

This is correct because the validation rule requires a specific value. Transforming the data to populate a valid default ensures that all records pass validation. This approach is simple, does not require changing the validation rule, and maintains data quality. It is a standard data cleansing step in migration projects.

A data inventory maps the flow and storage location of data across the enterprise. It is essential for residency compliance because it identifies where data originates, moves, and resides. Without this, an organization cannot prove to regulators that they are keeping data within the required legal jurisdictions or borders.

Salesforce resolves relationship fields by matching the value supplied in the relationship field against the target object's external ID field, so loading visits with the legacy provider code in the Provider__c relationship maps each visit to the correct Provider__c record without a prior ID export. This is exactly the pattern Bulk API 2.0 and Data Loader support for external ID lookups, and it scales for multi-million record loads.

Storing the original legacy status in a separate text field preserves the exact source value for auditing and reporting, while the picklist field is used for operational purposes. This dual approach ensures data quality and traceability without compromising the picklist's integrity. It is a best practice when transforming data during migration to retain historical context.

Salesforce selectivity thresholds depend on the object size; for 12 million records, a query must filter to a small percentage to use an index. Even with indexes on Status__c and Order_Date__c, if the filters are not restrictive enough, the optimizer may choose a full scan. Sorting by CreatedDate adds a sort operation that can further degrade performance when the result set is large. This combination explains the timeout.

Pre-aggregation shifts the computational load from read-time to write-time. By calculating metrics asynchronously and storing them in a summary object, the report engine only processes a small number of aggregate records rather than scanning the entire base table, significantly reducing execution time and resource consumption.

The data dictionary serves as the single source of truth for metadata definitions. By standardizing how data is described and used across the organization, it eliminates inconsistencies. This clarity is vital for developers and business users alike, as it ensures they all interpret the data in exactly the same way.

An External ID field is specifically designed to store unique identifiers from external systems and is used by the upsert operation to match records. Making the custom Text field an External ID allows the architect to use upsert with this field as the match key, preventing duplicates during future updates. The length of 15 accommodates the legacy identifier.