Standard and Custom Objects

Standard and Custom Objects in Salesforce: A Complete Guide for Platform Developer 1 Exam

Why Standard and Custom Objects Matter

Standard and Custom Objects are the foundational building blocks of the Salesforce data model. Every Salesforce application — whether declarative or programmatic — relies on objects to store, organize, and manage data. As a Salesforce Platform Developer, understanding objects is absolutely critical because virtually every line of Apex code, every SOQL query, every Lightning component, and every automation you build interacts with objects in some way. The Platform Developer 1 (PD1) exam heavily tests your knowledge of how objects work, how they relate to each other, and when to use standard versus custom objects.

What Are Standard Objects?

Standard objects are objects that come built-in with every Salesforce org. They represent common business entities and processes. Examples include:

• Account – Represents a company or organization
• Contact – Represents an individual person, often associated with an Account
• Opportunity – Represents a potential sales deal
• Lead – Represents a prospective customer
• Case – Represents a customer support issue
• Task and Event – Represent activities
• User – Represents someone who logs into Salesforce
• Product, Pricebook, PricebookEntry – Represent product catalog data
• Campaign – Represents marketing campaigns

Standard objects have a predefined set of standard fields (e.g., Name, CreatedDate, OwnerId, Id) and predefined relationships. You cannot delete standard objects, but you can customize them by adding custom fields, validation rules, triggers, and more.

What Are Custom Objects?

Custom objects are objects that you create to store data specific to your organization's unique business requirements. When no standard object fits your needs, you create a custom object. Custom objects have the __c suffix appended to their API name (e.g., Invoice__c, Project__c).

Custom objects support virtually all the same features as standard objects, including:
• Custom fields
• Page layouts and record types
• Relationships (Lookup, Master-Detail, Many-to-Many via junction objects)
• Triggers, validation rules, workflow rules, and flows
• Sharing rules and security settings
• Reporting and list views

Key Differences Between Standard and Custom Objects

1. API Name Convention:
Standard objects use simple names (e.g., Account, Contact). Custom objects always end with __c (e.g., MyObject__c). Similarly, custom fields on any object end with __c, while standard fields do not.

2. Deletion:
Standard objects cannot be deleted. Custom objects can be deleted (they go to the Deleted Objects area for 15 days before permanent deletion).

3. Predefined Behavior:
Standard objects come with built-in behaviors, page layouts, and related lists. For example, the Opportunity object has built-in Stage and Probability fields, forecast integration, and the Opportunity Contact Role related list. Custom objects start with only a few system fields (Id, Name, CreatedDate, CreatedById, LastModifiedDate, LastModifiedById, OwnerId, SystemModstamp, IsDeleted).

4. Standard Fields:
Every object has standard fields like Id and Name. For standard objects, many additional standard fields exist (e.g., Account has Industry, AnnualRevenue, BillingAddress, etc.). For custom objects, you typically only get Name (which can be auto-number or text) plus system fields, and then you add your own custom fields.

5. Limits:
There are governor limits on how many custom objects you can create per org (varies by edition — Enterprise Edition allows up to 200 custom objects, Unlimited Edition allows up to 2,000).

How Objects Work in Salesforce

Object Relationships:

Objects don't exist in isolation. They are connected through relationships:

• Lookup Relationship: A loosely coupled relationship. The child record does not require a parent. Deleting the parent does not automatically delete the child. Both standard and custom objects can participate. The lookup field can be left blank (unless made required).

• Master-Detail Relationship: A tightly coupled relationship. The child (detail) record requires a parent (master). Deleting the master cascades the delete to all detail records. The detail record inherits its sharing/security from the master. Roll-up summary fields are available on the master object to aggregate data from detail records. A custom object can have at most two master-detail relationships. You cannot create a master-detail relationship on a standard object as the detail side if the standard object already has records (in most scenarios).

• Many-to-Many Relationship: Achieved using a junction object — a custom object with two master-detail relationships pointing to two different parent objects. This allows records from both parent objects to be associated with multiple records from the other parent.

• Hierarchical Relationship: A special type of lookup available only on the User object, allowing you to create a hierarchy (e.g., manager-subordinate).

