Field
A field in Salesforce is a single column on an object, holding one piece of data per record.
Definition
A field in Salesforce is a single column on an object, holding one piece of data per record. Account.Name, Contact.Email, and Opportunity.Amount are all fields. Every field has a data type (Text, Number, Date, Picklist, Lookup, Formula, and so on) that controls the values it accepts and how it behaves in queries, formulas, page layouts, and the API. Each field also carries an API name used in code and a label shown to users, along with metadata for length, help text, default value, and the required flag.
Fields are the smallest unit of customization on the platform. Salesforce ships standard fields for every standard object, such as Industry on Account or StageName on Opportunity. Admins add custom fields to capture org-specific data, and those fields carry the __c suffix on the API name. The platform supports roughly two dozen field types, and the type you pick decides what the field can do. A Picklist renders a dropdown, a Lookup creates a reference to another record, and a Formula is computed when the record is read.
How fields work, from data type to access control
The full set of field types
Salesforce supports around two dozen custom field types, grouped by what they store. Text and Long Text Area hold free-form strings, up to 255 characters for Text and 131,072 for Long Text Area. Number, Currency, and Percent store numeric values with different display formatting. Date, Date/Time, and Time cover time-related values. Picklist and Multi-Select Picklist offer enumerated lists, and Checkbox stores a boolean. Email, Phone, and URL are formatted text variants with light validation. Geolocation stores latitude and longitude as a compound value. Lookup Relationship and Master-Detail Relationship link a record to another record, while External Lookup Relationship points at an external data source. Formula fields compute a value at read time, and Roll-Up Summary fields aggregate child records under a master-detail parent. Auto Number assigns a sequential identifier, and Hierarchical Relationship is a self-referencing field available only on the User object. The type you choose is not just cosmetic. It decides which features the field unlocks, how it sorts and filters in SOQL, and which functions you can use against it in a formula.
Standard fields versus custom fields
Standard fields ship with every standard object and are owned by Salesforce. Account alone carries dozens of them, including Name, Industry, AccountNumber, and BillingAddress. You can usually relabel a standard field and adjust its security, but you cannot delete it. Custom fields are anything you add to track data Salesforce did not anticipate, and they belong to your org. The API name makes ownership obvious. A custom field carries the __c suffix, as in Account.Region__c, while a managed-package field also carries a namespace prefix, as in acme__Region__c. That distinction matters at deployment time, because custom fields move between orgs as metadata through change sets, packages, or the Metadata API. The label is what users read on a page or report, and the API name is what code, formulas, and integrations reference. Renaming a label is free and reversible. The API name, by contrast, is set when the field is created and stays fixed for the life of the field, so it pays to name fields deliberately the first time.
Field-Level Security and access
Field-Level Security, or FLS, controls who can see and edit each field. For a given field you can mark it Visible so a user can read and edit it, Visible and Read-Only so the user can read but not change it, or leave both unset so the field is hidden entirely. FLS sits on top of object-level access. A user needs Read on the object and Visible on the field before the value appears anywhere, including reports, list views, search results, and the API. FLS also overrides the page layout. If a field is hidden by FLS, it will not show even when the layout includes it. Salesforce now recommends setting field permissions on permission sets rather than directly on profiles, which keeps access modular and easier to audit as your user base grows. This is the platform's primary mechanism for column-level access control. Combined with object permissions and record-level sharing, it determines exactly which slice of the data each user can reach.
Field attributes that change behavior
Beyond the data type, several attributes shape how a field behaves. Required means the field cannot be blank when a record is saved through the UI or the API. Unique means no two records can hold the same value, which is useful for external keys and natural identifiers. External ID marks the field as a key you can match on during upsert operations, so an integration can update existing records without storing the Salesforce ID. Marking a custom field as an External ID is also the supported way to add a custom index, which speeds up queries that filter on that field. These attributes are independent, so you combine them as the use case demands. A common pattern for integration keys is a Text field that is both Unique and an External ID. Note that an External ID that is not also Unique can throw a duplicate error during upsert when more than one record matches the supplied value, so pair the two whenever the key is meant to be one-to-one.
Formula and Roll-Up Summary fields
Two field types compute their values instead of storing them. A Formula field derives a value at read time from other fields, dates, or constants, using a function library similar to a spreadsheet. Formula fields are read-only and hold no data of their own, so the platform recalculates them every time the record is read. They are handy for status flags, concatenated display text, and simple math that should always stay current. A Roll-Up Summary field aggregates child records across a master-detail relationship, supporting COUNT, SUM, MIN, and MAX. For example, an Opportunity can roll up the total Amount of its line items, or an Account can count its related cases. Roll-Up Summary fields require a master-detail relationship, not a plain lookup, because the platform needs the tight parent-child link to keep the total accurate. Both field types work in reports, list views, and dashboards without extra setup, and both are evaluated on the server, so the values stay consistent no matter how the record is accessed.
Field limits per object
Every object has a cap on custom fields, and the number depends on your Salesforce edition. Enterprise Edition allows up to 500 custom fields per object, and Unlimited and Performance editions allow up to 800. Lower editions allow fewer. Above the edition allowance, certified managed packages from the AppExchange can add their own fields without counting against your limit, so an Enterprise org can install another 400 packaged fields on top of its 500. There is also a hard ceiling that no edition or package can exceed, set at 800 fields for most objects and 900 for a few. When you reach the cap, the platform blocks new field creation until you delete fields you no longer use. Roll-Up Summary fields carry their own smaller per-object limit on top of the general count. Because field count is one signal of org complexity, and because every field adds to page layouts and query plans, it is worth treating object capacity as a budget rather than something you only think about once you run out of room.
How to create a custom field
Custom fields are created in Object Manager, one object at a time. The flow is the same for almost every type: pick the data type, name the field, then set visibility and which layouts show it. Here is the standard path in Lightning Experience.
- Open the object in Object Manager
From Setup, go to Object Manager and click the object you want, for example Account. In the left sidebar, click Fields and Relationships, then click New.
- Choose the data type
Select the field type that matches the data, such as Text, Number, Picklist, or Lookup Relationship. The type is hard to change later, so confirm it fits how the field will be queried and displayed.
- Enter the details
Provide a field label, which auto-populates the API name. Set length or precision, default value, help text, and flags such as Required, Unique, or External ID where they apply.
- Set field-level security
Choose which permission sets or profiles can see and edit the field. Tighten this now rather than accepting the default, especially for sensitive data.
- Add to page layouts and save
Select the page layouts that should display the field, then click Save. The field is live immediately and available in reports, SOQL, and the API.
The field type, such as Text or Picklist. It governs accepted values and behavior and is set before anything else.
The human-readable name shown on layouts and reports. Salesforce derives the API name from it on first save.
The permanent identifier used in code and integrations, auto-suffixed with __c for custom fields.
- The API name is permanent once saved. Relabeling is free, but the underlying API name never changes, so name it carefully the first time.
- A field hidden by Field-Level Security will not appear even if it sits on the page layout. Check FLS before assuming a layout issue.
- Changing a field's data type after it holds data can truncate or lose values. Review the conversion considerations before converting a populated field.
- Roll-Up Summary fields need a master-detail relationship. You cannot roll up across a plain lookup.
Prefer this walkthrough as its own page? How to Field in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Custom Field TypesSalesforce
- Custom Fields Allowed Per ObjectSalesforce
Straight from the source - Salesforce's reference material on Field.
- Field PermissionsSalesforce
- Field Types (Object Reference)Salesforce
Hands-on resources to go deeper on Field.
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. Which Salesforce field type is computed at read time and stores no value of its own on the record?
Q2. Which field property, when enabled, causes the platform to build a database index that speeds queries filtering on that field?
Q3. What does reaching an object's per-edition custom-field cap prevent an admin from doing?
Discussion
Loading discussion…