Salesforce Data Management practice questions

Use Custom Objects with private sharing rules.

Why it fails: Storing seven-year-old records in Custom Objects within Salesforce still consumes production data storage limits. This does not address the primary goal of archiving, which is to reduce the footprint of the operational database, improve record search speeds, and maintain high performance for current, active business transactions.

Soft-delete records using a custom field.

Why it fails: Soft-deleting data using a checkbox field does not reduce the storage usage in Salesforce, as the records remain in the system. The database query engine must still index and scan these records, which does not provide the performance benefits required for effective historical data management and archival strategies.

Increase the size of the Salesforce Data Storage limit.

Why it fails: Increasing data storage limits is a stop-gap measure that does not solve the root cause of inefficient data volume management. It increases costs significantly and does not optimize query performance, which degrades as tables grow larger. Proactive archiving is a necessary architectural discipline for long-term platform health.

Reduce the number of fields on the Contact object.

Why it fails: Reducing field counts does not significantly impact query performance for large datasets. While lean objects are a best practice, the primary bottleneck for large tables is usually the lack of appropriate indexing, which forces the database to perform expensive full-table scans to find the requested records.

Implement a Platform Cache partition.

Why it fails: Platform Cache is useful for caching frequently accessed data like custom settings or API response payloads. However, it is not an indexing solution for database queries. Searching millions of records requires a database-level optimization through indexing rather than application-layer caching of static or semi-static data values.

Switch to the Salesforce Lightning user interface.

Why it fails: Switching to Lightning UI does not solve database-level performance issues related to non-selective queries on large datasets. The underlying database query performance remains identical regardless of the UI layer, so the performance bottleneck will persist until the data access patterns are optimized through proper indexing or data partitioning strategies.

Batch file transfer via SFTP every 24 hours.

Why it fails: Batch processing introduces high latency, which fails the requirement for real-time synchronization. Changes made in the ERP would not be reflected in Salesforce for up to 24 hours, creating a significant data discrepancy that could negatively impact sales operations and customer service interactions that rely on accurate data.

Fire and Forget using Platform Events.

Why it fails: Fire and Forget is asynchronous and does not provide an immediate guarantee that the receiving system processed the update successfully. For financial records, this lack of confirmation is a high risk, as data might fail to sync without the originating system being notified, causing severe downstream business process errors.

UI-based data import for every change.

Why it fails: Manual UI-based data imports are inefficient, prone to human error, and do not scale for real-time needs. Using a manual process for synchronization between enterprise systems is not a viable architecture, as it creates bottlenecks and lacks the reliability and auditability required for enterprise-grade financial data management.

Enable 'All Data' access for all users.

Why it fails: Enabling 'All Data' access is a security risk and violates the principle of least privilege. It encourages unauthorized modifications, which can lead to data integrity issues. Proper data management requires granular access controls to ensure that only authorized users can modify data, maintaining the reliability of the system.

Increase API limits for all user profiles.

Why it fails: Increasing API limits does not improve data quality; it only allows for higher volumes of data movement. If the source data is poor, increasing throughput simply propagates bad data throughout the organization faster. Data quality must be managed through logic and policy, not by adjusting platform resource limits.

Field-Level Security.

Why it fails: Field-Level Security controls access, not data content. It would hide the field from users, but it does not mask the actual data within the field. If a user has access to the field, they would still see the real PII, which is not sufficient for protecting data privacy in sandbox environments.

Organization-Wide Defaults.

Why it fails: OWDs define the baseline access level for records but do not alter or mask the content of those records. Even if a user has restricted access, the data itself remains in plain text, meaning PII is not protected. OWDs are entirely irrelevant to the objective of masking data for privacy compliance.

Encrypted Custom Fields.

Why it fails: Encrypted fields use Shield Platform Encryption to protect data at rest, but they display decrypted data to users with the 'View Encrypted Data' permission. This does not mask the data. It is meant for security against database theft, not for anonymizing data for testing purposes in lower-tier Salesforce environments.

Use the SOAP API with a batch size of 200 during standard business hours with active triggers.

Why it fails: Processing records during business hours with active triggers creates severe row-level locking and transaction bottlenecks. The SOAP API processes requests synchronously, making it poorly suited for multi-million record migrations compared to asynchronous bulk endpoints.

Deploy a custom Visualforce batch controller to process records synchronously via single DML statements.

