Lead Source in Salesforce | Reporting & Setup Guide

Lead source is the Salesforce field that records where a prospect or opportunity originated, such as Web, Partner Referral, Trade Show, or a paid campaign. In Salesforce, it is a standard picklist backed by the LeadSource standard value set, so admins must manage it as both a data-entry field and an attribution field.

For teams that use Leads, the field matters because its value can travel through conversion into related sales records. For teams that skip Leads and create Contacts or Opportunities directly, the same concept still matters because reporting depends on consistent source values.

What is lead source in Salesforce?

A lead source value answers one question: which first known channel created this record? Salesforce Help describes Lead Source as the source of the lead, selected from configured picklist values. The API name on the Lead object is LeadSource.

Do not treat this field as a full marketing attribution model. A single picklist value cannot explain every email click, webinar visit, sales call, or partner touch that influenced a deal. Use it for the first known source or the source rule your business defines, then use Campaigns and Campaign Influence for multi-touch analysis.

Canonical name lead source definition

The canonical name lead source definition for Salesforce implementation work is: a controlled picklist value that identifies the agreed source category for a Lead, Contact, Account, Campaign Member, or Opportunity record. The word “canonical” matters because every system that sends data to Salesforce should use the same source names. For example, do not let one form send “Google Ads,” another send “google_paid,” and a CSV import send “PPC” if the reporting category should be “Paid Search.”

Salesforce source field behavior

The salesforce lead source field is not a custom field that you need to create. It is available as a standard field. Salesforce represents standard picklists such as LeadSource through standard value sets in Metadata API v38.0 and later, and the same value set name is used across objects including Lead, Contact, Campaign Member, Opportunity, and Account Source.

In Setup, admins can add, deactivate, reorder, and restrict values. In enterprise orgs, the important decision is not whether the field exists; it is who owns the taxonomy and which systems can write to it.

Salesforce source setup checklist

1. Open Setup, then open Object Manager.
2. Select Lead, then open Fields & Relationships.
3. Open the standard source field and review the active picklist values.
4. Keep broad reporting categories in the source field, such as Web, Partner, Referral, Event, Paid Search, Organic Search, and Other.
5. Create a separate custom field such as Source_Detail__c only when the business needs the campaign, vendor, partner name, or form source.
6. Use field dependencies when the detail field must show different choices for each source category.
7. Set field-level security so only trusted roles or integration users can edit source after the first capture.

For related setup work, see Salesforce Leads setup and conversion, Salesforce reports for pipeline analysis, and Data Loader import steps for Salesforce admins.

How does lead source Salesforce conversion work?

The phrase lead source Salesforce usually appears when admins are troubleshooting lead conversion. Salesforce documentation states that when a lead is converted, information from standard lead fields appears in standard fields for the account, contact, and opportunity records created during conversion. Custom lead fields use the lead field mapping setup instead.

That means the source taxonomy should be designed before lead conversion is rolled out. If conversion happens first and the taxonomy changes later, older Contacts and Opportunities can hold values that no longer match your reporting model.

Lead source salesforce conversion scenarios

For production orgs, document the conversion rule in one place. Include how Person Accounts, duplicate matching, validation rules, flows, and integrations affect the final value.

How to populate lead source correctly

A good source process starts before a record reaches Salesforce. The field should be populated by the channel that creates the record, not guessed by a sales user after the fact.

Manual entry by sales or operations

Manual entry works when the volume is low or when reps create outbound records. Make the field required only after you know every record creation path can supply a correct value. Required fields can break imports, API integrations, and lead conversion if you enforce them without exceptions.

CSV import and Data Loader

For imports, add a column that maps to LeadSource. Clean the file before load. If your org uses restricted picklists, values in the file must match active Salesforce picklist values exactly. For large imports, load a test batch first and review rejected rows before running the full job.

Web-to-Lead hidden field

Web-to-Lead can create leads from website forms. Salesforce Help notes that Web-to-Lead supports hidden parameters, and Salesforce documents a daily Web-to-Lead capture limit. For a simple website form, the source field can be submitted as a hidden value.

<!-- Example only: generated Web-to-Lead forms include your org id and required fields. -->
<input type="hidden" name="lead_source" value="Web" />
<input type="hidden" name="00NXXXXXXXXXXXX" value="pricing-page" />

The custom hidden field in the second line represents a possible source-detail field. Use the field id generated by Salesforce for your org, not the placeholder shown here.

Account Engagement and UTM capture

In Account Engagement, source tracking can use referral and UTM information. Salesforce Help states that Account Engagement looks for the utm_source parameter when tracking source through UTM data. Keep the Account Engagement source field and the Salesforce picklist model aligned before syncing data between systems.

A practical pattern is to store broad categories in LeadSource and store UTM values in custom fields such as UTM_Source__c, UTM_Medium__c, and UTM_Campaign__c. This avoids forcing every campaign parameter into a picklist that sales users must scroll through.

For related marketing automation topics, review Salesforce Pardot and Account Engagement basics and Salesforce Campaigns for marketing attribution.

API integrations and middleware

Integrations should send the canonical source value, not a vendor-specific label. If middleware receives “linkedin-cpc,” “LI paid,” and “LinkedIn Ads,” normalize those values before creating the Lead. Use an error queue for unknown source values instead of writing “Other” for every failure.

