A Salesforce object is essentially a database table that stores a specific type of data. If you’ve worked with spreadsheets, think of an object as one entire spreadsheet dedicated to a single category of information, like “Contacts” or “Leads.” Each row in that spreadsheet is a record, and each column is a field. Objects are the fundamental building blocks of how Salesforce organizes everything in your CRM.
How Objects Map to Database Concepts
Salesforce uses its own terminology, but the underlying structure follows familiar database logic. An object is a table. Each object contains fields, which are the equivalent of columns. Fields store specific types of information like text, numbers, dates, or picklist values (dropdown menus). A record is a single row, representing one individual entry within that object.
For example, the Contact object has fields like First Name, Last Name, Email, and Phone Number. Each person you add becomes a new record. If you have 500 people stored in the Contact object, you have 500 records, each with its own set of field values.
Standard Objects
Salesforce comes preloaded with a set of standard objects designed around common business processes. These are built into every Salesforce org and can’t be deleted, though you can customize them by adding or hiding fields. The most widely used standard objects include:
- Account: Represents an organization or person involved with your business, such as a customer, partner, or competitor.
- Contact: A person associated with an Account.
- Lead: A prospect who hasn’t yet been qualified or converted into an Account and Contact.
- Opportunity: A sale or pending deal you’re tracking through your pipeline.
- Case: A customer issue or support request.
- Campaign: A marketing effort like a webinar, trade show, or email promotion.
These objects work together out of the box. When you convert a Lead, Salesforce automatically creates an Account, a Contact, and optionally an Opportunity. Cases link to Accounts and Contacts so your support team can see the full customer history. This interconnected structure is what makes Salesforce more than just a collection of spreadsheets.
Custom Objects
When standard objects don’t cover what your business needs to track, you create custom objects. A custom object works exactly like a standard one, with records, fields, and relationships, but you define its purpose. A real estate company might create a custom object called “Property.” A university might build one called “Application.” A logistics firm might need one called “Shipment.”
Custom objects are identified by an “__c” suffix in Salesforce’s backend. So a custom object named “Property” would appear as “Property__c” in formulas, code, and API calls. Custom fields on any object follow the same convention.
Salesforce limits the number of custom objects you can create based on your edition. Enterprise Edition orgs, for instance, get a higher allowance than Professional Edition orgs. For most businesses, the limit is generous enough that you’re unlikely to hit it, but it’s worth checking your edition’s capacity if you’re planning a complex data model with dozens of custom objects.
How Objects Connect Through Relationships
Objects rarely exist in isolation. A Contact belongs to an Account. An Opportunity is tied to both. These connections are called relationships, and they determine how records across different objects link to each other. Salesforce offers two primary relationship types.
Lookup Relationships
A lookup relationship is a loose connection between two objects. It lets you link one record to another, but neither record depends on the other to exist. You can have a Contact record without linking it to an Account, for example. If you delete the parent record, the child record stays intact. An object can have up to 40 lookup fields.
Lookup relationships are flexible and work well when the connection between records is optional or informational. Security settings on the child record are independent of the parent.
Master-Detail Relationships
A master-detail relationship is a tighter bond. The child record cannot exist without a parent. If you delete the parent, all child records are deleted automatically (this is called cascade delete). The parent also controls the child record’s sharing and visibility settings, so you don’t need to manage permissions separately.
Master-detail relationships unlock a feature called roll-up summary fields, which let you calculate values across child records on the parent. For instance, an Account (parent) could display the total value of all its related Opportunities (children). An object can have a maximum of two master-detail relationships.
Many-to-Many Relationships
Sometimes two objects need a relationship where many records on each side connect to many records on the other. A student can enroll in multiple courses, and a course can have multiple students. Rather than duplicating lookup fields, Salesforce handles this through a junction object, which is a custom object that sits between the two and holds a master-detail relationship to each. The junction object stores each individual pairing as its own record.
Big Objects for Massive Data
Standard and custom objects use a traditional relational database and handle millions of records well. But some use cases involve data at a much larger scale, like transaction logs, clickstream data, or years of archived records. For those scenarios, Salesforce offers big objects.
Big objects run on a horizontally scalable distributed database and can store hundreds of millions or even billions of records. They’re designed for historical archiving, long-term auditing, and extending your data model with high-volume information like billing details or loyalty program activity.
The tradeoff is functionality. Big objects don’t support triggers, flows, process automation, or the Salesforce mobile app. They also don’t use the same sharing rules as standard objects, supporting only object-level and field-level permissions. You query them with SOQL and interact with them through Bulk, SOAP, and Chatter APIs, but not the REST API. Think of big objects as long-term storage that you read from rather than actively work with day to day.
Fields and Data Types
Every object, whether standard or custom, is defined by its fields. When you create or customize an object, choosing the right field types matters because it controls what data users can enter and how Salesforce handles that data in reports, formulas, and automation.
Common field types include text (for names and descriptions), number, currency, date, checkbox (true/false), picklist (a dropdown menu of predefined options), and formula fields that calculate values automatically based on other fields. There are also relationship fields, which are the lookup and master-detail fields that create connections to other objects.
Each field type has its own behavior. A currency field, for instance, respects your org’s currency settings and displays the right symbol. A picklist field restricts users to a set of choices you define, keeping your data consistent. Formula fields are read-only and recalculate whenever the underlying values change.
Where Objects Show Up in Practice
Objects aren’t just an abstract data layer. They shape what your users see and interact with every day. Each object typically gets its own tab in the Salesforce navigation bar, its own set of list views for filtering records, and its own page layouts that control which fields appear when someone opens a record.
Reports and dashboards pull data from objects and their fields. Automation tools like flows and validation rules operate on specific objects. When you integrate Salesforce with another system, you’re mapping fields from external data to fields on Salesforce objects. Understanding what objects exist in your org and how they relate to each other is the foundation for building reports, automating processes, and keeping your data clean.