Objects and Fields in Salesforce

If Salesforce is a building, objects and fields are the bricks and mortar. Every screen your users see, every report they run, every automation that fires — it all sits on top of the data model. Understanding objects and fields deeply isn’t just helpful, it’s non-negotiable for anyone administering or building on Salesforce.

This section is dense. Take your time with it.

What Are Objects?

An object in Salesforce is essentially a database table. Each object stores a specific type of data and is made up of fields (columns) and records (rows).

When you open the “Accounts” tab and see a list of companies, you’re looking at records in the Account object. When you click into one and see fields like “Account Name,” “Industry,” and “Phone,” you’re looking at columns in that table.

Salesforce comes with many objects out of the box, and you can create your own.

Standard Objects

Standard objects are the pre-built objects that come with Salesforce. They represent common business entities and are the backbone of the CRM:

Standard objects come with predefined fields, page layouts, relationships, and behaviors. You can customize them (add fields, modify layouts, create automations) but you can’t delete them or change certain core behaviors.

Custom Objects

Custom objects are objects you create to store data specific to your business that doesn’t fit into standard objects. For example:

• A Project object to track internal projects
• An Invoice object to manage billing
• A Property object for a real estate company
• A Bug object for a software team

Custom objects have an __c suffix in their API name (e.g., Project__c, Invoice__c). This suffix distinguishes them from standard objects in code, formulas, and integrations.

Key Differences Between Standard and Custom Objects

How to Create Custom Objects

Step-by-Step

1. Navigate to Setup → Object Manager (top nav in Setup)
2. Click “Create” → “Custom Object”
3. Fill in the required fields:

Label and Name:

• Label — The human-readable name (e.g., “Project”)
• Plural Label — The plural form (e.g., “Projects”)
• Object Name — The API name, auto-generated from the label. Salesforce appends __c automatically.

Record Name:

• This is the “Name” field for the object — the primary identifier displayed in list views, lookups, and search results
• Data Type options:
  • Text — A free-text name (e.g., “Website Redesign Q2”)
  • Auto Number — Auto-incrementing ID (e.g., “PRJ-00001”, “PRJ-00002”). Set the format with {0} as the placeholder for the number.

Optional Settings:

• Allow Reports — Enable reporting on this object. Almost always: Yes.
• Allow Activities — Allow Tasks and Events to be related to records of this object. Recommended: Yes for most objects.
• Track Field History — Enable field history tracking (more on this below). Recommended: Yes for important objects.
• Allow in Chatter Groups — Allow Chatter feed tracking on this object
• Allow Search — Make records of this object searchable via Global Search. Recommended: Yes.
• Allow Sharing — Enable sharing rules for this object. Recommended: Yes.
• Allow Bulk API Access — Required for Data Loader and bulk integrations. Recommended: Yes.
• Allow Streaming API Access — Required for real-time event notifications. Recommended: Yes for integration-heavy objects.

4. Click “Save”

Your custom object is created. It will have a few default fields: Name (that you just configured), Created By, Last Modified By, Owner, and a system ID.

After Creation: Next Steps

• Add custom fields (covered below)
• Create page layouts to control how the record appears
• Add the object’s tab to an app so users can find it
• Configure profiles/permission sets to grant access
• Build validation rules and automations as needed

What Are Fields?

Fields are the individual data points on an object — the columns in your database table. Every piece of information stored in Salesforce lives in a field.

When you look at a Contact record and see “First Name: Abhishek,” “Email: abhishek@example.com,” “Phone: +91-9876543210” — each of those is a field.

Standard Fields

Every object comes with pre-built standard fields. Some are common across all objects:

Object-specific standard fields include things like:

• Account: Industry, BillingAddress, Website, AnnualRevenue
• Contact: FirstName, LastName, Email, Phone, MailingAddress
• Opportunity: Amount, CloseDate, StageName, Probability

Standard fields can be customized to an extent (you can change labels, help text, and some properties) but you can’t delete them or change their data type.

Custom Fields

Custom fields are fields you create on any object (standard or custom). Like custom objects, they have an __c suffix in their API name.

Examples:

• Project_Status__c (Picklist) on the Project object
• NPS_Score__c (Number) on the Account object
• Preferred_Contact_Method__c (Picklist) on the Contact object

Key Differences

Big Objects and Their Limitations

Big Objects are a special object type designed for storing massive volumes of data — billions of records — without consuming standard data storage.

