GoHighLevel Custom Objects: When and How to Use Them (2026 Guide)
Last updated: September 2026.
GoHighLevel custom objects solve a problem every agency hits eventually: the client's business does not fit inside a contact record. A plumbing company has jobs. A real estate agency has properties. An insurance broker has policies. Flattening those into job_1_date, job_2_date custom fields works for about three weeks and then becomes unmaintainable.
Some links below are affiliate links — if you sign up through them, Pivot 2 Thrive may earn a commission at no extra cost to you. It never changes what we recommend. Full disclosure.
On This Page
Dr Priya Jaganathan is a Go High Level Certified Admin, Certified AI Tech Stack Consultant and keynote speaker. Pivot 2 Thrive has migrated field-service and trades data into GoHighLevel custom objects at scale, including full ServiceM8 migrations where jobs, companies and job contacts all needed to remain navigable from any record.
What GoHighLevel Custom Objects Actually Are
A custom object is a record type you define yourself. Contacts and opportunities are built into HighLevel; a custom object lets you add "Job", "Property", "Vehicle", "Policy" or "Enrolment" as a first-class record with its own fields, its own records and its own detail view.
The important part is associations. A custom object record can be linked to a contact — and to other objects — with a labelled relationship. Open a contact and you see their five jobs. Open a job and you see the company it belongs to and the site contact attached to it. Navigation works in every direction.
That is the functional difference from custom fields. A custom field describes the contact. A custom object is a separate thing that relates to the contact, and can exist in any number.
Why Custom Fields Stop Working
Almost every agency tries custom fields first, because it is faster. The pattern looks reasonable: create last_job_date, last_job_value, last_job_type and update them on each new job.
It breaks in four predictable ways. You can only hold one job's worth of data, so history is lost. You cannot report on jobs as a set. Workflows cannot iterate over them. And the moment the client asks "show me every property we listed in Brisbane last quarter", the data simply is not in a shape that can answer the question.
The tell is when you start numbering fields. The first time you create job_2_date, stop — you have a one-to-many relationship and you need an object, not more columns.
The Limits You Need to Know Before You Build
These constraints decide whether custom objects will work for a given client, and they are the thing most agencies discover too late. Figures below are from HighLevel's support documentation as at September 2026.
| Constraint | Limit | What it means in practice |
|---|---|---|
| Custom objects per sub-account | 10 | Plenty for most builds — plan them rather than creating objects ad hoc |
| Custom fields per object | 10 unique fields | The real constraint. Be ruthless about which attributes matter |
| Linked records per association label | 1,000 per side | Fine per contact; a problem if you link everything to one parent record |
| Unique labels between two objects | 10 | Enough to model most relationship types |
| Plan availability | All plans since October 2025 | No longer a reason to upgrade a client's plan |
The 1,000-record association cap is the one that bites. If you model "all jobs belong to one company record" for a client with 4,000 historical jobs, you will hit the ceiling on that label. Reporting on custom objects is also less mature than contact reporting, so if a client's core dashboard depends on object-level analytics, test that before you promise it.
How to Set Custom Objects Up Properly
1. Model on paper before you touch the platform. Write the nouns in the client's business and draw the lines between them. Contact, Company, Job, Site. A migration that gets this wrong costs days to unwind because associations have to be rebuilt record by record.
2. Create the object and its fields before importing anything. Fields cannot be retrofitted onto records that have already been created without a second pass. With only 10 fields available, decide up front which attributes are genuinely needed versus which are nice to see.
3. Define association labels explicitly. Name them from the perspective of both records — "Jobs" from the contact side, "Customer" from the job side. Vague labels make the record view unreadable within a few months.
4. Import parents first, then children, then associations. Companies before jobs, jobs before job contacts. Keep the source system's ID in a field on every record so you can de-duplicate and re-run a failed import without creating a second copy of everything.
5. Build workflows against the object, not around it. Custom object record changes can trigger workflows. That is where the value compounds — a job moving to "Complete" firing a review request beats any manual process. If you have not built the foundational ones yet, start with the five GoHighLevel workflows every agency should build first.
6. Test the client's three hardest questions. Before handover, try to answer the three reporting questions the client asks most. If the data model cannot answer them, fix the model now rather than after they have 5,000 records in it.
If you are staring at a client migration and are not sure whether their data belongs in objects, opportunities or fields, book a CRM architecture call — we will map the object model with you before anything gets imported.
Not on HighLevel yet? Start with a free 30-day trial — enough time to build everything in this guide before you pay a cent.
An Australian Agency Example
A Melbourne agency inherited a plumbing client running on ServiceM8 with about 2,800 historical jobs across 900 customers. The brief was simple to state and hard to deliver: open any contact and see their job history; open any job and see the company and the site contact.
The first attempt used custom fields and lasted a week. Job history could not be held, and the client's first question — "which customers have had two or more callbacks?" — was unanswerable.
The rebuild used three custom objects: Company, Job and Site Contact, with labelled associations in both directions. Because the source system's IDs were carried into a field on every record, the import could be re-run safely after the first pass failed partway through — no duplicate records, no manual reconciliation. Total rebuild time was under three days, most of it spent on the data model rather than the import.
The payoff was not the tidy record view. It was that completed jobs could now trigger review requests and 12-month service reminders automatically, which turned a migration project into an ongoing retainer. That is the pattern worth noticing: object modelling is the thing that makes the automation possible.
Common Mistakes With Custom Objects
Using an object where an opportunity would do. If the record moves through stages and represents potential revenue, it is an opportunity. Custom objects are for things that exist regardless of sales stage — a property, a vehicle, a policy.
Ignoring the 10-field cap until import day. Agencies design a 22-field object, build the import, and discover the ceiling at the worst possible moment. Count the fields first.
Creating objects per client without a standard. If every sub-account has a differently shaped "Job" object, nothing is reusable and nothing can be snapshotted cleanly. Standardise the model across a niche — that is what makes snapshot-based delivery actually productised.
Importing without carrying a source ID. Without it, a partial failure means you cannot tell what already imported. This is the single most expensive mistake in any CRM migration and it is trivial to avoid.
Promising object-level dashboards you have not tested. Reporting on custom objects is less developed than contact and opportunity reporting. Scope it honestly — and if you find yourself quietly absorbing the rebuild when it falls short, read how scope creep destroys agency margin.
Frequently Asked Questions
What is a custom object in GoHighLevel?
A custom object is a user-defined record type that sits alongside contacts and opportunities in a sub-account. It has its own fields, its own records and its own detail view, and can be associated with contacts or other objects using labelled relationships so you can navigate between related records.
How many custom objects can a GoHighLevel sub-account have?
Up to 10 custom objects per sub-account, with up to 10 unique custom fields on each object. Custom objects have been available across all plans, including Starter, since October 2025.
What is the association limit for custom objects?
Each association label supports up to 1,000 linked records per side, and you can define up to 10 unique labels between any two objects. The 1,000-record cap matters most when many child records are linked to a single parent record.
When should I use a custom object instead of a custom field?
Use a custom object whenever a contact can have more than one of something — multiple jobs, properties, vehicles or policies. Custom fields describe a single attribute of the contact. The moment you find yourself numbering fields, you need an object.
Can workflows trigger from custom object records?
Yes. Changes to custom object records can trigger workflows, which is where most of the value sits. A job record moving to a completed status can fire a review request, a service reminder or an internal task without anyone touching it.
Are custom objects included in snapshots?
Object definitions can be carried between sub-accounts as part of your standard build, but records themselves are account data and are imported separately. Standardising the object model across a niche is what makes snapshot-based delivery repeatable.
Is GoHighLevel suitable for very large datasets?
Not for hundreds of thousands of records. Custom objects work well for the scale of a typical small to mid-size Australian service business. Beyond that, the association and reporting limits mean a purpose-built database is a better fit.
Getting the data model right is the difference between a CRM a client uses and one they work around. If you want that architecture mapped before you migrate, book a call with Pivot 2 Thrive or see the rest of what we build at pivot2thrive.com.au.
Related Articles
Our services
More on building in GoHighLevel
- 5 GoHighLevel Workflows Every AI Agency Should Build First
- HubSpot to GoHighLevel Migration Checklist for Australian Agencies
- GoHighLevel Snapshots Explained: Productise Your Agency Delivery
- AI Agency Scope Creep: How to Stop It Killing Your Margins
- AI Automation for Australian Financial Planners
Everything else
