Overview of Salesforce Objects and Fields

Salesforce uses "objects" (like tables in Excel) to store data. Each object has "fields"
(like columns) to hold specific information like name, email, etc. There are standard
objects (built-in like Contacts) and custom ones (you can create your own). Think of
it like creating a structured form to keep all data organized.

Primitive Data Types​

These are the basic types of data you can store in Salesforce fields. Examples
include:
●​ Text (String)
●​ Numbers (Integer, Decimal)
●​ Dates
●​ Boolean (true/false)
They’re like setting the format of a cell in Excel so the right kind of data is stored.

Field Types​
This explains the different kinds of fields you can create on an object, like:
●​ Text Field: for names or comments
●​ Picklist: dropdown menu options
●​ Checkbox: yes/no answers
●​ Lookup: link to another record
It’s about choosing the right field type for the kind of info you want to collect.

API Field Properties​

This talks about the settings behind each field, such as:
●​ Is the field required?
●​ Can it be updated or read only?
●​ Can it be accessed through the API?
Basically, it defines how a field behaves and who can see or change it.

Required Fields
These are the fields that must have data filled in—Salesforce won’t let you save a
record without them. For example, a Contact might need at least a name and email.
These are like mandatory questions on a form.

System Fields​
Salesforce automatically creates certain fields on every record like:
●​ Created Date
●​ Last Modified Date
●​ Record Owner
These help track when and by whom data was added or changed.

Frequently Occurring Fields​

Common fields you’ll see often in different objects like:
 ●​ Name
●​ Email
●​ Phone Number
They’re used across many objects because they’re basic and universal.

Compound Fields​
These are special fields that group together related data, like a full address. Instead
of having separate fields for street, city, state, etc., a compound field treats them as
one unit for simplicity—but they still store the parts separately under the hood.

Address Compound Fields​

A specific type of compound field used for addresses. It includes things like:
●​ Street
●​ City
●​ Postal Code
●​ Country
Salesforce treats it as one big address field, but you can still access or update each
piece.

Geolocation Compound Field​

Another compound field that stores a location using:
●​ Latitude
●​ Longitude
You can use this data to show locations on maps or calculate distances between
records (like nearby stores or customers).

Compound Field Considerations and Limitations

●​ Compound fields are grouped fields—like Address (street, city, postal code).
●​ You can’t report on individual parts of a compound field directly; you must
extract them.

Custom Objects 1
●​ These are objects you create to store business-specific data.
●​ Useful when standard objects don’t meet your needs.
●​ Custom objects work like spreadsheets where each row is a record and each
column is a field.

Custom Fields
●​ Custom fields are extra fields you add to standard or custom objects.
●​ You choose the type of data they hold—like text, numbers, date, etc.
●​ Fields can be required or optional and have limits on size and formatting.

AppExchange Object Prefixes and the API

●​ Every object installed from AppExchange has a prefix to identify it.
 ●​ Helps Salesforce know where an object or field came from and avoid naming
conflicts.

Relationships Among Standard Objects and Fields

●​ Salesforce lets you link data across objects using relationships:
○​ Lookup (basic connection)
○​ Master-Detail (stronger dependency between records)
●​ Relationships help organize and connect data like contacts to accounts or
products to orders.

Factors that Affect Data Access

●​ Access to data is controlled by permissions, roles, profiles, and sharing
settings.
●​ Just because data exists doesn’t mean every user can see or change it.
●​ Important for data security and compliance.

Field and Type Differences in Salesforce Apps and APIs

●​ Some field types behave differently in Salesforce vs. API calls.
●​ For example, fields like checkboxes or formula fields might look different or
behave differently in the backend.
●​ Knowing this helps avoid data sync issues when integrating with other
systems.

External Objects
●​ These represent data stored outside Salesforce.
●​ Useful if your data lives in another system but you want to access it in
Salesforce without storing it.
●​ You can view and report on it like any normal object.

Big Objects
●​ Big Objects are used to store huge amounts of data—millions or even
billions of records.
●​ They are great for archiving, tracking user activity, or storing external data
for reporting.
●​ There are two types: standard (built-in) and custom (you create them).
●​ Big Objects don’t support triggers or flows and are optimized for scale, not
speed.

