Mapping RealGreen data into HubSpot: the fields that matter

Which RealGreen fields belong in HubSpot? On the Professional-tier portals most companies run, the right mapping puts about a dozen RealGreen facts onto the contact record as custom properties, uses deals only for open sales motions, and deliberately leaves the majority of your RealGreen database out of HubSpot entirely. (On Enterprise, custom objects change the picture, and we cover that below.) The leaving-out part surprises people. A sync is not a migration: HubSpot does not need your invoice line items, your route assignments, or your chemical tracking. It needs answers: is this an active customer, what do they buy, what do they owe, how did they arrive. This post is the practical mapping, with naming conventions that will save your future admin, and the shortlist of things you should refuse to sync. It assumes you already understand the nightly-sync architecture underneath, which we covered in how the RealGreen-HubSpot integration works.

The principle: sync answers, not tables

RealGreen stores transactions; marketing needs states. The transform layer between the two systems should collapse history into current truth. Forty invoices become two properties: current balance and days past due. Six years of visits become last visit date and visit count. A program purchase history becomes a simple multi-select of active programs. Every property you add should pass one test: will a list, workflow, or report filter on this? If nothing filters on it, it is clutter, and clutter has a real cost: office staff stop trusting the contact record the day it takes scrolling to find the field they need.

Which RealGreen facts become contact properties?

The working set, prefixed so everyone knows the sync owns them:

• rg_customer_status: active, inactive, canceled, prospect. The single most-used field in the portal.
• rg_programs: multi-select of active programs. Powers every cross-sell list you will ever build.
• rg_balance and rg_days_past_due: the suppression pair. No upsell should ever reach someone you are dunning.
• rg_last_visit_date and rg_visit_count: recency and tenure at a glance.
• rg_source_code: how they originally arrived, feeding closed-loop reporting.
• rg_cancel_date and rg_cancel_reason: what win-back timing and messaging key off.
• rg_prepay_status: who prepaid this season, for renewal-campaign gating.
• rg_ltv: lifetime revenue, computed in the transform layer. How to calculate it honestly from RealGreen data is its own topic: see our LTV guide.

Notice what this list is not: it is not the customer's full financial history, and it contains nothing the office would consider sensitive beyond a balance figure.

When do companies and deals earn their place?

Companies matter for commercial work: an HOA or property-management account with multiple contacts, sites, and a decision-maker hierarchy maps naturally to a HubSpot company with associated contacts. For residential households, skip company records entirely; a husband and wife sharing an address are handled better by careful contact matching in the sync than by a fake company called "The Hendersons." Deals are for open motions with a beginning and an end: a quote being chased, a commercial bid in flight, a renewal in its window. Do not create a deal for every synced historical sale; a customer with nine years of programs does not need 27 closed-won deals polluting your pipeline math. The rule: RealGreen history lives in properties; HubSpot deals exist only while a human or workflow is actively trying to close something.

What about custom objects?

This is where the tier question gets real, and we will give it to you straight. Custom objects, real records for properties, programs, visits, and invoices, each associated to the contact, are an Enterprise feature, and they are the difference between a summary of your RealGreen data and a model of it. Flattened properties can tell you a customer has aeration; objects can tell you which property, which season, on what visit cadence, against which invoice. If you run multi-property customers, a commercial portfolio, or you want program-level revenue reporting inside HubSpot, Enterprise is how you get the most out of a RealGreen integration. On Professional, the mapping in this post is the plan: collapse history into properties and deals, and accept the known limits with your eyes open. Either tier rides the same pipeline underneath, which is the larger point about this whole exercise: we can connect RealGreen to pretty much anything with an API, a Zapier connection, or a native connection, so the mapping decisions travel with you.

Naming conventions that save you later

Three habits. Prefix every synced property with rg_ so nobody edits by hand what the sync will overwrite at 2 a.m.; mark them read-only in HubSpot if your tier allows it. Keep property labels boring and literal: "RG: Days past due," not "Payment health." And maintain a one-page data dictionary: property name, source field in RealGreen, refresh cadence, owner. That page turns every future debugging session from an archaeology dig into a lookup. Groups matter too: put all synced properties in one property group so the contact record shows RealGreen truth in a single block the office can read top to bottom.

What should you refuse to sync?

• Payment card data or bank details: never. No marketing system needs them, and carrying them expands your compliance surface for zero benefit.
• Invoice line items and pricing detail: summary fields answer every marketing question; detail invites misuse.
• Tech notes verbatim: condition codes are structured and useful; free-text notes were written for the office, not for merge fields, and syncing them into a marketing tool is how something embarrassing lands in an email.
• Every historical prospect: a 40,000-row graveyard of decade-old leads inflates your database and, if flagged marketable, your marketing-contact count. Sync prospects with activity in the last 24 months and archive the rest.
• Fields nobody can define: if the office cannot say what a RealGreen field means, it does not get a seat in HubSpot until they can. Dirty inputs are a data-cleanup problem to fix at the source, per our database cleanup guide, not something to launder through a sync.

The takeaway: a good RealGreen-to-HubSpot mapping is small, boring, and opinionated. A dozen prefixed properties that answer real questions, deals only for live pursuits, custom objects almost never, and a written dictionary. Every field you decline to sync is future confusion you declined to buy.

Map it this month

1. List every question your lists, workflows, and reports need answered; derive the property list from the questions, not from RealGreen's schema.
2. Write the data dictionary page before the first property is created.
3. Prefix, group, and lock the synced properties so hand edits cannot fight the sync.
4. Define the deal policy in one sentence: which motions create deals, and who closes them.
5. Review the mapping with the person who will run your RealGreen data pipeline; the transform layer is where most of these decisions actually live.