Custom objects: how RealGreen data should live in HubSpot

If you want the short answer on how RealGreen data should live in HubSpot, here it is: as custom objects. A serious RealGreen HubSpot integration models your world the way RealGreen does, with properties, programs, visits, and invoices as their own records, each tied to the customer, instead of squashing all of it into a pile of contact properties. We build both kinds of setups, and we will be straight with you about the catch up front: custom objects are a HubSpot Enterprise feature. Lower tiers still get a genuinely useful integration through flattened properties, and we will cover exactly what that version can and cannot do. But if you are asking which HubSpot tier gets the most out of a RealGreen integration, the honest answer is Enterprise, and this post explains why.

What is a custom object, in plain English?

Out of the box, HubSpot knows about four kinds of records: contacts, companies, deals, and tickets. A custom object is a fifth kind you define yourself. Think of it as adding a new filing cabinet to the portal: a cabinet labeled Visits, where every drawer is one visit with its own date, round, technician, and condition codes, and every folder is clipped to the customer it belongs to. RealGreen already thinks this way. A customer in RealGreen is not a flat record; they are a person attached to a property, enrolled in programs, receiving visits, generating invoices. Custom objects let HubSpot hold that same shape: a Property object, a Program object, a Visit object, an Invoice object, each associated to the contact. Nothing about this is exotic. It is simply the difference between storing your data as a model and storing it as a summary.

What do you lose when you flatten everything onto contact properties?

The standard approach on Professional-tier portals, ours included, is flattening: years of RealGreen history collapse into answer-shaped fields like active programs, last visit date, current balance, and days past due. We wrote the full playbook for that approach in mapping RealGreen data into HubSpot, and we stand by it. But be clear about what the compression throws away.

• The one-to-many relationships. A property flag can say a customer has aeration. It cannot say which of their two properties has it, at what price, since which season. Multi-property customers become approximations.
• History. Last visit date overwrites itself every sync. The pattern across visits, such as three straight rounds with a weed pressure condition code, is exactly the kind of signal that sells a program, and a flat field cannot hold it.
• Detail you will want later. Once invoices are collapsed to a balance, you cannot ask HubSpot which program the unpaid amount belongs to, or how payment timing trends by neighborhood.
• Reporting depth. Flat properties support lists and workflows well. They support cross-record reporting badly, because the records are not there to report on.

What does the object model actually look like?

The design we use has four custom objects, all fed by the nightly sync and associated to the contact.

• Property: address, lot size, zone, branch. Contacts associate to one or more properties, which is how households with a lake house stop breaking your data.
• Program: one record per enrollment: program type, status, season, price, prepay flag. A customer with lawn care plus perimeter pest has two program records, not one mushy multi-select.
• Visit: date, round, service, technician, condition codes. This is the object that turns tech observations into marketing triggers, the machinery behind condition-code upselling.
• Invoice: amount, date, program, paid or open. Invoice records are what make revenue reporting and true lifetime value possible inside HubSpot rather than in a spreadsheet, the calculation we walk through in our LTV guide.

Keep the objects lean: sync the fields that answer questions, skip the rest, and let RealGreen remain the system of record. The objects are a mirror, never a second home for the truth.

What do custom objects unlock that properties cannot?

Three practical things. First, sharper lists: enrollment criteria can reach through associations, so you can build audiences like customers with an active lawn program at a property over half an acre and no aeration program at that same property. Second, smarter workflows: enrollment can key off object events, such as a new Visit record carrying a grub condition code, rather than a lossy summary field changing. Third, and biggest, real reporting: with Program and Invoice objects in the portal, revenue by program, by season, by branch, by original lead source becomes a HubSpot report instead of an export project. One worked example, illustrative as always, plug in your own numbers: a Visit-object list of households whose aeration invoices appeared last fall but not this fall surfaces 140 lapsed aeration customers; a two-touch reminder rebooks 15% at $330 a job, roughly $6,900 recovered from a report a flattened portal could not have produced.

Do you really need Enterprise for this?

For the full model, yes, and we would rather tell you plainly than have you discover it in a sales call: custom objects are gated to HubSpot's Enterprise tier. That is the single most important fact in this post. It means the question is not which CRM has the prettiest demo; it is whether the object model earns the tier for your business. Our honest take: multi-property books, commercial portfolios, multi-branch operations, and owners who want program-level revenue reporting inside HubSpot get clear value from Enterprise. A smaller residential shop can run happily for years on a Professional portal with flattened properties, working lists and workflows that cover most of the money. The flattened setup is a good car; the object model is the same car with instruments. And either way the plumbing is the same nightly sync: we can connect RealGreen to pretty much any platform out there that has an API, a Zapier connection, or a native connection, so the tier decision is about what HubSpot can hold, never about whether the data can get there. The sync mechanics live in our RealGreen integration if you want to see what flows.

The takeaway: RealGreen is relational, so the best HubSpot version of your data is relational too. Custom objects for properties, programs, visits, and invoices give you the model; Enterprise is the tier where that model lives; and a flattened Professional setup remains a legitimate, money-making middle step, as long as you choose it knowing what it leaves out.

Decide your data model this month

1. Count your complexity: multi-property customers, program count per household, branches. High counts argue for objects.
2. Write the five reports you wish you had. If most need program or invoice detail, the object model is doing real work for you.
3. Pick the tier deliberately: Enterprise for the full model, Professional with flattened properties as the deliberate middle step.
4. Design the four objects on one page each, lean fields only, before anyone builds anything.
5. Look at a live RealGreen object model before you commit; seeing visits and invoices attached to a real contact record settles the debate faster than any diagram.