How to Insert Accounts into Salesforce Using Data Loader

File Prep, Mapping, and a Clean Run

Importing company records sounds simple until you hit the stuff that causes rework, like silent truncation, audit fields you can’t fix later, and lookups that don’t match. This walkthrough shows a practical way to prep your file and load Salesforce Data into Account records using Data Loader, with the goal of getting a clean success run on your first try.

If you want a visual walkthrough, check out How to Insert Accounts into Salesforce using Data Loader for a step-by-step guide.

Prep & Map Your Data Before You Insert Accounts in Salesforce

Before you open Data Loader to insert Accounts, get your spreadsheet into ‘load-ready’ shape. The fastest loads usually come from two things:

• A file that already respects Salesforce field limits and formats
• Column headers that match Salesforce field API names (so Data Loader can auto-match)

That prep work is what keeps you from chasing errors after the fact.

Minimum requirements for Account records

To create a new Account, only one field is required: the Account Name.

Salesforce enforces a 255-character limit on the Account Name. If your source data has a name longer than that, Salesforce truncates it automatically. The painful part is you won’t get told which rows were truncated, so it’s easy to miss until someone notices a chopped company name later.

A quick check in Excel catches this before you load.

Steps to flag long names with the LEN formula:

• Add a new column called something like Name Length.
• In the first row of that column (example: row 2), enter =LEN(A2) (use the cell that contains the Account Name).
• Fill the formula down for all rows.
• Filter the Name Length column to show values greater than 255.
• Fix those names in the source before you export your CSV.

If you keep the length check column during prep, remove it before the final CSV unless you plan to map it to a real Salesforce field.

List of native Account fields (and why it matters)

A reliable mapping starts with knowing what fields exist on Account and how they’re configured (data type, length, picklist values, requiredness, and so on). A field reference list is also where you get the field API names, which are what Data Loader uses during mapping.

This matters because the mapping goes faster when you work with API names, and it’s more accurate. Field labels can be changed, and labels can be similar. API names are stable and unique on the object.

When you’re working in a real org, you can also cross-check field details in Salesforce setup and documentation. For related Data Loader help content, Salesforce’s help library is useful, for example: Insert files with Salesforce Data Loader.

Why using field API names speeds up Data Loader mapping

If you’ve ever dragged fields around in the Data Loader mapping screen, you already know how easy it is to mis-map something. Using API names changes the experience.

Here’s the practical difference:

1. API names: Unique per object, friendly to auto-match, less manual mapping.
2. Field labels: Not guaranteed unique, easier to misread, more dragging and dropping.

When your CSV headers match the Account field API names, you can use Data Loader’s auto-match feature, then spend your time reviewing instead of manually connecting every field. That’s how you move fast while keeping accuracy high.

One more benefit: API names reduce ambiguity. “Billing Street” is a label. BillingStreet is the target.

Salesforce doesn’t clean your data for you

Salesforce will accept almost anything you give it if it passes basic validation rules. It’s not a magical cleansing tool.

If your source system has inconsistent casing, messy address lines, or placeholder values, those often come into Salesforce exactly as-is. Data cleanup takes time, and it’s commonly out of scope unless someone explicitly asks for it.

Before you load thousands of Accounts, make sure expectations are clear on what gets cleaned, what stays as-is, and what “good enough” means.

Default field behavior you need to understand before you insert

A load can “succeed” and still be wrong if you miss how Salesforce sets certain fields by default.

Account Owner and audit fields (Created By, Created Date)

• Owner: If you don’t set the Account Owner during insert, Salesforce makes you the owner. That’s annoying, but it’s fixable later with an update.
• Audit fields: You can only set Created By and Created Date at insert time (assuming your org and permissions allow it). You can’t fix these later with a normal update.

If audit fields are part of the requirements and you forget to set them on insert, the fix is ugly:

• Missed audit fields means delete and re-import (if you need those fields to be historically accurate).