Lead source marketing attribution limits

Lead source marketing reports are useful when leaders want a first-pass view of which channels create pipeline. They become misleading when teams use the field as the only attribution source. A webinar attendee can first arrive through organic search, convert through a paid retargeting ad, talk to a partner, and then become an opportunity after a sales sequence. One picklist value cannot represent all of that activity.

Use Salesforce Campaigns to track initiatives and Campaign Members to connect Leads or Contacts to those initiatives. Use Campaign Influence when the business needs opportunity attribution across one or more campaigns. Keep the standard field as the entry-source field; use campaigns for touch history.

Lead source marketing taxonomy example

How to report on source performance

Start with simple report types before building automation. Use Lead reports for top-of-funnel volume, Contact reports for converted people, and Opportunity reports for revenue. If you need both the original Lead fields and converted information, test the standard converted lead report types available in your org.

SOQL examples for admins and developers

The following SOQL examples use aggregate queries. Salesforce SOQL supports GROUP BY for grouped summaries, which avoids querying every record just to count by source.

SELECT LeadSource, COUNT(Id)
FROM Lead
WHERE CreatedDate = THIS_FISCAL_QUARTER
GROUP BY LeadSource
ORDER BY COUNT(Id) DESC

SELECT LeadSource, COUNT(Id), SUM(Amount)
FROM Opportunity
WHERE IsWon = true
AND CloseDate = THIS_FISCAL_YEAR
GROUP BY LeadSource
ORDER BY SUM(Amount) DESC

For enterprise dashboards, add filters for business unit, record type, country, and lead creation channel. Do not compare source performance across teams if one team enforces the field and another leaves it blank.

Best practices for source data quality

Source data breaks when every team treats the field differently. Use the following controls before you build dashboards that executives will use.

Keep the picklist small

A small picklist makes reporting easier. Use 8 to 15 broad values where possible. Put campaign names, vendor names, ad platforms, and form names in separate fields or Campaign records.

Use a detail field only when it has an owner

A detail field such as Source_Detail__c helps when marketing operations maintains it. Without ownership, it becomes a second uncontrolled source field. Use dependent picklists when the detail choices depend on the parent source category.

Protect the field with field-level security

Salesforce field-level security controls whether users can view or edit a field, and it overrides page layout editability. Make the field editable for marketing operations, data operations, and integration users. Make it read-only for most sales profiles unless your business process requires sales correction.

Use “Unknown” only as a data-quality signal

An “Unknown” value is better than a blank value when the source truly cannot be determined. Do not use it to hide integration failures. Review unknown-source records weekly and fix upstream capture rules.

Document the source of truth

Write down whether the field is owned by Salesforce, Account Engagement, a website form, middleware, or a data warehouse. If two systems can update the same field, define which one wins and when overwrites are allowed.

Apex example for source validation

Use declarative validation or Flow when it is enough. Use Apex when you need shared logic across triggers, integrations, or managed packages. The example below is bulkified, performs no SOQL inside loops, and validates against active picklist values using schema describe metadata.

public with sharing class LeadSourceService {
    public static final String DEFAULT_SOURCE = 'Web';

    public static void applyDefaultSource(List<Lead> leadsToPrepare) {
        if (leadsToPrepare == null || leadsToPrepare.isEmpty()) {
            return;
        }

        Set<String> activeValues = new Set<String>();
        Schema.DescribeFieldResult sourceDescribe =
            Schema.SObjectType.Lead.fields.LeadSource.getDescribe();

        for (Schema.PicklistEntry entry : sourceDescribe.getPicklistValues()) {
            if (entry.isActive()) {
                activeValues.add(entry.getValue());
            }
        }

        for (Lead leadRecord : leadsToPrepare) {
            if (String.isBlank(leadRecord.LeadSource)) {
                if (activeValues.contains(DEFAULT_SOURCE)) {
                    leadRecord.LeadSource = DEFAULT_SOURCE;
                }
                continue;
            }

            if (!activeValues.contains(leadRecord.LeadSource)) {
                leadRecord.addError(
                    'Source is not an active picklist value: ' +
                    leadRecord.LeadSource
                );
            }
        }
    }
}

trigger LeadSourceTrigger on Lead (before insert, before update) {
    LeadSourceService.applyDefaultSource(Trigger.new);
}

Governor limit note: this pattern uses one describe call and loops through the trigger records once. It does not run DML inside the trigger helper because the records are already in a before-save context. If you expose lead creation through Apex for LWC, REST, or integrations, also enforce CRUD and field-level security with platform security features such as Security.stripInaccessible or user-mode data operations where appropriate.

Deployment note: Apex deployments still require passing tests and at least 75% org-level code coverage. Write tests for blank source, valid source, and invalid source paths, and avoid depending on a picklist value that may be inactive in another org.

Common source tracking errors

Official Salesforce references

• Salesforce Help: Lead Fields
• Salesforce Help: Map Custom Lead Fields for Lead Conversion
• Salesforce Developer Docs: StandardValueSet Names and Standard Picklist Fields
• Salesforce Help: Generate Leads from Your Website with Web-to-Lead
• Salesforce Developer Docs: SOQL GROUP BY

Frequently Asked Questions