The Problem Custom Objects Solve

Most CRM implementations begin the same way.

A contact record stores:

• Name
• Phone Number
• Email Address

Then the business grows.

One customer now has:

• Multiple insurance policies
• Multiple properties
• Several vehicles
• Several projects

The natural response is to simply add more custom fields.

Soon the contact contains:

• Property 1
• Property 2
• Property 3

or

• Policy 1
• Policy 2
• Policy 3

At first this feels simple.

Over time it becomes difficult to:

• Report on the data
• Build automations
• Track history
• Find information
• Maintain consistency

This is exactly the problem Custom Objects were designed to solve. 

What Is a Custom Object?

A Custom Object is a completely new type of record that you define.

Rather than representing a person, it represents something connected to that person.

Examples include:

• Insurance Policy
• Property
• Claim
• Job
• Vehicle
• Equipment
• Project
• Pet

Each object has:

• Its own fields
• Its own lifecycle
• Its own workflows
• Its own reporting

while remaining connected to the appropriate contact. 

The Custom Field Trap

One of the most common mistakes in CRM design is what we call the Custom Field Trap.

Imagine you're tracking insurance policies.

Your first client has one policy.

Easy.

You create a field called:

Policy Number

Then another client has two policies.

Now you create:

• Policy Number 1
• Policy Number 2

Soon another client has five policies.

Now your CRM contains:

• Policy Number 1
• Policy Number 2
• Policy Number 3
• Policy Number 4
• Policy Number 5

The CRM has no idea these fields are related.

To the system, they're simply five unrelated text fields.

Reporting becomes difficult.

Automation becomes difficult.

Maintenance becomes difficult.

Custom Objects eliminate this problem by making each policy its own record instead of another field. 

The Five-Question Decision Framework

One of the easiest ways to decide whether something should become a Custom Object is to ask these five questions.

Should this be a Custom Object?


 Ask yourself: 
• Can one contact have more than one of these?

• Does it have its own lifecycle?

• Can it be shared between multiple contacts?

• Does it have details that describe the thing instead of the person?

• Do you need to report on it separately?


 If you answer Yes to any one of these questions, a Custom Object is likely the better solution.




	

	

This simple framework can help you avoid building a CRM that becomes difficult to manage as your business grows. 

Contact Fields vs. Custom Objects

Industry Examples

Although the concept is the same, every industry uses Custom Objects differently.

The pattern never changes.

Store information about the "thing" separately while keeping it connected to the people involved. 

Benefits of Using Custom Objects

Properly designed Custom Objects allow you to:

• Keep contact records clean
• Eliminate duplicate custom fields
• Build meaningful dashboards
• Create more advanced automations
• Track the lifecycle of each record independently
• Scale your CRM without rebuilding it

When You Should NOT Use a Custom Object

Custom Objects are powerful, but they aren't always necessary.

A standard Contact field is usually the better choice when:

• The information only exists once per contact.
• The information doesn't change over time.
• You don't need to automate it.
• You don't need to report on it separately.

Keep your CRM as simple as possible while still supporting your business processes. 

Best Practices

• Design the object before creating fields.
• Keep your first version simple.
• Use descriptive names.
• Think about how the object will be reported on.
• Consider future automation requirements.
• Avoid creating numbered fields such as "Policy 1" or "Property 2."

Summary

Custom Objects allow Momentum CRM to grow beyond a simple contact database into a true relational CRM.

Instead of forcing multiple policies, properties, projects, or other business records onto a Contact, each becomes its own object with its own data, workflows, and reporting.

If you're unsure whether something belongs on a Contact or should become its own record, ask yourself one simple question:

"Am I describing the person, or am I describing something the person owns or is associated with?"

If you're describing the "thing" rather than the person, a Custom Object is often the better solution.