• External Lookup: Used with External Objects to relate Salesforce data to data stored outside of Salesforce.

Schema Builder:
Salesforce provides Schema Builder, a visual tool for viewing and creating objects, fields, and relationships. It gives a graphical representation of your data model.

Custom Object Features:

When creating a custom object, you can enable several features:
• Allow Reports – Makes the object available for reporting
• Allow Activities – Enables Tasks and Events on the object
• Track Field History – Enables field history tracking
• Allow Search – Makes records searchable
• Allow Sharing – Enables sharing rules
• Allow Bulk API Access – Enables the Bulk API
• Allow Streaming API Access – Enables streaming notifications
• Deployment Status – In Development vs. Deployed (controls visibility to non-admin users)

Working with Objects in Apex

In Apex, you interact with objects using sObject types. Every object (standard or custom) is an sObject:

• Account acc = new Account(Name = 'Acme');
• Invoice__c inv = new Invoice__c(Name = 'INV-001');

You can use DML operations (insert, update, delete, upsert, undelete, merge) on sObjects. SOQL queries return lists of sObjects:

• List<Account> accounts = [SELECT Id, Name FROM Account WHERE Industry = 'Technology'];
• List<Invoice__c> invoices = [SELECT Id, Name FROM Invoice__c];

You can use dynamic Apex with the Schema namespace to describe objects and fields at runtime:
• Schema.DescribeSObjectResult describeResult = Account.SObjectType.getDescribe();
• Map<String, Schema.SObjectField> fieldMap = describeResult.fields.getMap();

You can also use generic sObject references for dynamic processing:
• sObject record = Database.query('SELECT Id, Name FROM Account LIMIT 1');

Key Concepts for the PD1 Exam

1. Field Types: Understand the different field data types available on objects — Text, Number, Currency, Date, DateTime, Checkbox, Picklist, Multi-Select Picklist, Lookup, Master-Detail, Formula, Roll-Up Summary, Auto Number, Email, URL, Phone, Percent, Text Area (Long, Rich), Geolocation, and External Lookup.

2. Roll-Up Summary Fields: These are only available on the master side of a master-detail relationship. They can perform COUNT, SUM, MIN, and MAX operations on the child records. This is a very commonly tested concept.

3. Formula Fields: Read-only, calculated fields. They can reference fields on the same record, fields on parent records (via relationship), and certain system variables. They do not count against data storage because they are computed on the fly.

4. Relationship Names: In SOQL, child-to-parent traversal uses dot notation (Contact.Account.Name). Parent-to-child traversal uses subqueries. For standard relationships, the child relationship name is typically the plural form of the child object (e.g., Contacts, Opportunities). For custom relationships, the relationship name ends with __r (e.g., Invoices__r).

5. Object-Level and Field-Level Security: Objects have profiles and permission sets that control CRUD (Create, Read, Update, Delete) access. Fields have field-level security that controls visibility and editability. In Apex, CRUD and FLS are not enforced by default — you must explicitly check them using methods like Schema.sObjectType.Account.isAccessible() or use WITH SECURITY_ENFORCED in SOQL or Security.stripInaccessible().

6. Sharing Model: The Organization-Wide Defaults (OWD) set the baseline access level for each object. Sharing rules, role hierarchy, manual sharing, and Apex sharing can open access further. Master-detail child records inherit the sharing settings of their parent.

7. Record Types: Allow you to offer different business processes, picklist values, and page layouts on the same object to different users.

8. Custom Settings and Custom Metadata Types: These are special types of custom objects. Custom Settings store configuration data (list or hierarchy). Custom Metadata Types store configuration data that can be deployed via packages and metadata API. Both are commonly used for application configuration rather than transactional data.

9. External Objects: Represent data stored outside Salesforce. They use the __x suffix. They are accessed via Salesforce Connect (OData or custom adapters). External objects support a subset of standard object features.

10. Big Objects: Designed for storing massive volumes of data (billions of records). They use the __b suffix and support limited query capabilities (only specific indexed fields can be queried). They are used for archiving or large-scale analytics.

11. Platform Events: These use the __e suffix and represent event messages in an event-driven architecture. While they are technically defined like objects, they are not data storage objects — they are publish/subscribe messaging constructs.


