Custom Object

What it is

Standard CRM objects — company, contact, deal, ticket — cover most B2B selling. A custom object is one you define when your business has a durable thing those four cannot represent: a subscription with its own term and renewal date, a property, a vehicle, a legal matter, a shipment.

When it is justified

• The thing has its own lifecycle, independent of any single deal.

• It has attributes nothing else owns, and stuffing them onto a deal would distort the deal record.

• You need to report on it directly, not merely as a field on something else.

• It relates to several other records at once — one subscription spanning many contacts, for instance.

When it is not

If the answer is a handful of extra fields on an existing object, use the fields. A custom object introduces its own permissions, its own associations, its own reporting surface and its own migration problem later. The cost is not the creation; it is that every integration, report and automation downstream now has one more shape to know about.

The governance point

Custom objects are where CRM complexity compounds fastest, because each one invites custom properties, which invite custom workflows, which invite custom reports. Create as few as the business genuinely requires, and write down why each exists — the person who inherits the portal will otherwise have no way to tell a deliberate design from an accident.

How to decide, in one sitting

1. Write the thing down as a sentence: what it is, who creates one, and what it relates to. If you cannot name what it associates with, it is an attribute of something else rather than an object.

2. Count the fields it genuinely needs. Under about six, and with no independent lifecycle, the honest answer is usually properties on an existing object.

3. Ask whether it has its own lifecycle — does it get created, change state and end independently of the deal or company? Independent lifecycle is the strongest argument for a custom object.

4. Name the owner. Every custom object is a schema somebody maintains forever, including its permissions, its associations and its reporting. An object with no named owner will drift.

5. Check reporting before building. Custom objects are frequently harder to report across than standard ones, and discovering that after migration is expensive.

Where it goes wrong

• Modelling a process as an object. A stage a deal passes through is usually a property or a pipeline, not a record type — and once built as an object it is painful to unwind.

• One custom object invites custom properties, which invite custom workflows, which invite custom reports. This is where CRM complexity compounds fastest and least visibly.

• Permissions do not inherit the way people expect. A user who can see the parent company may not see the related custom records, which produces reporting that differs per user.

• Integrations frequently do not support custom objects, or support them at extra cost. Check the tools that must read it before the schema is agreed.