Why it fails: Visualforce controllers are bounded by strict synchronous heap size and execution time limits. Attempting to process 5 million records through this interface will immediately trigger governor limit exceptions and application timeouts.

Leverage standard web-to-lead forms routed through an automation workflow to inject records into the database.

Why it fails: Web-to-lead is specifically architected for inbound marketing forms rather than high-volume data migrations. It lacks the throughput capacity, error handling granularity, and object flexibility required for massive Account object loads.

Immediate automatic archiving of deleted records into a secondary Salesforce sandbox environment via native streaming.

Why it fails: Salesforce does not automatically stream deleted records from production to a secondary sandbox environment. Deletion removes data from the current org completely, requiring external ETL processes or Big Objects for long-term retention prior to purging.

Immediate release of database storage limits across all connected enterprise data warehouses within milliseconds of deletion.

Why it fails: Storage metrics in Salesforce are recalculated periodically through background jobs rather than updating instantaneously across external data warehouses. External systems must be explicitly synchronized via integration layers to reflect production deletions.

Automatic generation of immutable audit logs stored natively within standard Account attachments for compliance reporting.

Why it fails: Salesforce does not automatically generate immutable audit logs or attach deletion records to Accounts during standard purges. Organizations requiring regulatory compliance logs must implement custom logging mechanisms or Event Monitoring solutions.

The query must contain a WHERE clause with an indexed field.

Why it fails: PK Chunking does not require a WHERE clause with an indexed field; in fact, its purpose is to handle scenarios where a WHERE clause might be inefficient. It automatically generates its own boundaries based on the record IDs, regardless of the filters applied to other fields in the query.

The batch size must be set to exactly 10,000 records.

Why it fails: While PK Chunking uses default chunk sizes (usually 100,000), the user can specify a 'chunkSize' in the header. There is no requirement for the batch size to be exactly 10,000 records. The system manages the creation of batches automatically based on the ID ranges it calculates.

Skinny Tables can only be created for standard objects.

Why it fails: Skinny Tables can be created for both standard and custom objects. They are particularly useful for custom objects with millions of records where report and query performance has begun to degrade due to the underlying database structure of split tables for standard and custom fields.

Skinny Tables must be manually refreshed by an administrator every 24 hours.

Why it fails: Skinny Tables are kept in sync with the source tables automatically by Salesforce. There is no manual refresh required. When data is inserted or updated in the main object, the platform ensures the corresponding Skinny Table is updated in near real-time to maintain data consistency.

Skinny Tables are only available in Developer and Enterprise editions.

Why it fails: Skinny Tables are available in most editions where performance is an issue, but they must be enabled by Salesforce Support. They are more about the scale of the data rather than the specific edition, though they are primarily utilized in Enterprise and Unlimited editions.

Salesforce Connect.

Why it fails: Salesforce Connect is a data virtualization tool used to view external data in real-time within Salesforce. It is not an import tool and cannot be used to physically move records into Salesforce or perform deduplication logic on a CSV file of Lead records.

Change Data Capture.

Why it fails: Change Data Capture (CDC) is a streaming product that sends notifications when data changes in Salesforce. It is used for synchronization and event-driven architectures, not for the bulk import of legacy data or spreadsheet-based records into the system.

Data Loader with Duplicate Rules enabled.

Why it fails: While Data Loader can import records, it does not have 'built-in' matching logic like the Wizard. While Duplicate Rules can technically trigger during a Data Loader run, the process is less streamlined for the user than the native matching options provided directly in the Import Wizard interface.

Point-to-Point integration between all systems.

Why it fails: Point-to-Point integration becomes unmanageable as the number of systems grows. It leads to 'spaghetti' architecture where each system has its own logic for data mapping, making it nearly impossible to maintain a single 'Golden Record' or achieve true Master Data Management across the entire organization.

Peer-to-Peer synchronization where Salesforce is the master.

Why it fails: Peer-to-Peer synchronization often results in data conflicts and 'race conditions' where two systems update each other simultaneously. While Salesforce is powerful, it is often not the best choice for a corporate-wide MDM hub if the data must be shared across many non-Salesforce systems.

Using Salesforce Big Objects to store all external system data.

Why it fails: Big Objects are a storage solution, not a data management strategy. Storing raw data from other systems in Big Objects does nothing to cleanse, deduplicate, or master the data. MDM requires logic and processes that go far beyond simple high-volume data storage capabilities.

