Creating a custom object is one of the more common admin tasks on the platform. The walkthrough below covers the standard sequence from initial setup through deployment and adoption. The same general flow applies whether you are modeling a new business entity or extending the data model to support a new use case on an existing entity.
- Design the object before clicking anywhere
Sketch the object on paper or in a diagramming tool. Document its purpose, expected record volume, relationships to other objects (Lookup or Master-Detail), record types, and major fields. Validate the design with at least one business stakeholder. Most data model regret traces back to skipping this step, then realizing two months later that the object should have been a related list on an existing object rather than its own entity.
- Create the object in Object Manager
From Setup, navigate to Object Manager, click Create, and pick Custom Object. Fill in the Label, Plural Label, Object Name (API name), and Record Name field type. Enable Allow Reports, Allow Activities, and Track Field History as appropriate. Save. The object now exists with a Standard Name field plus the audit fields the platform always adds (CreatedDate, OwnerId, LastModifiedDate). Open the object's setup page to begin adding fields.
- Add fields and relationships
Add the custom fields the business needs, one at a time. For each field, pick the type carefully (a Picklist that should have been Text is hard to convert, and vice versa). Add the relationships to other objects, choosing Lookup or Master-Detail per the design. Set field-level security on each field for each profile. Group the fields logically on the page layout. Add validation rules for required field combinations or business-rule enforcement.
- Configure permissions, layouts, and roll out
Grant object permissions through profiles or (better) permission sets. Configure the page layout for each Record Type and assign per profile. Add the object to the relevant app menu so users can access it. Build a basic report type if the business will report on the object. Train the impacted users via a brief written guide. Communicate the new object's purpose so users know when to use it versus existing standard objects.
The display name and plural form shown in the UI for the object. Required at creation time.
The programmatic identifier ending in __c. Used in formulas, Apex, and integrations. Cannot be renamed easily.
Either a Text field or Auto Number, used as the primary display label for records.
Required to create custom objects and configure their fields, layouts, and permissions.
Without page layout assignment and object permissions, users cannot see or interact with the new object.
- Object Name (API name) is hard to change after records exist. Set it carefully on creation; rushing this leads to confusing inconsistencies later.
- Master-Detail is hard to convert to Lookup after records exist. Use Lookup as the default unless cascade-delete and Roll-Up Summary are specifically required.
- Field-level security is independent of page layout. A field can be on the layout but hidden by FLS, which surprises users who expect to see it.
- Activity-related objects (Task, Event) live in their own storage tier and have unique limits. They do not behave the same as other custom objects.
- Custom objects do not automatically appear in app navigation. Add them to the relevant app or users will not find them.