When to Use Big Objects

• Historical data archival (e.g., 5 years of transaction history)
• Audit logs and compliance records
• IoT data streams
• Any dataset too large for standard objects (where you’d hit storage limits)

How They Work

• Big Objects store data in Salesforce’s back-end storage infrastructure, separate from the standard database
• They don’t count against your org’s data storage limits
• Records are accessible via Apex, SOQL (with restrictions), and API

Limitations (Important)

Big Objects have significant limitations that make them unsuitable for everyday use:

Bottom line: Big Objects are a storage solution, not a replacement for standard/custom objects. Use them for archival and high-volume data that doesn’t need real-time user interaction.

How to Create Fields

Step-by-Step

1. Setup → Object Manager → Select your object

2. Click “Fields & Relationships” in the left sidebar

3. Click “New”

4. Select the field type (see next section for all types)

5. Click “Next”

6. Configure field details:

   • Field Label — Human-readable name (e.g., “Project Status”)
   • Field Name — API name (auto-generated, e.g., Project_Status__c)
   • Help Text — Tooltip that appears when users hover over the field label. Use this!
   • Required — Whether the field must have a value to save the record
   • Unique — Whether values must be unique across all records (useful for external IDs)
   • Default Value — Pre-populated value for new records
   • Description — Internal documentation (not visible to users)

7. Click “Next” to set Field-Level Security — which profiles can see and/or edit this field

8. Click “Next” to choose which Page Layouts should include this field

9. Click “Save”

What Are the Different Field Types?

Salesforce offers a wide variety of field types. Choosing the right one is critical — changing a field’s type after data exists is limited and sometimes impossible.

Text Fields

Number Fields

Date and Time

Selection Fields

Relationship Fields

Other Fields

Choosing the Right Field Type — Decision Framework

1. Is it a yes/no? → Checkbox
2. Is it a fixed set of options? → Picklist (single) or Picklist (multi-select)
3. Is it a number? → Number, Currency, or Percent depending on context
4. Is it a date? → Date (if no time needed) or Date/Time (if time-zone matters)
5. Is it text? → Text (short), Text Area (multi-line), Long Text Area (very long), Rich Text (formatted)
6. Is it calculated from other fields? → Formula
7. Does it aggregate child records? → Roll-Up Summary (requires master-detail)
8. Does it link to another record? → Lookup or Master-Detail

What Are Global Value Sets?

A Global Value Set is a reusable list of picklist values that can be shared across multiple picklist fields on different objects.

The Problem They Solve

Imagine you have a “Region” picklist field on Account, Contact, and Opportunity. Without global value sets, you’d maintain three separate copies of the same values. Add a new region? You’d have to update three fields. Forget one? Inconsistent data.

How to Set Up a Global Value Set

1. Setup → Picklist Value Sets (Quick Find: “Picklist Value Sets”)
2. Click “New”
3. Enter:
   • Label — e.g., “Regions”
   • API Name — auto-generated (e.g., Regions)
   • Values — Enter each value on a new line:

     North India
     South India
     East India
     West India
     International

   • Sort alphabetically — Check if you want values auto-sorted
4. Click “Save”

Using a Global Value Set with a Picklist Field

When creating a new Picklist field:

1. At the field type selection step, choose “Picklist”
2. On the next screen, select “Use global picklist value set”
3. Choose your global value set (e.g., “Regions”)
4. Complete the field creation wizard

Now this field uses the shared values. Any change to the global value set automatically updates every field that references it.

When to Use Global Value Sets

• When the same set of values appears on 3+ fields across different objects
• When data consistency across objects is important (e.g., Status, Region, Priority)
• When a centralized team manages the value list

When NOT to Use Them

• When each object needs slightly different values
• When individual field flexibility is more important than consistency
• When you have only 1-2 fields using the same values (the overhead isn’t worth it)

State and Country Picklists

By default, Salesforce stores State and Country as free-text fields on Address fields. This means users can type “Maharashtra,” “MH,” “Maha,” or “maharashtra” — leading to inconsistent data and broken reports.

State and Country Picklists replace these free-text fields with standardized picklist values based on ISO codes.

How to Enable

