Data Management practice questions

Global Search

Why it fails: Global Search is for finding existing records, not importing new ones.

Mass Delete tool

Why it fails: Mass Delete is for removing records, not importing.

Data Import Wizard

Why it fails: Data Import Wizard has a strict limit of 50,000 records per import.

Map the Owner ID column to a blank value in the CSV file.

Why it fails: Leaving Owner ID blank without checking assignment rules will cause records to default to the integration user.

Write a Process Builder to change the owner after insert.

Why it fails: Process Builder is unnecessary when standard assignment rule processing is built into Data Loader settings.

Use Data Import Wizard, which ignores assignment rules by default.

Why it fails: Data Import Wizard has an optional checkbox for trigger-based assignment rules, but Data Loader requires explicit configuration.

Data Loader cannot process Person Accounts without a parent Business Account.

Why it fails: Person Accounts are inserted as Account records and do not require a parent Business Account, so this is not the cause; the duplicate email error stems from the Person Account matching or duplicate rules. It is tempting because Person Accounts do relate to Contacts, and a parent Business Account would be needed only for Business Account contact linkage.

Person accounts require a separate insert for the Contact object first.

Why it fails: Person accounts are stored in the Account table and do not require a separate Contact record insert.

Person accounts do not support custom fields in Data Loader.

Why it fails: Person accounts fully support custom fields.

Lookup relationship to User

Why it fails: A custom user lookup does not govern record ownership or standard transfer capabilities.

Auto-Number field

Why it fails: Auto-Number is for naming/numbering, not ownership control.

Checkbox field named 'Locked'

Why it fails: A checkbox does not inherently restrict ownership transfers without validation rules or Apex.

Campaign records must be locked before adding members.

Why it fails: Locking campaigns is not a prerequisite for adding members.

Campaign Status is a required field that was omitted from the mapping.

Why it fails: While status is important, default values typically apply if omitted; duplicate membership is the primary failure cause.

Campaign members cannot be loaded via Data Loader; they require Data Import Wizard.

Why it fails: Data Loader fully supports Campaign Member inserts and updates.

Escalation Rule

Why it fails: Escalation Rules monitor time-based conditions on case records and reassign or notify, so they cannot validate a Discount Percentage value on save. They are tempting because they enforce automated actions on records, but they would be correct for escalating overdue cases, not restricting field input.

Sharing Rule

Why it fails: Sharing Rules widen record access for roles or groups; they do not validate field values, so a Discount Percentage above 20% would still save. They are tempting because they enforce governance over who sees records, but they would be correct for opening access to records owned by other users.

Assignment Rule

Why it fails: Assignment Rules automatically assign new leads or cases to users or queues; they cannot evaluate a Discount Percentage field on save. They are tempting because they automate record routing declaratively, but they would be correct for directing incoming leads to the right queue, not for validating numeric input.

Change the record type of old opportunities to 'Archived' and apply a sharing rule to hide them.

Why it fails: Changing record types still keeps records in the primary database tables, consuming storage and impacting query performance.

Mark the opportunities as inactive using workflow field updates.

Why it fails: Opportunities do not have an active/inactive status flag natively.

Contact Salesforce Support to delete the primary database indexes for those records.

Why it fails: Salesforce does not manually alter database indexes for individual customer record partitions.

Load Tasks and Events using the parent Account ID directly in the WhoId field.

Why it fails: WhoId relates to People (Contacts/Leads), while WhatId relates to objects like Accounts and Opportunities.

Perform a single bulk insert of 2 million records with a batch size of 2,000.

Why it fails: A batch size of 2,000 for activities often causes database lock contention and CPU timeouts.

Convert all historical activities into custom object records to bypass standard activity limits.

Why it fails: Converting standard activities to custom objects breaks native activity timelines and standard reporting.

Duplicate Rule set to block on delete

Why it fails: Duplicate Rules detect and block duplicate record creation or editing; they do not govern delete permissions, so they cannot restrict deletion to holders of a custom permission set. They are tempting because they enforce data-quality blocks declaratively, but they would be correct for preventing duplicate Opportunity records.

Sharing Rule with Read-Only access

Why it fails: Sharing rules grant access, they do not restrict deletion for users who otherwise have modify/delete object permissions.

Escalation Rule

Why it fails: Escalation rules manage cases.

Mass Delete Wizard

Why it fails: Mass Delete Wizard permanently removes selected records in bulk and offers no matching, comparison or merge capability, so it cannot identify duplicates at all. It is intended for purging obsolete or test data en masse; duplicate remediation requires the duplicate rules and matching functionality that surface candidate records for merging.

Data Import Wizard deduplication wizard

Why it fails: The Data Import Wizard imports records and can prevent new duplicates during insert, but it does not scan existing Account records to identify or merge them. It is the right tool when loading a file and blocking duplicates at entry; cleaning records already residing in Sales Cloud needs native duplicate identification and merge features.

Data Loader upsert operation

Why it fails: Upsert updates or inserts based on external IDs, it does not merge duplicate records.

Web-to-Lead settings

Why it fails: Web-to-Lead captures inbound form submissions and creates leads; it applies no field-level visibility control to existing records. It tempts because it governs data capture, but masking Tax ID for sales reps requires field-level security plus a permission set or profile granting finance managers access.

