Salesforce administrators spend a surprising amount of time protecting the quality of data that already exists while bringing in data from somewhere else. A migration, campaign upload, account cleanup, territory change, or integration can create thousands of correct records\u2014or thousands of problems\u2014in a few minutes. The current Salesforce Platform Administrator<\/a> certification reflects that reality: Salesforce’s current exam-prep material assigns 17% of the exam to data and analytics management, alongside configuration, applications, access, automation, and Agentforce.<\/p>\n Salesforce now publicly presents the credential as the Salesforce Certified Platform Administrator<\/strong>. The site inventory still uses the familiar Before selecting Data Import Wizard, Data Loader, an integration, or another utility, define what the import is supposed to accomplish. Are you adding new leads, updating existing contacts, migrating accounts from another CRM, loading reference data, or correcting a historical error? The same CSV can require completely different handling depending on whether records should be inserted, updated, upserted, or rejected.<\/p>\n The safest plan identifies the target objects, key fields, ownership, required values, record types, lookup relationships, validation rules, automation, duplicate controls, and the field that uniquely identifies each source record. If that mapping is unclear, the import tool will not fix the ambiguity. It will simply execute the ambiguity at scale.<\/p>\n Administrators also need to understand who owns the data after import. A technically successful load can still be operationally wrong if every record lands under one user, the wrong queue, or an inactive owner. Data movement is therefore part of process design, not merely file handling.<\/p>\n Field mapping deserves its own review. A source column called \u201cStatus\u201d might appear obvious but can map to different business concepts across objects. Administrators should confirm data types, length limits, picklist values, required fields, and whether source values need transformation. A mapping document also becomes evidence when someone later asks why a historical value was placed in a particular field.<\/p>\n Salesforce’s Data Import Wizard is available from Setup and supports common standard objects such as accounts, contacts, leads, person accounts, campaign members, and custom objects. Salesforce’s current Trailhead guidance states that the wizard can import up to 50,000 records at a time and provides a guided interface for mapping source columns to Salesforce fields.<\/p>\n The wizard is especially useful when an administrator needs a controlled import with clear mappings and no need for a complex command-line workflow. It can add records, update records, or perform combinations depending on the object and import configuration. A small test file is a strong practice because it reveals mapping mistakes, validation failures, unexpected automation, or formatting issues before the full file is committed.<\/p>\n The most important lesson is that \u201ceasy to use\u201d does not mean \u201csafe to skip planning.\u201d Even a few thousand incorrectly mapped contacts can create cleanup work that takes far longer than the import itself.<\/p>\n Related-object sequencing matters during migrations. Accounts often need to exist before contacts or opportunities can reference them, and custom parent records may need to be created before child records. Loading in the wrong order creates lookup failures or temporary orphan logic that later cleanup must repair.<\/p>\n For higher-volume work, more objects, exports, deletes, or repeatable administration, Data Loader or API-based approaches provide more control. These tools work well when the administrator needs explicit operation types, reusable field mappings, error files, or scheduled processing. They also make it easier to work with object IDs and external IDs across related datasets.<\/p>\n That power raises the stakes. A bulk update can overwrite good data quickly if the key field is wrong. A delete operation can remove records faster than users notice. Administrators should back up relevant data, test on a representative subset, and preserve the success and error results from each operation.<\/p>\n A useful mental model is to separate extract, transform, and load even when the transformation is simple. The article on bringing API data into analysis tools<\/a> illustrates the same idea from another direction: reliable data work depends on understanding source shape, transformation, and destination constraints.<\/p>\n Update operations can unintentionally blank fields if the source file contains empty values and the tool is configured to treat them as null. Conversely, leaving blanks untouched can preserve obsolete data that the migration intended to remove. The handling of nulls should be an explicit decision rather than an import default nobody reviewed.<\/p>\n When records originate in another system, Salesforce record IDs usually are not available in the source data. An external ID field can provide a durable business key that represents the source system’s identifier. Upsert operations can then update an existing record when the key matches or insert a new record when it does not.<\/p>\n This pattern is safer than trying to decide uniqueness from names alone. Two customers can share a name, a company can change its name, and email addresses can change or be shared. The best external key is one that the source system treats as stable and unique.<\/p>\n External IDs also help with relationships. A parent object can be loaded first, then child records can reference the parent’s external identifier rather than requiring a manual lookup of every Salesforce ID. That makes migration logic easier to reproduce and audit.<\/p>\n Data types can also hide localization problems. Dates, decimal separators, phone formats, state codes, and character encodings may vary between source systems or countries. A small test file should include these edge cases, not only the easiest records, so transformations are validated before the full load.<\/p>\n Salesforce duplicate management separates detection from enforcement. Matching rules define how potential duplicates are identified. Duplicate rules use those matches to decide whether users or integrations should be warned, allowed, or blocked when records are created or updated. Salesforce provides standard matching behavior for common objects and also allows custom rules.<\/p>\n This distinction becomes important during bulk loads. A Data Loader insert can fail with a \u201cUse one of these records?\u201d message when active duplicate or matching rules detect a conflict. The right response is not automatically to disable the rule. First determine whether the source record is genuinely new, whether the matching logic is too broad, or whether the import should update an existing record instead.<\/p>\n Duplicate rules are part of data governance. They should reflect the organization’s definition of a duplicate, which may differ between leads, contacts, accounts, and custom objects.<\/p>\n Large migrations benefit from reconciliation controls. Source counts, destination counts, rejected rows, duplicate warnings, and transformed values should be recorded so the team can explain exactly what happened. A migration is much easier to defend when every source row can be classified as inserted, updated, rejected, or intentionally skipped.<\/p>\n Source files commonly contain inconsistent capitalization, whitespace, obsolete values, malformed dates, missing country codes, duplicate rows, invalid picklist values, and inconsistent identifiers. Cleaning before import improves match accuracy and reduces avoidable validation errors. It also prevents bad source patterns from becoming normalized inside Salesforce.<\/p>\n Post-import validation is equally important. Administrators should compare record counts, review error files, spot-check key records, verify ownership and relationships, and run reports that expose unexpected blanks or duplicates. A successful status from the import tool confirms that Salesforce accepted the transaction; it does not prove that the resulting data is correct for the business.<\/p>\n The broader principles in data lifecycle management<\/a> apply here too: data quality, access, retention, and ownership should be considered from ingestion through eventual deletion.<\/p>\n Duplicate prevention should be paired with a process for resolving existing duplicates. Matching rules can identify candidates, but business ownership is needed to decide which record survives, how related activities are merged, and whether identifiers must be preserved. Automatic merging without understanding record history can destroy valuable context.<\/p>\n Salesforce does not import into an empty rules engine. Validation rules, record-triggered flows, assignment rules, Apex, duplicate rules, and other automation can run as records are created or updated. A file that appears valid in a spreadsheet may fail because the org enforces requirements that the source system never had.<\/p>\n Administrators should know which automation is expected to run during a migration and which behavior could create unwanted side effects such as email notifications, task creation, ownership changes, or updates to related records. The right solution is not necessarily to deactivate everything. It may be to prepare the data so it satisfies the intended controls or to use a controlled migration strategy that accounts for those controls.<\/p>\n This is where the relationship with Salesforce Platform Developer<\/a> knowledge becomes useful: administrators do not need to write every line of code, but they should understand when custom logic can influence a data transaction.<\/p>\n Sandbox testing is particularly useful when imports interact with validation and automation. A representative copy of configuration allows administrators to discover side effects without emailing customers, reassigning production records, or changing live pipeline metrics. The test should include enough realistic data to exercise the same rules that production will use.<\/p>\n Data export is not only the reverse of import. Administrators export records to support backups, external analysis, migration, reconciliation, legal requests, and integration troubleshooting. The scope of an export should match the purpose. A full backup may need attachments or related data; a reconciliation may need only identifiers and a few control fields.<\/p>\n Exports also create a security boundary. Data that is protected by Salesforce sharing and field permissions can become an ordinary file once it leaves the platform. Administrators must consider where exported files are stored, who can access them, how long they are retained, and how they are deleted.<\/p>\nadm-201<\/code> destination, so this article uses that approved internal URL while following the current Salesforce terminology. The broader Salesforce certifications<\/a> ecosystem is useful context, but the administrator’s practical job is to move data deliberately, preserve relationships, and stop avoidable duplicates before users lose trust in the org.<\/p>\nData movement begins with the business purpose, not the import tool<\/h3>\n
The Data Import Wizard is designed for common, guided imports<\/h3>\n
Data Loader and API-oriented tools suit larger or more controlled operations<\/h3>\n
external IDs and upsert operations reduce accidental duplication<\/h3>\n
matching rules identify potential duplicates; duplicate rules decide what to do<\/h3>\n
data cleansing should happen before and after the load<\/h3>\n
automation and validation rules can change import behavior<\/h3>\n
exports are part of backup, audit, analysis, and migration workflows<\/h3>\n