salesforce 15 to 18 ID Converter | SalesforceTutorial

Salesforce 15 to 18 conversion means changing a 15-character Salesforce record ID into its 18-character case-safe form. Use the 18-character ID when data leaves Salesforce for Excel, SQL, CSV imports, middleware, or reporting tools that may not preserve letter case.

The short version for salesforce 15 to 18: inside Salesforce, a record ID can appear as 15 or 18 characters. Outside Salesforce, standardize on 18 characters unless a specific Salesforce feature asks for the 15-character value.

Release note: This article uses standard Salesforce formula and Apex ID behavior documented in current Salesforce platform references. No Beta or Pilot feature is required for the conversion patterns shown here; compile Apex examples with the API version approved for your org.

What is salesforce 15 to 18 ID conversion?

A Salesforce record ID is the stable identifier for a record such as an Account, Contact, Case, User, or custom object row. Salesforce documentation describes ID fields as 15 to 18 characters long, and the platform treats the 18-character form as case-safe. The salesforce 15 to 18 conversion adds three characters to the original 15-character value so systems that ignore case can still work with the correct record.

This salesforce 15 to 18 distinction matters because many tools outside Salesforce do not treat ABC and abc as different values. If a spreadsheet, database collation, or integration step changes case during a join, a 15-character ID can point to the wrong value or fail during an update. The 18-character form reduces that risk.

A salesforce 15 to 18 conversion does not create a second record ID. It produces the case-safe representation of the same record identifier, which is why the value remains safe for updates, deletes, and joins when the source ID is valid.

Salesforce’s Object Reference notes that 18-character IDs are case-safe, not simply case-insensitive. If someone changes the casing inside an 18-character ID by hand, Salesforce can reject it because the added characters no longer match the original case pattern. See the official Salesforce Object Reference for ID field behavior at Salesforce field types.

When should admins use salesforce 15 to 18?

Use salesforce 15 to 18 conversion before the ID becomes part of a process that Salesforce does not fully control. In enterprise orgs, this usually appears during data migration, Excel reconciliation, duplicate cleanup, middleware mapping, and system-to-system record updates.

Make salesforce 15 to 18 handling part of the same data standard as date formats, external IDs, and owner mappings. Teams that wait until the import error file appears usually spend more time tracing rows than converting the IDs at the start.

Common cases include:

• Excel or Google Sheets matching: XLOOKUP, VLOOKUP, and pivot tables can hide ID problems when letter case changes.
• Data Loader updates: normalize the record ID column before the file reaches an update, upsert, or delete job.
• ETL and SQL staging: some database collations compare strings without case sensitivity.
• Support operations: case exports, user extracts, and audit files often move between systems before someone loads them back.
• Marketing Cloud Engagement: AMPscript has a Salesforce-specific function for converting a short Salesforce ID when working with Sales or Service Cloud data.

For a broader salesforce 15 to 18 import workflow, pair this article with Salesforce Data Loader best practices and Salesforce reports for admin exports.

How to run salesforce 15 to 18 conversion in Salesforce

There is not one best salesforce 15 to 18 method for every team. Choose the method based on where the ID is produced, who owns the process, and whether the data contains customer or regulated information.

For repeat work, document the approved salesforce 15 to 18 path in the runbook. The runbook should say where the 18-character ID comes from and who validates the file before upload.

How to convert 15 to 18 salesforce with CASESAFEID

The most direct Salesforce-native method is the formula function CASESAFEID(). Salesforce’s formula documentation defines CASESAFEID as the function that converts a 15-character ID to a case-insensitive 18-character ID. The typical formula field is:

CASESAFEID(Id)

Use this salesforce 15 to 18 approach when admins need an 18-character ID in list views, reports, exports, or simple reconciliation files. The setup path is:

1. Go to Setup > Object Manager.
2. Open the object that needs the converted ID, such as Account or a custom object.
3. Select Fields & Relationships > New.
4. Choose Formula, set the return type to Text, and name the field something clear, such as Record_ID_18__c.
5. Enter CASESAFEID(Id) as the formula.
6. Set field-level security and page/report visibility only for users who need the value.

Formula fields are calculated by Salesforce. They do not require a trigger, flow, batch job, or stored copy of the ID. Review the official formula function documentation at Salesforce formula operators and functions and the CASESAFEID Help page at Salesforce CASESAFEID documentation.

When salesforce 15 to 18 conversion belongs in Apex

Use Apex when salesforce 15 to 18 conversion is part of a custom UI, an integration helper, a managed admin tool, or a controlled process that receives mixed 15-character and 18-character values. The Apex Id type can normalize a valid Salesforce ID, and the Apex Reference includes Id.valueOf() and to15() behavior.

The following salesforce 15 to 18 class accepts a list of possible record IDs and returns both forms. It performs no SOQL and no DML, so governor-limit risk is low. Still, do not pass unbounded CSV files through a synchronous LWC call; batch large conversions in files before upload or use asynchronous Apex when the UI must process many rows.