1. Setup → State and Country/Territory Picklists (Quick Find: “State and Country”)
2. Click “Enable” (this starts a multi-step process)
3. Configure countries — Select which countries are active in your org. You don’t need all 200+ countries — just the ones relevant to your business.
4. Configure states — For each active country, select which states/provinces/territories are active
5. Scan your existing data — Salesforce will scan your records and try to match existing text values to the standardized picklist values. Review the mapping.
6. Convert data — Apply the conversion to existing records

Warning: This is a one-way process. Once enabled, you can’t revert to free-text state/country fields. Test thoroughly in a sandbox first.

Benefits

• Clean, consistent address data
• Reliable reporting by state/country
• Integration-friendly (ISO codes)
• Better data quality for analytics and deduplication

Custom Address Field Activation

Starting with recent Salesforce releases, you can now create custom address fields (compound fields) on custom objects — similar to the standard address fields on Account and Contact.

How to Enable

1. Setup → Address Settings (Quick Find: “Address Settings”)
2. Toggle “Enable custom address fields on custom objects” to ON

How to Create a Custom Address Field

1. Object Manager → Select your custom object → Fields & Relationships → New
2. Select “Address” as the field type
3. Complete the wizard

This creates a compound field with sub-fields for Street, City, State, Zip/Postal Code, and Country. If you’ve enabled State and Country Picklists, the address field automatically uses the picklist values.

Use case: A custom “Warehouse” object that needs an address, or a “Site Visit” object with a location.

How to Edit Your Fields After You Create Them

Fields aren’t set in stone after creation, but there are limitations.

What You Can Always Change

• Field Label — Rename the field freely
• Help Text — Update tooltip text
• Description — Update internal documentation
• Required — Toggle required on/off
• Default Value — Change or remove defaults
• Field-Level Security — Change who can see/edit the field
• Page Layout placement — Add or remove from layouts

What You Can Change with Restrictions

Field Type Conversion: Not all type changes are allowed, especially when data already exists. Here’s the general compatibility:

You CANNOT convert:

• Any field type to/from Auto Number
• Lookup to Master-Detail (directly — requires workaround)
• Formula to any editable type (must delete and recreate)
• Rich Text to any other type
• Any type to/from Roll-Up Summary

Data loss warning: Some conversions will truncate or lose data. For example, converting a Long Text Area (131K chars) to Text (255 chars) will truncate any values longer than 255 characters. Salesforce warns you but always test in a sandbox first.

How to Edit Standard Fields

Standard fields are more limited:

• You can change the label, help text, and field-level security on most standard fields
• You cannot change the data type or delete standard fields
• Some standard fields have additional restrictions (e.g., the Account Name field can’t be made non-required)

How to Edit the Names Field

Every object has a Name field — the primary identifier for records. For custom objects:

• If the Name field is Text type, you can change it to Auto Number (and vice versa)
• Navigate to Object Manager → Your Object → Fields & Relationships → Click “Name” → Edit
• Warning: Changing from Text to Auto Number will overwrite existing name values with auto-numbers. This is destructive.

How to Change the Names of Standard Objects

You can rename standard objects to match your business terminology. For example, “Accounts” → “Clients” or “Opportunities” → “Deals.”

1. Setup → Rename Tabs and Labels (Quick Find: “Rename Tabs”)
2. Select the language
3. Click “Edit” next to the object you want to rename
4. Enter the new Singular and Plural labels
5. Optionally check “Starts with a vowel sound” for proper grammar (a vs. an)
6. Click “Save”

What this changes:

• The tab name
• All standard UI references to the object
• Help text and default descriptions

What this does NOT change:

• The API name (still Account, Opportunity, etc.)
• Apex code references
• Formula field references
• Integration code

This is cosmetic only — it affects the UI label, not the underlying object.

What Are Object Relationships?

Relationships are the connections between objects. They define how records from different objects relate to each other, enabling you to build a connected data model.

For example:

• An Account has many Contacts (one-to-many)
• An Opportunity belongs to one Account (many-to-one)
• A Case is related to a Contact (lookup)

Types of Relationships

Lookup Relationship

A loose relationship between two objects. The child record has a lookup field pointing to the parent, but it can exist independently.

Characteristics:

• Child record can exist without a parent (the lookup field can be blank)
• Deleting the parent does NOT delete the children (the lookup field is just cleared)
• No Roll-Up Summary fields available (by default — you can use Flows or AppExchange tools)
• The child record’s sharing/ownership is independent of the parent
• Up to 40 lookup relationships per object

