[object Object]

A team creates a “Project” custom object on Monday because their professional services flow needs one. By Friday they have created “Project Phase,” “Project Resource,” “Project Deliverable,” and “Project Risk.” Each made local sense and the data model now requires a five-table join to answer “which projects are at risk.” Custom objects are the right answer for some entities and the wrong answer for many. Pick deliberately.

What custom objects give you

A custom object is a first-class CRM entity beside Contact, Company, Deal, and Ticket. Available on Enterprise tiers (and selected hubs). Each custom object gets:

- Its own database table
- Configurable properties
- Associations to standard objects and other custom objects
- Pipelines with stages
- Records UI with views and filters
- Workflow triggers and actions
- Custom report builder dimensions
- API endpoints

Examples that fit well: Subscription, Shipment, Project, Loan Application, Property Listing.

When custom is the right answer

Three tests. The entity passes the bar if all three are true:

1. Distinct lifecycle the standard objects can't represent
2. Multiple-per-parent relationship that doesn't fit a property
3. Reporting needs the entity as a first-class noun

A “Subscription” tied to a customer fits all three. A “Lead Source” does not — it is a property on Contact. A “Project Phase” probably belongs as a property on Project, not its own object.

Schema design

Custom object: Subscription
  Properties:
    plan_name        (single-line text)
    monthly_amount   (number)
    start_date       (date)
    renewal_date     (date)
    status           (dropdown: active, paused, churned)
    seats            (number)
  Associations:
    Company (parent)        -> 1:N
    Primary contact         -> 1:1 with label "Billing contact"
    Deal (origin)           -> 1:1 with label "Origin deal"
  Pipeline:
    New > Active > At risk > Churned

Resist adding properties speculatively. Start with the minimum the use case requires and add as questions surface.

Associations and the join trap

Custom objects associate to standard objects and to each other. Use labels on associations so reports answer the question you really mean. Avoid chains beyond two hops — Subscription > Project > Phase > Task is three hops and most reports will not traverse it cleanly:

Acceptable:
  Company > Subscription > Subscription Event

Risky:
  Company > Project > Phase > Deliverable > Owner
  (collapse Phase + Deliverable into properties on Project)

Pipelines for process-driven custom objects

If the entity has a lifecycle, configure a pipeline. If it does not, leave pipelines off. A status property is enough for entities that change state rarely:

Subscription pipeline:
  New > Active > At risk > Churned > Reactivated

Property listing pipeline:
  Listed > Under contract > Closed

Workflow triggers fire on stage change, just like deals.

Limits to verify before committing

- Record count per object (varies by tier)
- Properties per object (~600 max)
- Custom objects per portal (limited by tier)
- Associations per record (~5,000)
- API request quotas

A reporting object pushed past 250k records starts hitting list-building latency. Plan partitioning by year or by status if growth is steep.

Migration from properties to a custom object

If you started by stuffing the entity into properties on Contact and have outgrown it, plan a one-time migration: model the custom object schema, write a migration script that creates one record per source contact, archive the old properties after a 30-day verification window.

What to do this week

Apply the three-test bar to every custom object idea on your backlog, model the highest-priority one as a schema doc, and validate report and workflow needs before clicking create on the new object.

[object Object]
Share