What you’re working toward.
An explicit data-model decision backed by record, reporting, and integration tests.
- Bring these people
- CRM architect, operations owner, and integration administrator
Have these inputs ready
- Examples of the entity, its lifecycle, and its relationships.
- The reports and workflows that need to use it.
- A confirmed account entitlement and inventory of connected systems.
Name the entity
Describe the thing independently: a location, contract, installation, or membership. If it has its own lifecycle and many related records, it may need a separate model. If it is just an attribute, a property may be enough.
- Describe the entity without mentioning HubSpot: what identifies it, who owns it, when it is created, and when it ends. A field with many values is not automatically a separate entity.
- Compare a standard object, a property on an existing object, and a new custom object. Choose the simplest model that preserves distinct records and their meaning.
A model decision with rejected alternatives and reasons.
Map relationships
Draw how the entity connects to contacts, companies, deals, and other records. Define stable identifiers and which relationships are required. Test whether standard objects can represent the business without ambiguity.
- Draw one-to-many and many-to-many relationships using real examples. Mark the required associations and explain what should happen when a parent record is missing.
- Define a durable external key and the rule for renaming or merging entities. Do not rely on a display name that users can edit.
An entity-and-relationship diagram plus identifier rules.
Check the operating cost
Consider reporting, integrations, permissions, imports, and user training. Verify subscription availability and API support before choosing a custom object. More structure is useful only when the team can maintain it.
- Verify that the chosen object works in the reports, workflows, permissions, and connector operations you need. Test the exact tool path rather than assuming every connector supports every object.
- Name who maintains the schema, resolves duplicates, and approves future fields. Include these responsibilities in the handover.
A capability checklist and ongoing ownership plan.
Prototype before committing
Build sample records and walkthroughs for creation, update, handoff, and retirement. Validate the key reports and migration path. Document the model and name an owner for future changes.
- Create examples covering one entity with multiple contacts, one company with multiple entities, and an inactive entity. Rehearse creation, update, reassignment, and retirement.
- Build the most important report before a full migration. Confirm that a user can answer the business question without exporting and manually reconstructing relationships.
A demonstrated report, scenario test, and approved migration approach.
Property or separate record?
Illustrative modeling decisions for a multi-location service business.
Know when the work is ready.
Use these checks in the handover. Keep evidence of the result and assign an owner to anything that still fails.
- The chosen model represents the required relationship cardinality.
- The principal report works with representative records.
- Connected systems can create, read, and update the required data.
- The admin team has an ownership and change process.
Catch the problems early.
Building an object to avoid a definition
A new container does not resolve an unclear business process. Agree the entity and lifecycle first.
Testing record creation but not reporting
An elegant schema can still fail the operational question. Validate the main report before moving real data.