How to Export Salesforce Contacts to a Clean Excel Format

Exporting Salesforce contacts to Excel is straightforward, but getting a clean workbook requires one important decision before you click Export: choose a detail-level export that gives Excel one row per contact, then control how Excel interprets text-like values such as Salesforce IDs, phone numbers, and postal codes.

The current Salesforce documentation reviewed in September 2026 still makes the same practical distinction that matters most here: a Formatted Report is designed to preserve the report's presentation, while Details Only is designed to give you the underlying rows for calculations and downstream work. For most contact lists that will be filtered, deduplicated, sorted, or handed to another system, Details Only is the better starting point. See Salesforce's official report export documentation.

The short answer: which export format should you choose?

Action: If your goal is an ordinary contact workbook, start with Details Only XLSX. Switch to Details Only CSV when preserving text exactly matters more than convenience.

Step 1: Build a contact report with only the records and fields you actually need

Start in Salesforce Reports. Use an account-and-contact report type that exposes the contacts you need, or a custom report type if your organization has configured reporting differently. Report availability, field visibility, and permissions can vary by Salesforce edition and org configuration, so the exact report type name is not universal. Salesforce notes that standard report types are customizable and that administrators can create custom report types when the standard choices do not expose the needed data. See Salesforce's standard report type guidance.

Add only the columns you need. A practical contact export often includes Contact ID, First Name, Last Name, Account Name, Title, Email, Phone, Mobile, Mailing Street, Mailing City, Mailing State/Province, Mailing Postal Code, Mailing Country, Owner, and any business-specific status or segmentation fields.

If the file may ever be matched back to Salesforce, include Contact ID. Salesforce explicitly recommends including record IDs in export files used for later imports because those IDs uniquely identify the records; Salesforce record IDs are also case-sensitive. See the official export-file guidance for import workflows.

Common misconception: Email is not always a safe unique key. Two contacts can share an email address, a contact can have no email, and an email can change. Contact ID is the safer technical key when the spreadsheet must remain traceable to Salesforce.

Action: Add Contact ID before exporting, even if you plan to hide that column in the final presentation copy.

Step 2: Export the report as Details Only

Run the report, open the report actions menu, and choose Export. In Lightning Experience, Salesforce offers two export views:

• Formatted Report: preserves the report header, groupings, and filter details and exports as XLSX.
• Details Only: exports the underlying rows without report formatting and is intended for spreadsheet calculations or downstream use.

For a clean Excel contact list, choose Details Only. Then choose XLSX, XLS, or CSV according to what you need to preserve.

Common misconception: “Formatted Report” sounds more polished, so it must be better for Excel. In practice, presentation formatting often makes data cleaning harder because it brings report structure into the workbook. Salesforce's own help article says Details Only is the option to use when you want to do calculations in the spreadsheet.

There is also an important text-field exception. Salesforce published a May 2026 support article stating that Long Text Area and Rich Text Area fields can be truncated to 255 characters in Formatted Report exports and in Details Only XLSX exports. The same article says Details Only CSV or XLS can be used when the full field content is required. See Salesforce's long-text export guidance.

Action: Use Details Only XLSX for ordinary contact fields. If you included a long Notes, Description, or rich-text custom field whose full content matters, use Details Only CSV instead.

Step 3: If you exported CSV, import it into Excel instead of double-clicking it

A CSV file does not store Excel data types. When Excel opens one directly, it may infer what each column “looks like.” That is convenient for ordinary numbers and dates, but risky for identifiers.

Microsoft documents several automatic conversions that can alter text-like values: leading zeros can be removed, long digit strings can be converted or lose precision, strings containing “E” can be treated as scientific notation, and date-like strings can be converted to dates. See Microsoft's guidance on preserving leading zeros and large numbers.

Instead of double-clicking the CSV, use Excel's import path:

1. Open a blank workbook.
2. Choose Data → Get Data → From File → From Text/CSV.
3. Select the Salesforce CSV.
4. Choose Transform Data when you need to control column types before loading.
5. Set columns such as Contact ID, Account ID, postal code, phone, mobile, and other codes to Text.
6. Set true date fields to Date or Date/Time only when that interpretation is correct.
7. Choose Close & Load.

Microsoft's current Power Query documentation confirms that the Text/CSV connector detects delimiters, headers, and types, and lets you transform the data before loading it. See Import data from data sources with Power Query.

Common misconception: A phone number is a number. For data-cleaning purposes, it usually is not. You do not calculate with it, and punctuation, country prefixes, extensions, or leading zeros may be meaningful. Treating phone numbers as Text is generally safer.

Action: Before loading a CSV, explicitly set every identifier and code-like column to Text.

