What is a custom object in a CRM, and how is it different from a custom field?

A property management company tracks contacts and deals fine in its CRM, but it also needs to track individual rental units — each with its own address, square footage, lease history, and link to multiple tenants over time. There’s no clean way to force “unit” into a contact or a deal. That’s the gap a custom object exists to fill.

What is a custom object?

A custom object is a new record type you define inside a CRM, alongside the built-in ones like Contacts, Accounts, and Deals. Where a custom field adds one more attribute to a record that already exists — a “Preferred Contact Time” field on a contact, say — a custom object creates an entirely new kind of record, with its own fields, its own list views, and its own relationships to other objects. Equipment, Properties, Subscriptions, and Warranties are common examples: none of them are a person or a company, so none of them belong on a standard object.

How is it different from a custom field?

The distinction is scale, not just terminology. A custom field extends what you can say about a record you already have — it adds a column to an existing table, in database terms. A custom object adds a whole new table, with its own rows, its own fields, and its own relationships to contacts, accounts, or deals. If the thing you’re tracking has many-to-many relationships with your existing records (one property, many tenants over time; one tenant, many properties over time), you need an object, not a field — a field can’t represent that structure.

When do you actually need one?

Most small businesses never need a custom object — contacts, accounts, and deals cover the vast majority of B2B sales data, and reaching for a custom field first is usually the right call because it’s simpler to build and simpler for reps to use. Custom objects earn their complexity when you have a distinct category of “thing” with its own lifecycle — locations, assets, projects, subscriptions — that has many records per account and needs its own reporting, not just a note on an existing record.

What should you do next?

Before creating a custom object, check whether your CRM’s data model already has a fit-for-purpose way to represent what you’re modeling, and whether a related list of custom fields on an existing object would actually cover it more simply. Custom objects add real maintenance overhead — new permissions, new automation rules, new reports to keep in sync — so build one only when a field genuinely can’t do the job.