That’s why it’s worth slowing down during file prep to decide whether you’re setting audit fields as part of the insert.

Parent Accounts and a quick note on Person Accounts

If your source data includes a historical “parent company” relationship, plan for a two-step process:

• Insert Accounts first.
• Do a follow-up update to populate Parent Account once you have Salesforce IDs to reference.

Person Accounts are a separate topic and require their own setup and handling, so they’re not included in this process.

Mapping record types and user IDs (without creating lookup errors)

Two areas cause most insert problems for Accounts:

• Record Types
• User lookups (Owner and Created By)

Two ways to map Record Types

In the example org, there are two Account record types: Business and Partner. Each record type has its own ID.

You can map record types in two common ways:

Method	Data Loader setting	What your CSV column looks like
Map by Name	Set Record Type lookup to Name	A column containing the record type name (example values: Business, Partner)
Map by ID	Do not set Record Type by Name	A column containing the Record Type ID

Mapping by name is often faster, but there’s a catch: if record type names overlap across objects (for example, the same record type name exists on both Account and Contact), mapping “by name” can cause confusion and errors because of how the lookup resolves.

A simple rule that works well in practice:

• If record type names are clearly distinct across your org’s objects, mapping by name is convenient.
• If your org reuses record type names in multiple places, mapping by ID is safer.

Map Account Owner & Created By for a Smooth Insert Accounts Run

You typically have two options for mapping user lookups:

• Salesforce User ID
• A custom Legacy ID field on User marked as an External ID (loaded earlier)

What you can’t do is mix both approaches in a single Data Loader run. Data Loader will throw an error if you try to provide both a Salesforce ID and an external ID reference for the same lookup mapping.

Another common failure point: if you reference legacy user IDs that were never loaded into Salesforce, Data Loader will fail the lookup because it can’t find the foreign key (external ID) value you referenced.

If your migration approach is “load Users first, then load Accounts,” mapping owner and created-by via legacy IDs is a clean pattern because it keeps your source system identifiers intact.

For extra context on loading Users (since Accounts often depend on them), this is a helpful walkthrough: Insert Users With Data Loader in Salesforce Tutorial.

Preparing the Excel workbook so Data Loader cooperates

A workbook-based workflow is common: you receive an export from another system, organize it in Excel, then export one tab as a CSV for Data Loader.

Start with a “Sample Accounts” style tab, then build a mapped tab

A practical workbook layout looks like this:

• Sample Accounts: Raw extract, including an ID from the old system, a type indicator (like Business or Partner), and legacy user identifiers for Owner and Created By.
• Accounts Mapped: A clean version where headers are aligned to Salesforce field API names and any transformation decisions are applied.

This is where the main decisions happen:

• Record type mapping approach (name vs ID)
• Owner and Created By approach (legacy ID vs Salesforce ID)
• Field-to-field mapping for addresses and other standard fields

Decide record type strategy based on naming conflicts

A common pattern is using a “Type” or “Category” field from the old system to drive record type in Salesforce.

If you have “Business” and “Partner” record types on both Account and Contact, mapping by name can backfire. If the names are different (for example, Contact record types have a different naming convention), mapping by name is simpler and works fine.

The key is to decide before you build your CSV, because it changes how you set Data Loader Step 2B and what your headers and values look like.

Format Created Date as a date-time value (before exporting to CSV)

Created Date is a date-time field in Salesforce. If you load it as plain text or an inconsistent format, you can get failed rows or wrong timestamps.

A straightforward approach in Excel:

1. Find or define the exact date-time format you want to use (many teams store this on a dedicated “formatting” tab).
2. Apply that custom format to the entire Created Date column in your mapped tab.
3. Re-check a few sample rows to confirm they show both date and time.

This is one of those small steps that prevents a surprising number of errors.

Create the final CSV (and remove what Data Loader can’t use)

Data Loader can’t import an Excel tab directly. It needs a CSV.

Before you export:

• Keep only the columns you intend to load.
• Make sure the header row contains your final field API name headers.
• Remove any “helper” columns you used for checking (like Name Length), unless they map to real Salesforce fields.
• Export the mapped tab to CSV.

Step-by-Step Guide to Insert Accounts in Salesforce Using Data Loader

Once your CSV is ready, the Data Loader run to insert Accounts is usually quick. The work is in the prep and mapping review.

1) Start the insert

In Data Loader:

• Click Insert
• Select the object: Account
• Choose your prepped CSV file
• Continue to the mapping steps

For official guidance on the insert flow, Salesforce also documents the steps in: How to Insert, Update, and Delete Salesforce Data Using Data Loader.

2) Set lookup behavior in Step 2B

In the example approach:

• Created By: set lookup to your chosen external reference (example: Legacy ID)
• Owner: set lookup to the same external reference (example: Legacy ID)
• Record Type: set lookup to Name (if you’re mapping by name)

This is where you lock in the “how” behind the lookup resolution. Your CSV values must match what you selected here.

3) Auto-match fields, then review the mapping

Use auto-match, then slow down and review.

A quick checklist before you run:

• Record Type mapping points to the correct record type field
• Legacy ID field on Account maps to the correct external ID field
• Owner and Created By map to the correct user reference (and only one method is used)
• Address fields map to the standard Account address fields you expect (Billing, Shipping, etc.)
• No extra columns are floating around unmapped unless you intended them

4) Run the job and check the results

Choose your output folder and run the insert. Data Loader generates:

• A success file (rows that loaded, with Salesforce IDs)
• An error file (rows that failed, with messages)

The target outcome is the same one everyone wants: 100% Successes.

What to do with the success file (don’t skip this)

A clean run doesn’t mean the data is right. It means Salesforce accepted it.

After the insert:

1. Rename the success file to something you can recognize later (date, object, environment).
2. Copy the success rows into a new Success tab in your workbook.
3. Take the first Salesforce Account ID from the success output.
4. Open Salesforce and verify the record details field-by-field.

This verification step is where you catch issues like:

• Record type loaded, but not the one you expected
• Owner loaded as you (because the lookup did not match)
• Address fields swapped (street in city, city in state, etc.)
• Created Date set wrong due to formatting

If you plan to update Parent Account relationships after the insert, the success file is also how you connect “old parent ID” logic to the newly created Salesforce IDs.

Common errors and best practices that prevent rework

Most Data Loader issues come from a few predictable causes.

• Silent truncation on Account Name: Check lengths before load so names don’t get chopped without notice.
• Missing lookups (Owner, Created By): Load Users first and confirm your legacy IDs exist in Salesforce before referencing them.
• Record type confusion: If names overlap across objects, map record types by ID, not by name.
• Mapping mistakes from labels: Use API names so auto-match works and you can trust the mapping faster.

Good prep feels slow, but it usually saves hours later. It also prevents rework when you’re loading more objects that depend on Accounts.

Practice exercise: run the full flow in a Developer Org

To practice end-to-end:

1. Log into your free Developer Org.
2. Create two Account record types: Business and Partner.
3. Create a Legacy ID field on Account and mark it as an External ID.
4. In your workbook, copy the sample account data into a new working tab.
5. Build your Accounts Mapped tab with API name headers and your lookup choices.
6. Export that mapped tab to a CSV.
7. Use Data Loader to insert the Accounts, then verify results in Salesforce.

Once you can repeat this without errors, you’re ready for the next logical step: loading Contacts.

Conclusion

A clean Account load is less about clicking “Insert” and more about making a few smart choices upfront: field limits, API name headers, record type strategy, and consistent user lookups. If you treat your success file like a receipt and actually verify a few records, you catch problems before they spread to Contacts and Opportunities. The goal is simple: accurate Salesforce Data that you can trust. Run the exercise, get your process tight, then move on to Contacts with confidence.