Define and Deploy Custom Big Objects

●​ You can create your own Big Objects using Metadata API or Salesforce
Setup.
●​ Once deployed, you can’t change the index (used to organize/search the
object).
●​ Each custom Big Object must have:
 ○​ Fields (data points you store)
○​ Permissions (who can see/edit what)
○​ Index (key fields used to sort and find records)

Salesforce Object Behavior

This explains how Salesforce objects behave. Each object stores different types of
business information (like accounts, contacts, opportunities). Some objects can be
customized, and others are read-only. It also shows how objects relate to one
another.

Object Groups
Salesforce objects are grouped into types:
●​ Common Objects: Basic data like names and emails.
●​ High-Scale Objects: Used for large amounts of data.
●​ External Objects: Data that lives outside of Salesforce.
●​ Data Cloud Objects: For advanced data models and analytics.

Salesforce Common Objects

These include objects like Account, Contact, and Opportunity—standard ones
used in nearly every Salesforce setup. They're great for organizing customer and
company data.

Salesforce Cloud Objects

These are Salesforce objects used across its various cloud products, such as Sales
Cloud and Marketing Cloud. They store data that’s useful across departments.

Salesforce High-Scale Objects

These objects are built to handle very large volumes of data. You use them when
you need to store lots of records or process big data workloads.

Salesforce Data Cloud Objects

These are specialized objects that support Salesforce’s Data Cloud. They help unify
and analyze data from different sources and are used in big data and analytics
projects.

Salesforce External Data Objects

These objects represent data that isn’t stored inside Salesforce but can still be
viewed or used in Salesforce. It’s like referencing an outside source without
importing the data.

Salesforce Object Types

There are different types of objects:
●​ Standard (built-in),
●​ Custom (user-created),
 ●​ Big Objects (for huge data),
●​ External (referenced from outside),
●​ Platform Events (for real-time events).

Object Cheatsheet
This gives a quick comparison of different object types, like what they’re used for and
which systems they work in. It helps you choose the right object for your data needs.

Associated Objects (Feed, History, Share, etc.)

These are extra objects that track activity on other objects:
●​ Feed: Tracks updates or posts.
●​ History: Tracks field changes.
●​ Share: Manages sharing of records.
●​ ChangeEvent: Captures record changes in real time.

StandardObjectNameFeed
These are feed objects tied to standard Salesforce objects (like Accounts or Leads).
They track updates, comments, or posts, and help users see history or collaboration
around those objects.

StandardObjectNameHistory
This object tracks the history of changes made to a record's fields. It shows who
made the change, what was changed, and when. It’s useful for auditing and tracking
updates over time.

StandardObjectNameOwnerSharingRule
These are rules that define how records are shared based on their owner. For
example, if a user owns an account, this object helps determine who else should
have access to it.

StandardObjectNameShare
This object defines who can see or edit a specific record. It’s used when manual or
rule-based sharing is in place and controls the visibility of data.

StandardObjectNameChangeEvent
These objects are used to track changes to data in real-time (like creation, update,
delete). They’re part of Salesforce’s Change Data Capture feature and let other
systems stay up to date with Salesforce records.

Custom Objects 2.pdf

Custom objects let you create unique data structures in Salesforce for your own use
case. When you add features to them—like sharing rules or feeds—Salesforce
creates support objects to manage those features (e.g., “MyObject__Feed” or
“MyObject__Share”).
Custom Metadata Type__mdt
This is a special type of custom object used for storing configuration or settings (like
picklists) across the system. It's great for things that rarely change and can be
packaged and reused easily.

Custom Object__c
This is the core custom object you create in Salesforce, used to store any data that
doesn’t fit into the standard Salesforce structure. You can use it like a regular
object—query, update, or create records.

Custom Object__Feed
This object tracks posts and updates on a custom object’s feed in Salesforce. It's
used to view conversations and changes made to a custom record. You can delete
posts you created (with some rules), and fields include the post body and comment
marked as the best answer.

Object Interfaces
Object interfaces define how different Salesforce data types and objects
interact—such as price adjustments or sales transactions. Think of them as
templates that help structure how data behaves in certain modules.