4.1 Standard Objects, Custom Objects, and Schema Fit
Key Takeaways
- Start with standard objects when they already represent the business noun, because they bring native relationships, features, reporting, and app behavior.
- Use custom objects when the organization needs to store a distinct business concept with its own lifecycle, ownership, relationships, and reporting needs.
- A good schema fit accounts for security, automation, reporting, integrations, mobile use, and long-term maintenance, not just the first screen users ask for.
- Object Manager changes are metadata changes, but the data model choices they create can be expensive to unwind after records, flows, and reports depend on them.
Choosing the Right Object Shape
Object Manager is where an administrator defines the objects, fields, relationships, buttons, record types, compact layouts, page layouts, and other metadata that describe how business data is stored. The first modeling decision is not which custom object to create. The first decision is whether Salesforce already has a standard object that matches the business noun closely enough.
Standard objects such as Account, Contact, Lead, Opportunity, Case, Campaign, Product, Asset, Contract, and User are more than tables. They participate in native application features, automation entry points, sharing behavior, reporting types, related lists, mobile experiences, and setup pages. If the business wants to manage customer support requests, Case is usually the starting point. If it wants to track sales revenue and pipeline, Opportunity is usually the starting point.
A custom object is appropriate when the organization has a durable concept that standard objects do not represent well. Examples include Grant Application, Facility Inspection, Subscription Entitlement, Course Enrollment, or Warranty Claim. A custom object can have its own tab, fields, relationships, record types, sharing model, reports, automation, and Lightning record page. That power is useful, but it also creates maintenance responsibility.
Do not create a custom object just because users say they need a new screen. The request may be a field on an existing object, a record type, a page layout, a related list, a list view, a report, or a Lightning page variation. Creating the wrong object can split the customer story across too many records and make reporting, security, deduplication, and automation harder.
| Requirement clue | Likely design direction | Admin reasoning |
|---|---|---|
| Tracks a sales deal amount, close date, and stage | Standard Opportunity | Native pipeline, forecasting, products, and sales reports are already aligned. |
| Tracks a support issue from intake to resolution | Standard Case | Queues, assignment, escalation, email, and service reporting are already available. |
| Tracks a recurring inspection with its own status and findings | Custom object | The concept has its own lifecycle and needs related records. |
| Tracks a customer category or preference | Field or picklist | A full object would add unnecessary navigation and joins. |
| Tracks two variants of the same object with different fields and processes | Record types and layouts | The records share the same business noun and reporting base. |
In Setup, the practical workflow is to open Object Manager, review the object list, inspect fields and relationships on likely standard objects, and check whether existing apps already expose the behavior. In a Trailhead Playground or Developer Edition org, build a tiny proof of concept before committing. Create sample records, try a report, view the mobile layout, and test whether the object model answers the actual business question.
Schema fit includes ownership and security. Some objects have special behavior that affects sharing or feature access. Custom objects can use organization-wide defaults, role hierarchy access, sharing rules, teams where supported by product features, and permissions through profiles and permission sets. Before creating an object, ask who owns records, who needs to see them, and whether access differs by region, function, or record type.
Schema fit also includes reporting. If executives need one report showing Accounts, Opportunities, and the new concept, the relationship path matters. If operations needs to group the new concept by status, owner, date, and parent account, those fields must exist in report-friendly types. A field buried in long text or encoded in a naming convention is not a reportable model.
Integration and automation are part of the same decision. API names become contracts for integrations, flows, validation rules, formulas, and reports. A custom object that seems simple on day one may later need record-triggered flows, duplicate rules, approval processes, external IDs, and data imports. Choose names and relationships that still make sense when another system reads or writes the records.
A common exam trap is confusing navigation with data storage. Adding a tab makes an object easier to find, but it does not grant object permissions. Adding a related list shows related records, but it does not create the relationship field. Creating a Lightning page changes the experience, but it does not change the underlying schema. Admins need to know which setup area changes data structure and which changes presentation.
Another trap is assuming custom always means flexible. Standard objects often have the most flexible business value because Salesforce has built surrounding features around them. Custom objects are flexible in structure, but they lack some native app behavior unless you configure it or build it. The best model uses standard capability where it fits and reserves custom schema for concepts the platform does not already model.
A concise checklist helps before you build:
- Name the business noun and its lifecycle.
- Check standard objects and existing custom objects first.
- Identify parent records, child records, and reporting questions.
- Decide who owns records and who must access them.
- Consider whether record types or fields solve the variation.
- Prototype with sample records, reports, and a Lightning page.
- Review downstream impact on automation, integrations, and data imports.
For the exam, expect scenario language. If the request says users need different values, screens, or processes for the same kind of record, think record types, page layouts, and business processes. If the request describes a separate thing with its own records, owner, security, and reporting, think custom object. If the request describes one attribute of an existing thing, think field.
A company wants to track field inspections performed at customer sites. Each inspection has its own date, status, findings, owner, and related follow-up tasks. What is the best starting design?
Users ask for a new workspace for enterprise opportunities, but the records are still sales deals with amount, close date, products, and stage. Which decision should the admin consider first?
Which statement best describes the difference between adding a custom object tab and granting access to that object?