Example: Contact has a lookup to Account. But a Contact can exist without an Account (e.g., a personal contact).

Master-Detail Relationship

A tight parent-child relationship where the child’s existence depends on the parent.

Characteristics:

• Child record cannot exist without a parent (the field is always required)
• Deleting the parent cascades — all child records are deleted
• The child inherits the parent’s sharing settings (no independent Owner field on the child)
• Roll-Up Summary fields are available on the parent to aggregate child data
• Up to 2 master-detail relationships per object
• The first master-detail on a custom object removes the Owner field

Example: Opportunity Products (child) are in a master-detail with Opportunity (parent). You can’t have an Opportunity Product without an Opportunity.

How to Set Up Object Relationships

1. Object Manager → Select the child object
2. Fields & Relationships → New
3. Select “Lookup Relationship” or “Master-Detail Relationship”
4. Select the parent object (the object you’re relating to)
5. Configure the field label and name
6. Set field-level security and page layout placement
7. Optionally configure the related list (how child records appear on the parent’s page)
8. Save

Differences Between Master-Detail and Lookup

Unique Characteristics of Standard OOTB Master-Detail Objects

Some standard objects have pre-built master-detail relationships with behaviors you can’t replicate on custom objects:

• Opportunity → Opportunity Product — Deleting an Opportunity deletes all Opportunity Products. But Opportunity Products also have a relationship to Product, which is a lookup (not master-detail).
• Opportunity → OpportunityLineItem (Quote Line Items) — Quote syncing behavior is unique to this relationship.
• Campaign → Campaign Member — Campaign Members can’t exist without a Campaign, but Campaign Members also reference Lead or Contact (polymorphic relationship).
• Case → Case Comment — Case Comments are in a master-detail with Case, but they don’t have standard custom field support.
• Account → Account Contact Relationship — The junction object between Accounts and Contacts, enabling the many-to-many “Related Contacts” feature.

Key takeaway: Standard master-detail relationships often have custom behaviors (like polymorphic lookups or special sharing rules) that you cannot replicate with custom master-detail relationships. Be aware of these when designing your data model.

Viewing Objects via the Schema Builder

Schema Builder is a visual, drag-and-drop tool for viewing and editing your data model.

How to Access It

Setup → Schema Builder (Quick Find: “Schema Builder”)

What You Can Do

• View objects and their fields in a visual ERD-like diagram
• See relationships between objects as connecting lines
• Drag and drop to rearrange the visual layout
• Create new objects directly from the canvas
• Create new fields by dragging field types onto an object
• Filter to show only selected objects (essential — showing all objects at once is overwhelming)

When to Use Schema Builder

• Understanding an unfamiliar data model — Visual representation is faster than reading field lists
• Planning new objects and relationships — Sketch out the model visually before building
• Quick field creation — Faster than navigating Object Manager for simple fields
• Training and documentation — Screenshot the schema for documentation

Limitations

• Can’t create all field types (some advanced configurations require Object Manager)
• Performance degrades with too many objects on the canvas
• Can’t manage page layouts, record types, or validation rules from here
• The layout doesn’t save between sessions (you’ll rearrange every time)

Viewing Objects via the Dev Console

The Developer Console offers another way to explore objects, especially useful for viewing records and testing queries.

How to Access It

Gear icon (top-right) → Developer Console

Useful Object Exploration Tools

Query Editor:

• Write SOQL queries to explore data: SELECT Id, Name, Industry FROM Account LIMIT 10
• See field API names and data types in query results
• Test relationship queries: SELECT Name, Account.Name FROM Contact

View State Inspector:

• When debugging Visualforce pages, shows the objects and fields being accessed

Object reference via Tooling API:

• In the Query Editor, switch to “Use Tooling API” checkbox
• Query EntityDefinition to see all objects: SELECT QualifiedApiName, Label FROM EntityDefinition ORDER BY Label
• Query FieldDefinition for fields: SELECT QualifiedApiName, DataType FROM FieldDefinition WHERE EntityDefinition.QualifiedApiName = 'Account'

The Dev Console is more developer-oriented, but it’s invaluable when you need to quickly check API names, test queries, or debug data issues.

How to Set Up Field History Tracking on an Object

Field History Tracking records changes to specific fields on an object — what changed, from what value, to what value, who changed it, and when. This is essential for auditing and compliance.

How to Enable