Assignment Rules

Why it fails: Assignment Rules route new leads and cases to owners or queues; they never restrict field visibility. It tempts because it is a common Sales Cloud security-adjacent feature, yet Tax ID masking demands field-level security combined with permission sets or profiles for finance managers.

Sharing Rules

Why it fails: Sharing Rules grant record-level access to groups of users; they cannot hide individual fields such as Tax ID. It tempts because sharing is the usual answer for access questions, but field masking requires field-level security plus a permission set or profile for finance managers.

Attachments cannot exceed 5 MB when loaded via Data Loader.

Why it fails: Data Loader accepts attachments up to 100 MB, so a 5 MB ceiling is wrong; that limit applies to Data Import Wizard. It is tempting because attachment size limits genuinely constrain migration planning, and 5 MB is the real wizard threshold, making it the correct consideration for wizard-based loads.

Attachments must be converted into Campaign records first.

Why it fails: Attachments load directly against Account records via Data Loader or the wizard; no Campaign conversion step exists. It is tempting because Campaigns also hold attachments and relate to accounts through influence, but that relationship is unrelated to migrating legacy account files.

Notes and attachments must be loaded into the User object.

Why it fails: Notes and attachments are loaded against the parent Account, Contact, Case or similar record, not the User object; User holds no such child relationship. It is tempting because the loading user needs API access and permissions, but ownership of the running user is not the target parent.

Automatically merge the duplicate with the master record in real time.

Why it fails: Automatic real-time merging is not a native action of standard duplicate rules without custom code.

Automatically delete the newly entered duplicate record.

Why it fails: Salesforce does not automatically delete newly entered duplicates; it either blocks or alerts.

ISCHANGED()

Why it fails: ISCHANGED checks if a field value was modified during an update, which is not specific to format validation.

VLOOKUP()

Why it fails: VLOOKUP is for cross-object table lookups, not URL string validation.

PRIORVALUE()

Why it fails: PRIORVALUE returns the previous value of a field.

OpportunityLineItem

Why it fails: Opportunity Products do not support custom External ID fields.

Task

Why it fails: Activities (Tasks and Events) do not support custom External IDs for upsert operations in standard Data Loader.

Duplicate Rule configuration

Why it fails: Duplicate rules handle matching, not lead conversion record type assignments.

Data Import Wizard

Why it fails: Data Import Wizard is an import tool, not conversion logic configuration.

Territory Management rules

Why it fails: Territory management assigns accounts to territories, not lead conversion record types.

Rely on workflow rules to backdate the opportunity automatically.

Why it fails: Workflow rules fire on record save and would overwrite the loaded CloseDate rather than preserve it. Workflow-based backdating suits ongoing record maintenance after migration, not bulk historical preservation, where the requirement is disabling automation during load.

Map CloseDate to the SystemModstamp field.

Why it fails: SystemModstamp is a read-only system audit field tracking last modification, so it cannot carry historical CloseDate values. Mapping to it suits tracking record recency for integrations, not preserving business dates, which requires loading the actual CloseDate field with automation suppressed.

Convert opportunities as closed-lost first, then reopen them.

Why it fails: Converting as closed-lost then reopening triggers automation, alters stage history, and risks overwriting CloseDate on the reopen. This pattern suits correcting mis-staged deals individually, not bulk migration, where the requirement is loading closed-won records with historical dates intact.

Data Import Wizard

Why it fails: Data Import Wizard is an import tool, not real-time entry formatting automation.

Assignment Rule

Why it fails: Assignment rules handle record routing.

Web-to-Lead auto-response rule

Why it fails: Auto-response rules send email notifications, they do not format field data.

Data Loader export-import loop.

Why it fails: Manual or scheduled batch exports do not provide real-time creation checks.

Standard Validation Rule referencing external ERP database tables via formula.

Why it fails: Validation rules cannot query external systems or ERP databases directly.

Scheduled Flow running nightly to check ERP status and delete invalid opportunities.

Why it fails: A nightly schedule leaves invalid opportunities in the system for up to 24 hours, failing the real-time requirement.

Use the Data Loader 'Allow Duplicates' setting in the import wizard to bypass duplicate rules.

Why it fails: Data Loader does not have an 'Allow Duplicates' setting. Duplicate rules are enforced at the Salesforce platform level, not by the Data Loader client. The only way to bypass them is to deactivate the rules or use an API that ignores them. This option describes a nonexistent feature.

Import the records using the Bulk API in parallel mode, which automatically skips duplicate checks.

Why it fails: The Bulk API does not skip duplicate checks. Duplicate rules apply regardless of the API used. Parallel mode affects performance and record locking, not duplicate detection. Using Bulk API in parallel mode may actually increase the chance of duplicate rule errors due to concurrency, and it does not provide a way to bypass them.

Set the duplicate rule action to 'Allow' and the alert to 'No Alert' for the migration user's profile.

Why it fails: Duplicate rule actions and alerts are configured on the rule itself, not by profile. While you can assign duplicate rules to specific profiles, the action remains global for that rule. Changing the action to 'Allow' would permit duplicates for all users, not just during migration, which is not the intended temporary workaround.