Step 4: Clean the contact table without destroying record identity

Once the data is in Excel, make a raw copy before deleting or normalizing anything. A simple workbook structure is useful:

• Raw_Export: untouched Salesforce rows.
• Clean_Contacts: the working table after cleanup.
• Exceptions: optional rows that need manual review, such as missing emails or possible duplicates.

Remove columns you do not need

Delete or hide internal fields that the recipient does not need, but keep Contact ID somewhere in the workbook if traceability matters. If the workbook will leave your organization, review whether internal ownership, notes, or other sensitive fields should be included at all.

Trim accidental whitespace

Leading or trailing spaces can make apparently identical values compare as different. In Power Query, text cleanup can be applied consistently across a column; Microsoft's Power Query function documentation describes Text.Trim as removing leading and trailing characters, with whitespace removed by default. See Microsoft's Text.Trim documentation.

Handle duplicates carefully

Do not immediately remove every duplicate email address. First decide what “duplicate” means for your business. If your objective is one row per Salesforce Contact, Contact ID should be unique. If your objective is one reachable person per email address, duplicate emails may deserve review rather than automatic deletion.

Excel and Power Query can remove duplicate rows based on selected columns. Microsoft notes that duplicate removal uses the columns you select as the comparison key. See Microsoft's Power Query duplicate-row guidance.

Action: Highlight or isolate suspected duplicates first. Remove them only after you have chosen an explicit business key such as Contact ID, or a carefully defined combination of fields.

Step 5: Validate the workbook, then save it as XLSX

Before calling the workbook “clean,” perform a short reconciliation:

• Compare the exported row count with the Salesforce report result you intended to export.
• Confirm Contact IDs are still text strings and have not been altered.
• Spot-check postal codes that begin with zero.
• Check international phone numbers and extensions.
• Verify blank values are genuinely blank rather than the result of a filter or failed transformation.
• Check a few accented or non-English names to make sure character encoding is intact.
• If you removed duplicates, record how many rows were removed and by which key.

Then save the working file as Excel Workbook (.xlsx). If the source was CSV and you used Power Query, keeping the workbook lets you preserve the transformation steps. Microsoft notes that Power Query queries can be refreshed and will reapply their transformations to updated source data. That is useful when this export becomes a recurring monthly or weekly process.

Action: Keep the original Salesforce export untouched, and save the cleaned workbook as a separate XLSX file with a clear date or reporting period in the filename.

When should you use Data Loader instead of a report export?

For a human-readable contact spreadsheet, reports are usually easier because you can choose business-friendly columns and filters in Salesforce before exporting. Data Loader becomes more attractive when the extract is very large, needs SOQL-style filtering, includes technical fields, or must be repeated in an operational process.

Salesforce describes Data Loader as a client application for bulk import and export. It outputs CSV files on export and supports files with up to 5 million records. See the official Salesforce Data Loader documentation.

For backups, use a different tool again. Salesforce's Data Export service is designed to export broad sets of org data into CSV files on a weekly or monthly basis depending on edition. That is useful for backup, but it is usually excessive when the actual deliverable is a curated contact workbook. See Salesforce's backup data export documentation.

What can vary by Salesforce organization?

Some parts of this workflow are verified platform behavior; others depend on your org:

• Verified platform behavior: Salesforce supports report export, distinguishes Formatted Report from Details Only, and supports spreadsheet-oriented export formats in Lightning Experience.
• Org-dependent: the report types you can see, the fields exposed in those report types, field-level security, record visibility, and whether you have the Export Reports permission.
• Data-dependent: whether email is unique enough for deduplication, whether postal codes need leading zeros, and whether long text fields require CSV rather than XLSX.

If the Export option is missing, Salesforce's help documentation advises contacting your Salesforce administrator. Do not assume an absent button means the feature was removed; permissions are a common reason.

A clean-output checklist

• Use a report filtered to the exact Contacts you need.
• Include Contact ID for traceability.
• Prefer Details Only over Formatted Report for analysis-ready data.
• Use XLSX for ordinary contact fields; use CSV when long-text preservation or import-type control matters.
• Import CSV through Power Query instead of blindly opening it.
• Keep IDs, postal codes, phone numbers, and code-like values as Text.
• Preserve an untouched raw export.
• Define the deduplication key before removing rows.
• Validate row counts and sample values.
• Save the cleaned deliverable as a separate XLSX workbook.

The central principle is simple: Salesforce should decide which records and fields belong in the extract; Excel should handle typing, cleanup, review, and presentation. Keeping those responsibilities separate produces a workbook that is easier to audit, safer to refresh, and less likely to contain silent data-conversion errors.