Export records to an external data warehouse using Data Loader and delete them from Salesforce.

Why it fails: Exporting to an external warehouse removes the data from the Salesforce ecosystem. While this saves storage space, it fails the requirement to keep the records searchable directly within the Salesforce interface, necessitating additional development work to build a custom external integration for auditors to query the archived data.

Move records to a custom object and implement Apex-based sharing rules to restrict access.

Why it fails: Storing historical data in custom objects counts against the organization's standard data storage limits. This approach does not address the storage capacity issue caused by millions of records, and the query performance will degrade significantly as the volume of records grows, eventually leading to potential governor limit violations.

Update the Opportunity records to a private state and remove all users from the sharing rules.

Why it fails: Updating record visibility does not solve the underlying storage issue. The records still exist in the standard Opportunity table, continuing to consume valuable data storage space. This method does not support long-term archiving strategies and fails to reduce the performance overhead associated with large volumes of inactive records.

Use the SOAP API for all record inserts to leverage granular error handling.

Why it fails: The SOAP API is not designed for large-scale data migrations involving millions of records. It lacks the throughput capabilities of the Bulk API 2.0 and is prone to timeout errors when processing high volumes. Using SOAP for this scale would significantly extend the migration duration and increase failure rates.

Perform the migration during business hours to ensure IT support is available.

Why it fails: Performing high-volume migrations during business hours negatively impacts end-users. Increased resource consumption from the load results in slower system performance for daily tasks. Additionally, record locking caused by massive updates can prevent users from completing their work, making after-hours execution the standard best practice for data migrations.

Increase the batch size to the maximum allowed limit for every object type.

Why it fails: Increasing batch sizes to the maximum limit is not always optimal. Large batches can trigger CPU time limit errors and increase the likelihood of record-locking contention, especially when multiple batches attempt to update the same parent records. Batch sizes must be tuned based on object complexity and automation intensity.

The field must be converted to an Encrypted Text field type before encryption.

Why it fails: Platform Encryption does not require converting standard or custom text fields into the older 'Encrypted Text' field type. Those legacy fields have significant limitations, such as lack of support for validation rules or triggers. Platform Encryption is designed to work natively with standard and custom text fields.

The organization needs to enable 'Searchable' in the encryption policy settings.

Why it fails: There is no 'Searchable' toggle in the Platform Encryption policy settings. Enabling deterministic encryption automatically allows for filtering and exact-match searches. If searching fails, it is usually because the index was not correctly updated or the field was not configured as deterministic, rather than a missing checkbox.

AES-256 encryption is incompatible with SOQL filter operations.

Why it fails: AES-256 is the standard encryption strength used by Salesforce and is perfectly compatible with SOQL filtering when deterministic encryption is configured. The algorithm choice relates to data security levels, not the functional ability to perform standard database queries or filter operations on the encrypted data itself.

Manually export and re-import data using Data Loader to perform masking.

Why it fails: Manual export-import cycles are inefficient and error-prone. They expose sensitive data to local machines during the export process and require constant maintenance as the schema changes. This approach is not scalable or secure enough for enterprise-level data management requirements in a large organization.

Change the organization-wide defaults to 'Private' to hide data.

Why it fails: Changing visibility settings does not mask or obfuscate the data. Users with elevated access, such as System Administrators, can still view all the PII. The data remains in its original, sensitive format, failing to meet the security requirement of preventing unauthorized exposure of customer information.

The complexity of the record-level security model applied to the user.

Why it fails: Both APIs operate within the security context of the user. Record-level security, such as sharing rules or OWDs, applies equally to both APIs. The security model does not dictate the choice between these two APIs, as the platform enforces access control regardless of the method used to submit data.

The requirement to execute Apex triggers and validation rules.

Why it fails: Both APIs support the execution of Apex triggers and validation rules. Unless specifically bypassed, these platform features will fire regardless of whether SOAP or Bulk API is used. Therefore, this factor is not a differentiator when choosing between the two integration methods for data management tasks.

Create a formula field to calculate the totals on every record.

Why it fails: Formula fields are calculated at runtime, which does not help with performance in a dashboard. If anything, having complex formulas on 10 million records can slow down performance during reports and record views, as the system must calculate these values every time the records are retrieved from the database.

