Salesforce has its own vocabulary for data. Two of the most important terms are sObject and SOQL. They show up in Apex, APIs, integrations, reporting work, and almost every serious Salesforce implementation.
The short version: an sObject is how Salesforce represents a record or object in its platform data model. SOQL is the query language you use to retrieve those records when you know which Salesforce object holds the data.
What is an sObject in Salesforce? #
An sObject is a Salesforce object or record as represented in code and APIs. In Apex, Salesforce explains that every record is represented as an sObject. An Account record maps to an Account sObject, a Contact record maps to a Contact sObject, and a custom Project record might map to Project__c.
That means the word can appear in two closely related ways:
- As a Salesforce object type, such as
Account,Contact,Lead,Opportunity, orProject__c - As an in-memory representation of a specific record, such as one Account record with a name, phone number, owner, and industry
If you think in database terms, a Salesforce object is roughly like a table, and a Salesforce record is roughly like a row. The sObject is the Salesforce platform abstraction that lets code and APIs work with that data without treating Salesforce as a normal SQL database.
Standard and custom sObjects #
Salesforce includes standard objects out of the box. Common examples include:
AccountContactLeadOpportunityCase
Teams can also create custom objects for business-specific data. Salesforce custom object API names usually end in __c. For example, a custom object labeled Project would commonly have an API name like:
Project__c
Custom fields also usually end in __c, while custom relationship names commonly use __r. This matters because Apex, APIs, and SOQL use API names, not always the user-facing labels people see in the Salesforce interface.
Specific sObjects vs generic sObjects #
When developers know the object type, they often work with a specific sObject type:
Account acct = new Account(Name = 'Acme');
Contact person = new Contact(LastName = 'Rivera');
Project__c project = new Project__c(Name = 'Implementation');
Salesforce also supports a generic sObject type. That is useful when code needs to handle records without knowing in advance whether the record is an Account, Contact, Case, or custom object:
sObject record = new Account(Name = 'Acme');
Specific sObjects are easier to work with because you can access fields directly with dot notation, such as acct.Name. Generic sObjects are more flexible, but field access usually happens through methods such as get() and put().
What is SOQL? #
SOQL stands for Salesforce Object Query Language. It is Salesforce’s query language for retrieving records from Salesforce data. It looks familiar if you know SQL, but it is designed for Salesforce’s object model.
A basic SOQL query names the fields you want, the object you want them from, and optional conditions:
SELECT Id, Name, Industry
FROM Account
WHERE Industry = 'Technology'
ORDER BY Name
LIMIT 25
This query asks Salesforce for up to 25 Account records in the Technology industry and returns only the Id, Name, and Industry fields.
How sObjects and SOQL relate #
sObjects are the data shape. SOQL is the read language.
When you write this query:
SELECT Id, FirstName, LastName, Email
FROM Contact
WHERE Email != null
you are querying the Contact sObject type. The results come back as Contact records, and in Apex those records can be stored as a list of Contact sObjects:
List<Contact> contacts = [
SELECT Id, FirstName, LastName, Email
FROM Contact
WHERE Email != null
];
The FROM Contact part tells Salesforce which sObject type to query. The field list after SELECT tells Salesforce which fields to retrieve on each matching record.
SOQL is not exactly SQL #
SOQL is intentionally SQL-like, but it is not general-purpose SQL. A few differences matter right away:
- SOQL queries Salesforce objects, not raw database tables.
- SOQL does not support arbitrary joins the way SQL does.
- Relationship queries use Salesforce object relationships instead of normal SQL join syntax.
- You usually name fields explicitly instead of using
SELECT *. - Query behavior is shaped by Salesforce permissions, sharing rules, field-level security, API limits, and governor limits.
For example, instead of writing a SQL join between accounts and contacts, SOQL uses relationship syntax. A child-to-parent query can walk from Contact to its parent Account:
SELECT Id, FirstName, LastName, Account.Name
FROM Contact
WHERE Account.Name = 'Acme'
A parent-to-child query can return contacts related to each account:
SELECT Id, Name, (
SELECT Id, FirstName, LastName
FROM Contacts
)
FROM Account
WHERE Name = 'Acme'
That relationship-aware structure is one of the reasons SOQL feels different from SQL even when the SELECT, FROM, and WHERE clauses look familiar.
When should you use SOQL? #
Use SOQL when you know which Salesforce object contains the data you need. It is a good fit when you want to:
- Retrieve records from one object, such as Accounts or Opportunities
- Retrieve fields from related records, such as a Contact’s Account name
- Filter records with known criteria
- Sort query results
- Count records that match a condition
- Read Salesforce data through Apex, REST API, SOAP API, Salesforce CLI, or developer tools
If you do not know which object or field contains a search term, Salesforce’s SOSL may be a better tool. SOQL is for targeted object queries; SOSL is for broader text search across indexed data.
Why this matters for CRM teams #
sObjects and SOQL are not just developer trivia. They define how Salesforce data is named, retrieved, integrated, and automated.
For sales operations teams, that means reports and automations become easier to reason about when object and field API names are documented. For integration teams, it means a sync must know whether it is writing to Account, Contact, Lead, or a custom object such as Subscription__c. For developers, it means almost every data operation starts with understanding the sObject model and then using SOQL to retrieve the right fields.
Simple mental model #
Think of it this way:
- Object label: The friendly name users see, such as Account or Project
- sObject API name: The platform name code uses, such as
AccountorProject__c - Record: One saved item inside that object, such as the Acme account
- SOQL: The query language used to retrieve records from one object or related objects
Once that clicks, a SOQL query becomes much less mysterious. SELECT Name FROM Account simply means: get the Name field from records whose sObject type is Account.
