Salesforce Object

A Salesforce object is the basic unit the platform uses to organize information: it is equivalent to a database table where each row is a record and each column is a field. For example, the Account object stores companies, the Contact object stores people and the Opportunity object stores deals in progress. Each record in an object has a unique 15- or 18-character identifier (the Id) that Salesforce uses to reference it internally.

Salesforce distinguishes two main families. Standard objects come built in out of the box (Account, Contact, Lead, Opportunity, Case, among others) and are the foundation of products such as Salesforce. Custom objects are created by each company to model its own data that does not fit the standard ones (for example, "Policy," "Shipment" or "Subscription"), and you can recognize them by the `__c` suffix in their API name.

Each object carries its fields, its relationships with other objects, validation rules, page layouts and permissions. That is why understanding the object model is the first step to designing any implementation well.

How an object is structured

Each object brings together several pieces worth knowing. Fields are the columns that store each record's data (text, number, date, picklist, formula). Relationships connect objects to each other: a lookup relationship links two records in a flexible way, while a master-detail relationship ties the child record to the parent (if the parent is deleted, the children are deleted, and the child inherits permissions and ownership). In addition, each object has page layouts that define how the form looks, record types to have variants of the same object depending on the process, and a set of permissions that controls who can see and edit it.

A key detail for anyone just getting started is the API name. Standard objects use their plain name (`Account`, `Opportunity`), but custom objects carry the `__c` suffix (for example `Shipment__c`), and so do their custom fields (`Tracking_Number__c`). That API name is the one used in SOQL queries, in Apex code, in Flow and in the integration API.

Standard object vs custom object

The practical difference between the two types can be summed up like this:

The general recommendation is to reuse the standard object whenever the data fits (a company goes in Account, a person in Contact) and only create custom objects for what the platform does not cover. Forcing data into the wrong object complicates reports and automations down the road.

Why it matters for the business

The object model is not an isolated technicality: it determines what you can measure, automate and report on. A bad modeling decision (loose fields, duplicate objects, poorly built relationships) drags on for years and makes every change more expensive. A clean model, on the other hand, becomes a single source of truth on which you can build reliable dashboards and processes.

A concrete example

Think of a consumer goods company that sells to supermarkets. The Account object stores each chain, the Contact object stores the buyers, the Opportunity object stores each product listing negotiation, and a custom Visit__c object records every perfect store audit at the point of sale. With everything related to everything else, that structure lets you answer questions like "which accounts did not get a visit this month?" with a simple report.

Common mistakes

• Creating a new custom object when the data fit into a standard one, duplicating information.
• Storing several different concepts in the same object with a "type" field instead of using record types or separate objects.
• Overusing master-detail relationships when a lookup was enough, losing flexibility.
• Ignoring governor limits and the limits on the number of fields when overloading an object.

Understanding what an object is and when each type makes sense is the foundation of any serious project on the platform, from a sales CRM to a large-scale data integration.