Use a Dynamic Dashboard to force data refresh every hour.

Why it fails: Dynamic dashboards do not change how the data is queried; they only change who the data is viewed as. Forcing a refresh does not resolve the underlying issue of slow query performance on 10 million records; it actually increases the load on the platform by forcing constant re-computation.

Enable 'Parallel Report Processing' in the Org settings.

Why it fails: Parallel processing is an internal platform optimization and not a setting that can be enabled manually. Relying on this is not an architectural strategy. Performance must be solved at the data model level, such as through indexing or pre-aggregation, to guarantee consistent results for users interacting with the dashboard.

Use the SOAP API with standard field mapping to preserve original system timestamps and IDs directly.

Why it fails: SOAP API processes records sequentially or in small batches, making it entirely unsuited for a 50 million record migration due to severe timeout risks and performance degradation. Furthermore, standard system audit fields like CreatedDate remain locked to the import time unless special org-level features are explicitly requested. Data architects must avoid this protocol for high-volume loads.

Deploy a custom Apex batch process to insert records synchronously in chunks of 2,000 to manage governor limits.

Why it fails: Apex batch processing operates within strict synchronous execution limits and trigger overhead, making it significantly slower and riskier for a 50 million record volume compared to native Bulk API endpoints. Custom Apex should be reserved for complex data transformation logic rather than raw bulk data ingestion. Maintaining custom code for migrations increases long-term technical debt.

Utilize Salesforce Data Loader with the serial execution mode to guarantee sequential record processing and prevent locks.

Why it fails: Serial mode forces the Bulk API to process batches one record or small chunk at a time, severely throttling throughput and causing the 50 million record migration to take days or weeks. Parallel processing mode is vastly superior for performance, provided parent-child relationships and locking hierarchies are properly designed to minimize contention.

Sort the CSV input file by parent Account ID so child opportunities referencing the same account are processed in sequential batches.

Why it fails: Sorting by parent ID alone does not prevent locking if parallel threads process different chunks that happen to reference the same parent Account. Salesforce Bulk API parallel mode intentionally distributes batches across threads, which exacerbates parent-level locking contention regardless of intra-file sorting order unless processed strictly in serial mode.

Restructure asynchronous processing to utilize serial mode for all high-volume data loads affecting shared parent records.

Why it fails: Serial mode forces sequential processing which eliminates concurrent updates to shared parent records, thereby preventing the race conditions that cause UNABLE_TO_LOCK_ROW exceptions. Although processing takes longer, it provides predictable execution for high-contention parent-child hierarchies during maintenance windows. This is a classic mitigation pattern for heavily skewed rollup summary scenarios.

Increase the batch size in Data Loader to the maximum allowable limit of 10,000 records to minimize transaction overhead.

Why it fails: Larger batch sizes hold database locks for longer durations across a broader set of records, which dramatically increases the probability of deadlocks and UNABLE_TO_LOCK_ROW errors. Smaller batch sizes between 200 and 2,000 records are generally recommended for high-concurrency environments to release locks quickly and maintain optimal database performance.

Enable Parallel Processing mode in Bulk API to ensure threads process independent parent hierarchies simultaneously without cross-thread conflicts.

Why it fails: While parallel processing maximizes throughput, it actually increases row locking if the parallel threads attempt to update the same parent records simultaneously. Data architects must carefully analyze parent-child data skew before leveraging parallel mode to avoid exacerbating locking exceptions across shared master records.

Increase the batch size to process more records per transaction.

Why it fails: Increasing the batch size actually exacerbates record locking issues because more records are held in a single transaction. Larger batches increase the time the database transaction remains open, leading to higher probability of collision with other processes and increasing the total duration of the record-level locks applied.

Convert the batch Apex to a synchronous process to avoid contention.

Why it fails: Synchronous processes are subject to significantly tighter governor limits and will likely time out when processing large data volumes. Converting to synchronous code does not address the fundamental database contention issue and sacrifices the scalability required for handling large data volumes within the Salesforce platform's constraints.

Disable all Validation Rules and Triggers during the batch process.

Why it fails: While disabling triggers can reduce processing time, it does not solve the underlying database locking mechanism. The contention remains if multiple threads attempt to update the same record. Furthermore, disabling business logic often leads to data integrity violations, making this an inappropriate strategy for managing record-level locks.