Exam Tips: Answering Questions on Standard and Custom Objects

Tip 1: Know the Suffixes
Always remember: custom objects end with __c, custom fields end with __c, custom relationships end with __r, external objects end with __x, big objects end with __b, and platform events end with __e. Exam questions often test whether you recognize valid API names.

Tip 2: Master-Detail vs. Lookup — Know the Differences Cold
This is one of the most frequently tested areas. Remember: Master-Detail = cascade delete, required parent, inherited sharing, roll-up summaries available. Lookup = independent records, optional parent (unless required), no cascade delete by default, no roll-up summaries natively. A custom object can have a maximum of 2 master-detail relationships, and up to 40 total lookup/master-detail relationships.

Tip 3: Roll-Up Summary = Master-Detail Only
If a question asks about summarizing child data on a parent, the answer almost always involves a master-detail relationship and a roll-up summary field. If they describe a lookup relationship, then a roll-up summary is not natively available (you would need a trigger, flow, or third-party tool like Declarative Lookup Rollup Summaries).

Tip 4: Read the Question for Object Type Clues
If a question mentions __c, it is referencing a custom object or custom field. If it mentions a standard object name like Account or Contact without __c, it is standard. Pay close attention to API names in code snippets.

Tip 5: Understand SOQL Relationship Queries
Be comfortable writing and reading both parent-to-child subqueries and child-to-parent dot notation queries. For example: SELECT Id, Name, (SELECT Id, LastName FROM Contacts) FROM Account is a parent-to-child query. SELECT Id, LastName, Account.Name FROM Contact is a child-to-parent query. For custom relationships, use the __r suffix for the relationship name.

Tip 6: Security Is Not Automatically Enforced in Apex
When questions ask about data access in Apex, remember that running Apex in system context means CRUD and FLS are NOT automatically enforced. You must explicitly enforce them. This is a common trap in exam questions.

Tip 7: Junction Objects for Many-to-Many
If a scenario describes a many-to-many relationship (e.g., a Student can enroll in many Courses, and a Course can have many Students), the solution is a junction object with two master-detail relationships. The first master-detail relationship determines the junction object's primary relationship and controls the detail page layout.

Tip 8: When to Use Custom Objects vs. Custom Settings vs. Custom Metadata Types
Transactional business data → Custom Objects. Application configuration data that needs to be cached → Custom Settings. Configuration/metadata that should be deployable across environments → Custom Metadata Types. The exam tests your ability to choose the right construct.

Tip 9: Object Describe Methods
Know how to use Schema.getGlobalDescribe() and sObjectType.getDescribe() to dynamically discover objects and fields. Exam questions may present scenarios where you need to determine fields or object properties at runtime.

Tip 10: Eliminate Wrong Answers by Checking Feasibility
If an answer option suggests creating a roll-up summary field on a lookup relationship, it is wrong. If an option suggests deleting a standard object, it is wrong. If an option says you can create a hierarchical relationship on a custom object, it is wrong (hierarchical relationships are only available on the User object). Use these definitive rules to quickly eliminate incorrect options.

Tip 11: Understand Object Limits
Custom objects have limits per edition. Custom fields per object are limited (typically up to 500 for custom objects in Enterprise and above). Relationship fields have their own limits. Being aware of these limits helps you answer questions about scalability and design considerations.

Tip 12: Practice with Real Scenarios
Many PD1 exam questions present a business scenario and ask you to design the appropriate data model. Practice identifying when to use standard objects, when to create custom objects, what relationship type to use, and where to put custom fields. The more scenario-based practice you do, the better prepared you will be.

Summary

Standard and Custom Objects form the backbone of every Salesforce application. Standard objects provide out-of-the-box functionality for common business processes, while custom objects allow you to extend the platform for unique requirements. Mastering the differences between relationship types, understanding field types (especially roll-up summaries and formulas), knowing API naming conventions, and being able to work with objects in Apex code are all essential skills for passing the Platform Developer 1 exam. Focus on the nuances — particularly around master-detail vs. lookup relationships, security enforcement in Apex, and choosing the right type of object for a given scenario — as these are the areas where the exam most frequently tests your knowledge.