1. Object Manager → Select your object
2. Click “Fields & Relationships”
3. Click “Set History Tracking” button (top of the page)
4. Check “Enable [Object] History” (if not already enabled)
5. Select up to 20 fields to track (this is a hard limit per object)
6. Click “Save”

What Gets Tracked

For each tracked field, Salesforce logs:

• Date and time of the change
• User who made the change
• Old value (before the change)
• New value (after the change)
• Field name that changed

Where to View History

• On the record’s page layout, add the “History” related list (e.g., “[Object] History”)
• Via reports using the “[Object] History” report type
• Via SOQL: SELECT Field, OldValue, NewValue, CreatedBy.Name, CreatedDate FROM AccountHistory

Limitations

Best Practices

1. Track the fields that matter — Don’t waste your 20 slots on trivial fields. Focus on fields that are:

   • Financially significant (Amount, Price, Discount)
   • Status-related (Stage, Status, Priority)
   • Ownership-related (Owner, Assigned To)
   • Security-sensitive (Email, Phone, Role)

2. Use Field Audit Trail for compliance — If your industry requires long-term audit records (finance, healthcare, government), invest in the Shield add-on.

3. Combine with Setup Audit Trail — Field History tracks data changes. Setup Audit Trail tracks configuration changes. Together, they give you a complete picture.

4. Create reports on history — Don’t just enable tracking — build reports that surface meaningful insights. For example: “Opportunities where Stage changed from Closed Won back to an open stage in the last 30 days.”

Section Notes

• Start with the data model. Before building anything in Salesforce — page layouts, automations, reports — design your objects and fields. A poor data model creates problems that compound with every feature you add.
• Use standard objects first. Don’t create a custom “Company” object when the Account object already exists. Standard objects come with built-in relationships, features, and ecosystem support that custom objects don’t.
• Name things clearly. Use descriptive labels and API names. Project_Status__c is better than Status__c (which status? On which object?). Your future self and your teammates will thank you.
• Choose relationship types carefully. The Lookup vs. Master-Detail decision affects sharing, deletion behavior, and Roll-Up Summary availability. This is difficult to change later.
• Respect the 20-field limit for history tracking. Plan your tracked fields intentionally. You can change which fields are tracked later, but you lose history for fields you remove.
• Big Objects are for archival. They’re not a replacement for standard/custom objects. Use them for high-volume, low-interaction data only.
• Global Value Sets save maintenance headaches. If the same values appear across multiple objects, centralize them.
• Test in a sandbox. Especially for State/Country Picklist enablement, field type conversions, and Auto Number changes. These can be destructive.

Project: Create Two Related Objects with Fields

The Scenario

You’re setting up Salesforce for a small consultancy. They need to track Projects and Deliverables (each project has multiple deliverables).

Your Tasks

1. Create the Project object:

   • Name field: Auto Number with format PRJ-{0000}
   • Custom fields:
     • Project_Name__c (Text, 100 chars, required)
     • Client__c (Lookup to Account)
     • Status__c (Picklist: Not Started, In Progress, On Hold, Completed, Cancelled — use a global value set called “Project Statuses”)
     • Start_Date__c (Date)
     • End_Date__c (Date)
     • Budget__c (Currency)
     • Project_Manager__c (Lookup to User)
   • Enable field history tracking on: Status, Budget, Start Date, End Date

2. Create the Deliverable object:

   • Name field: Auto Number with format DEL-{0000}
   • Custom fields:
     • Deliverable_Name__c (Text, 255 chars, required)
     • Project__c (Master-Detail to Project)
     • Due_Date__c (Date)
     • Status__c (Picklist using the same “Project Statuses” global value set)
     • Description__c (Long Text Area)
     • Completion_Percentage__c (Percent, 0 decimal places)

3. On the Project object, create a Roll-Up Summary field:

   • Total_Deliverables__c — COUNT of related Deliverables
   • Overdue_Deliverables__c — COUNT of Deliverables where Due_Date < TODAY and Status ≠ “Completed”

4. View your model in Schema Builder:

   • Verify the relationship line between Project and Deliverable
   • Screenshot it for your records

5. Create 3 test Projects and 5-8 Deliverables to verify everything works as expected

In the next section, we’ll take these objects and control how they appear to users through Page Layouts and Record Types.

This is Part 4 of the Salesforce series. Next up: Page Layouts and Record Types — controlling what users see, the fields they can edit, and how different user groups experience the same object differently.