Lesson 7 of 18 · 5–7 minutes
Objects, Fields & Records
Relationships and access rules need a clear unit of data. Start here so you know what you are connecting and securing.
Learning sequence · data model first, security layers next
- What CRM and Salesforce Do
- The Salesforce Ecosystem and Major Clouds
- Org, App, Object, Field, and Record
- Standard and Custom Objects
- Common Standard Objects
- Field Types and Data Quality
- Objects, Fields & Records
- Lookup vs Master-Detail
- Many-to-Many Relationships and Junction Objects
- Profiles, Permission Sets & Object Access
- Field-Level Security
- OWD and Least-Privilege Record Access
- Opening Access: Role Hierarchy, Sharing Rules, Public Groups & Apex Sharing
- Apex First Steps
- Variables and Collections
- SOQL and DML Basics
- Why Asynchronous Apex Exists
- REST Callout Introduction
Your focus
Prepare for Your Next Developer Role
REVIEW · Review • Apply • Practice
- Choose standard vs custom objects; explain why repeating text fields fail.
Learning objective
Separate a business entity, its attributes and its individual instances before choosing relationships.
Before you start
No Salesforce development experience required.
Real-world scenario
A support team uses Account for customer organizations and Case for service requests. One customer can raise several Cases, each with its own status. Putting Case 1, Case 2 and Case 3 text fields on Account would hide that repeating business relationship.
The concept
An object defines a kind of business data. A field defines an attribute and its data type. A record holds the values for one instance. Account and Case are standard objects. Add a custom field for a missing attribute; consider a custom object when the business concept needs its own records and lifecycle. A new label alone is not a reason to duplicate a standard object.
Sketch the entities first. Then select field types: a date for the promised response date, a picklist for an agreed status vocabulary, and a relationship for the customer. API names are integration contracts; labels are what people read.
Read left to right as definition to instance, not as a database relationship.
1.Object: Case
Defines a support request.
2.Field: Status
Defines the request’s current state.
3.Record: request 1042
One request with Status = New.
- Object: Case connects to Field: Status: defines attributes
- Field: Status connects to Record: request 1042: stores a value on each instance
Common mistake
Using a text customer name as a relationship: spelling changes and duplicate names make joins and reporting unreliable. Use a record reference when the business meaning is a link.
Interview angle
“Would you add a field or create an object?” Explain whether you are storing one attribute or repeated items with their own lifecycle. Ask how users need to report on them.
Pause and apply
Sketch a customer with two support requests. Which values belong on Account, and which belong on each Case? Give each request a distinct identifier.
Official references
- Trailhead: Standard and Custom Objects (opens in a new tab)
- Trailhead: Create Object Relationships (opens in a new tab)
Reviewed 2026-09-22. Examples are illustrative; no code is executed here.
Key takeaways
- Model entities before fields, then create records.
- Field types influence validation, querying and reporting.
- Relationships affect ownership, sharing, automation and migration; choose them next.
Practice next
No linked assessment is available for this lesson. Use the pause-and-apply question to check your reasoning.
Reading these lessons does not yet save completion. Challenge results continue to provide assessment evidence.