Custom Field
A Custom Field in Salesforce is an admin-created field on any standard or custom object that captures data beyond what the standard object schema includes.
Definition
A Custom Field in Salesforce is an admin-created field on any standard or custom object that captures data beyond what the standard object schema includes. Custom Fields come in many types (Text, Number, Currency, Date, Picklist, Checkbox, Lookup, Master-Detail, Formula, Roll-Up Summary, Auto Number, and others), each with type-specific configuration. Custom Fields surface on page layouts, list views, reports, filters, validation rules, and integrations the same way standard fields do; the platform treats them identically once created.
Custom Fields are the most-built customization in any Salesforce org. A typical mature org holds dozens to hundreds of custom fields per heavily-used object (Account, Opportunity, Case, Contact). The fields capture industry-specific data (Account.AccountTier, Opportunity.RegionRevenue, Case.Tier_Number), integration keys (External_ID__c that maps to an ERP), calculated values (Formula fields), and process state. The discipline around custom field creation (naming, documentation, governance) is what separates orgs that stay maintainable from orgs that accumulate field debt.
Why custom field discipline is the difference between healthy and overgrown orgs
Where Custom Fields live and how they are created
Object Manager, pick the object, Fields and Relationships, New. The wizard asks for field type, label, length or precision, default value, help text, security settings (field-level security per profile), and field history tracking. The label becomes the user-facing display; the API name (auto-generated from the label with __c suffix for custom fields) is what code, formulas, and integrations reference. Once created, the field is available on page layouts, reports, formulas, validation rules, and integrations. Some changes (renaming a field) are easy; others (changing field type) are restricted or destructive.
Field types and the right-type-for-the-job decision
Text for free-form short strings (255 char limit). Text Area for longer text (255 char) and Text Area Long for up to 131,072 chars. Number for integers and decimals. Currency for monetary values (respects multi-currency). Date and Date/Time for temporal values. Picklist and Multi-Select Picklist for controlled values. Checkbox for boolean. Lookup for relationships to other objects (loose coupling). Master-Detail for tight parent-child relationships (cascading delete, roll-up summaries). Formula for derived values computed at read time. Roll-Up Summary for aggregated values from child records. Auto Number for sequential reference identifiers. Pick the type that matches the data semantics; type changes after creation are limited.
Field-level security and the per-profile access
Every Custom Field has field-level security (FLS) settings per profile and permission set: Read access (can see the field) and Edit access (can change it). FLS applies in the UI, in reports, in formulas referencing the field, in API responses. A user without Read FLS does not see the field anywhere. The default new-field FLS is Read on every profile; admins should review and tighten as part of the field-creation discipline. Most field-related access issues trace to FLS misconfiguration rather than to record-level sharing.
Naming conventions and the long-term cost
The label and API name are how users and integrations reference the field. Convention-based naming pays back over years: prefix custom fields with team or domain (FIN_Revenue_c, OPS_Region_c) to group related fields, use consistent casing (Title Case for labels, snake_case for API names), avoid abbreviations that ambiguate (Cust_Code__c could mean Customer Code or Custom Code). Most large orgs adopt a naming convention in the first quarter and pay for the lack of one for years afterward.
Help text, validation, and the data quality layer
Custom Field help text appears as a tooltip on the field in the UI. Users hover and see the explanation. The help text is the cheapest data quality investment available; users with clear help text fill the field correctly far more often than users guessing from the label alone. Validation Rules layer on top, enforcing format and value constraints. Field-level Required marking enforces that the field is populated on save. Together, help text + required + validation produces fields that hold reliable data; without them, custom fields accumulate junk.
Field history tracking and the audit question
Field History Tracking captures every change to a tracked field with old value, new value, who changed it, when. Up to 20 fields per object can be tracked. The history persists in the FieldHistory related list and in the (objectname)History object queryable via SOQL. Tracking is the audit trail for compliance-relevant fields (Owner, Amount, Stage on Opportunity); enabling it adds storage cost and surface area but produces evidence regulators and operations teams need. Pick the fields to track deliberately; tracking everything is wasteful.
Custom Field governance and the cleanup discipline
Custom Fields accumulate. Mature orgs hold hundreds of fields per object; many are unused. The cleanup discipline: Salesforce Optimizer report identifies unused fields (no data, no references). Quarterly audit reviews the report and retires fields that no longer matter. Retirement is two-step: hide from page layouts and reports (users stop seeing it), then delete after a safety window (the field and its data are gone). The discipline prevents the org from becoming a museum of past customization decisions.
How to create a Custom Field that earns its keep
The successful pattern: pick the right type for the semantic, name per convention, write clear help text, set FLS deliberately, add validation where appropriate, document the field's purpose. The failed pattern: build the field, drop it on a layout, never revisit, accumulate confusion.
- Confirm the data semantic and pick the matching type
Date for dates, Picklist for controlled values, Lookup for relationships. The type drives every other design choice; changing later is restricted.
- Name per the org's convention
Team or domain prefix, consistent casing, no ambiguous abbreviations. If the org has no convention, propose one before building the first custom field.
- Write help text explaining what to enter
One sentence on what the field captures. Users with clear help text fill fields correctly; users guessing from the label do not.
- Set field-level security per profile and permission set
Default Read for everyone is rarely right. Tighten before saving; default broad FLS is a common compliance gap.
- Add Validation Rules where format or value matters
Email format, numeric range, picklist dependency. The validation rule is the data quality enforcement; help text is the guidance.
- Enable Field History Tracking for compliance-relevant fields
Up to 20 per object. Track Owner, Stage, Amount on Opportunity; track sensitive fields on Account. Skip tracking for fields with no audit need.
- Add to page layouts, list views, and reports as appropriate
The field exists but is invisible until surfaced. Add to the layouts that need it; resist the urge to add it everywhere.
- Document the field's purpose and owner
Spreadsheet, ticketing system, or wiki. The documentation is what saves future admins from reverse-engineering intent.
Text, Number, Picklist, Lookup, Master-Detail, Formula, Roll-Up Summary, Auto Number, and others. Drives everything.
Per the org's naming convention. The API name is hard to change cleanly later.
Per-profile Read and Edit access. Default Read for everyone; tighten before saving.
Tooltip explanation. Cheapest data quality investment available.
Per-field audit trail. Up to 20 per object.
- Field type changes after creation are limited. Text to Picklist is allowed but most others require delete-and-recreate.
- Default field-level security is Read for every profile. Tighten before saving; default broad access is a common compliance gap.
- Master-Detail relationships cascade delete and cannot be undone easily. Pick Master-Detail only when the tight coupling is genuinely required.
- Field History Tracking has a 20-fields-per-object cap. Plan which fields matter most for audit before hitting the cap.
- Custom Fields accumulate. Without quarterly cleanup, mature orgs end up with hundreds of unused fields per object.
Trust & references
Cross-checked against the following references.
- Custom Field referenceSalesforce
- Field creation referenceSalesforce
Straight from the source - Salesforce's reference material on Custom Field.
- Add Custom FieldsSalesforce Help
- Custom Field TypesSalesforce Help
- Field-Level SecuritySalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Can a Salesforce admin configure Custom Field without writing code?
Q2. In which area of Salesforce would you typically find Custom Field?
Q3. What is the primary benefit of Custom Field for Salesforce administrators?
Discussion
Loading discussion…