Custom object model and dedupe on HubSpot CRM
Contact and Deal alone couldn't describe a childcare business built around physical locations and individually enrolled children. We added two custom objects, Campus and Children, each associated back to the standard CRM. A Children record ties to the family's Contact and to the Campus the child attends, and a Campus record carries its own pipeline views and tickets. Configuring views and permissions across all four objects was an ongoing, ad hoc stream of requests, answered and logged daily rather than a single rollout.
Executive Summary
Context
The object model briefly carried data nobody could trust. An earlier CSV import had duplicated records in both new objects, and the duplicates had to be identified and removed before the deal pipelines and tickets already keyed to Campus could rely on that data.
What We Built
We built two custom HubSpot objects, Campus for each physical location and Children for each enrolled child, both associated to the standard Contact and Deal records. Alongside the build, we configured and maintained Contact, Deal and Ticket views and permissions on an ongoing basis, then cleaned up the duplicate Campus and Children records left behind by an earlier CSV import.
Tech Stack
- HubSpot CRM
- Campus custom object
- Children custom object
- Contact and Deal objects
- CSV import
- record deduplication
Not a fit if a business already fits inside the standard Contact and Deal model. A second location object earns its place only when the native CRM has nowhere to put that structure. It also assumes the feeding CSV import is trustworthy from day one. Here it wasn't, and matching happened after the fact rather than at import time.
The Challenge
A childcare network with dozens of physical locations and thousands of enrolled children had nowhere in a standard Contact and Deal model to represent either one as its own record. Locations needed their own pipeline views and ticket routing. Children needed a record independent of the parent Contact filling out a form.
On top of that gap, an earlier CSV import had duplicated a large share of the Campus and Children records.
Our Approach
We built Campus and Children as custom objects associated to Contact and Deal, because a property on Contact can't carry its own pipeline views or tickets. A Children record ties to the family's Contact and to the Campus the child attends. A Campus record carries the pipeline views and tickets scoped to that location.
We configured and adjusted views and permissions continuously as requests came in, rather than fixing them once at launch.
Once we found the duplication, we isolated the duplicate rows in each object and removed them, which left the records the import had not duplicated in place.
Impact
Campus and Children exist as their own CRM records
A location and an enrolled child each hold a dedicated record, associated to the standard Contact and Deal objects rather than folded into either one, so a location's pipeline views and a child's history are each queryable on their own terms.
A child's record travels with a Campus and a Contact
Every Children record associates to its Campus and to the family's Contact, the same association other workflows on this account already pull from when they copy a ticket's Campus from its contact.
Duplicate Campus records from an earlier import removed
The duplicate Campus records created by an earlier CSV import were identified and removed, leaving the records the import had never touched.
Duplicate Children records from the same import removed
The duplicate Children records from the same import were removed, leaving the records that were already correct. That restored both objects to a state the running deal, ticket and view work could rely on.
Campus and Children were built as HubSpot custom objects rather than properties on Contact or Deal. A Children record associates to the family's Contact and to the Campus the child attends. A Campus record carries the pipeline views and tickets scoped to that location.
Contact, Deal and Ticket views and their permissions were built and adjusted continuously rather than set once at launch, with requests answered and logged daily across the engagement.
We isolated the rows created by an earlier CSV import. Duplicates were found in both the Campus and Children objects, and we removed them.
The Campus and Children records that were not part of the duplication remained in place, the base the running deal pipeline and ticket work relied on.
Contact and Deal alone had no place to hold a location or an enrolled child. Now "Campus" and "Children" are custom objects associated to Contact and Deal. A property on Contact can't carry its own pipeline views or tickets, which is why we used objects. An earlier CSV import had duplicated records in both objects, and removing the duplicates left the rest in place.
FAQ
We isolated the rows created by an earlier CSV import in each object and removed them, which left the Campus and Children records the import had not touched.
A property on Contact can't carry its own pipeline views or its own tickets. Campus and Children needed to stand as their own associated records so a location and a child could each be viewed and permissioned on its own terms.