public with sharing class SfdcIdConverter {
    public class ConversionResult {
        @AuraEnabled public String inputId { get; set; }
        @AuraEnabled public String id18 { get; set; }
        @AuraEnabled public String id15 { get; set; }
        @AuraEnabled public String keyPrefix { get; set; }
        @AuraEnabled public Boolean success { get; set; }
        @AuraEnabled public String errorMessage { get; set; }
    }

    @AuraEnabled(cacheable=true)
    public static List<ConversionResult> convertTo18(List<String> inputIds) {
        List<ConversionResult> results = new List<ConversionResult>();

        if (inputIds == null) {
            return results;
        }

        for (String rawValue : inputIds) {
            ConversionResult row = new ConversionResult();
            row.inputId = rawValue;
            row.success = false;

            String candidate = rawValue == null ? null : rawValue.trim();

            if (String.isBlank(candidate) ||
                (candidate.length() != 15 && candidate.length() != 18)) {
                row.errorMessage = 'Id must contain 15 or 18 characters.';
                results.add(row);
                continue;
            }

            try {
                Id normalizedId = Id.valueOf(candidate);
                row.id18 = String.valueOf(normalizedId);
                row.id15 = normalizedId.to15();
                row.keyPrefix = row.id18.substring(0, 3);
                row.success = true;
            } catch (Exception ex) {
                row.errorMessage = ex.getMessage();
            }

            results.add(row);
        }

        return results;
    }
}

Test the utility with a real test record instead of a hard-coded sample ID. That keeps the test portable across orgs and avoids relying on ID prefixes that may vary by object availability.

@IsTest
private class SfdcIdConverterTest {
    @IsTest
    static void convertsValidAccountIdAndRejectsBadInput() {
        Account acct = new Account(Name = 'ID Converter Test');
        insert acct;

        String shortId = acct.Id.to15();

        Test.startTest();
        List<SfdcIdConverter.ConversionResult> rows =
            SfdcIdConverter.convertTo18(new List<String>{
                shortId,
                String.valueOf(acct.Id),
                'not-a-salesforce-id'
            });
        Test.stopTest();

        System.assertEquals(true, rows[0].success);
        System.assertEquals(String.valueOf(acct.Id), rows[0].id18);
        System.assertEquals(shortId, rows[0].id15);

        System.assertEquals(true, rows[1].success);
        System.assertEquals(false, rows[2].success);
    }
}

Production teams should still apply normal Apex standards: keep tests deterministic, avoid unnecessary queries, and meet Salesforce’s 75% minimum Apex test coverage requirement before deployment. For Lightning Web Component usage, also check CRUD and field-level security before returning record data. This converter returns only ID strings, but real tools often add object labels, names, or owner fields. For related LWC patterns in a salesforce 15 to 18 admin tool, see Lightning Web Components in Salesforce.

Review the official Apex references at Apex Id class and Apex primitive data types.

How to choose an sfdc id converter

An sfdc id converter should match the risk level of the data. For non-sensitive samples, a browser or spreadsheet helper may be enough. For production customer data, keep the conversion inside Salesforce, inside your approved integration runtime, or inside a vetted desktop process.

Salesforce documents LongSFID() for Marketing Cloud Engagement AMPscript. It returns an 18-character Salesforce ID when given a 15-character value. See the official AMPscript reference at LongSFID documentation.

What does an sf id prefix tell you?

An sf id starts with a key prefix that identifies the object type in the current org context. For example, standard objects and custom objects have prefixes that help Salesforce route the ID to the right object metadata. Do not build business logic that assumes a prefix list copied from another org is always complete. Managed packages, custom objects, and metadata differences can change what your org recognizes.

In Apex, once an input is converted to the Id type, you can inspect the sObject type instead of relying only on string prefixes:

Id recordId = Id.valueOf('001000000000000AAA');
Schema.SObjectType objectType = recordId.getSObjectType();
System.debug(objectType);

Use this pattern when an internal sf id tool must route IDs to different object handlers. Still validate access before reading or updating records. ID conversion is not a permission check.

Best practices for salesforce 15 to 18 during imports

For import jobs, make salesforce 15 to 18 conversion a pre-load checklist item, not a cleanup step after errors appear. The safest process is simple:

A salesforce 15 to 18 rule also helps reviewers. When every import file uses 18-character IDs, a reviewer can check one standard instead of asking whether a short ID came from the UI, a report, or a copied URL.

1. Export or generate 18-character IDs at the source using CASESAFEID(Id) or API output.
2. Trim whitespace in the CSV column before saving the file.
3. Keep the ID column as text. Do not let spreadsheet software auto-format it.
4. Compare source row count, converted row count, and unique ID count.
5. Run a small update batch first, then review success and error files.
6. Store the original file and converted file with the deployment or data-load ticket.

If a salesforce 15 to 18 process only receives 15-character values, convert them before lookup matching. If a process receives a mix of both formats, normalize everything to 18 characters before comparison. This avoids duplicate map keys in code and avoids case-loss issues in tools outside Salesforce.

Common errors with salesforce 15 to 18

Frequently Asked Questions