Data Model & WordPress Integration
How we model our training courses in HubSpot, how we connect HubSpot to our website, and one design decision we want you to sanity-check.
Why we're hereThree things to validate
The model
Does our object structure for cohort-based courses make sense — and is the native Courses object the right home for it?
Linking by association
We connect records only through associations — avoiding copying data between them. Is that the right call?
WordPress integration
Our course-creation flow drives the website (events + tickets) from HubSpot. Is the approach sound?
The modelOne Course at the center
A Course = one cohort: a dated, located class (TFM, HCS, MToP…). Everything else hangs off it.
- Contacts — the attendees
- Deals — the orders / buyers
- Companies — districts & institutional buyers
- Products & Line Items — the tickets & revenue
- Sessions — for multi-day courses (e.g. MToP)
HubSpot is the source of truth. The website reflects it.
cohort_codeOur biggest question for youAssociations vs. “stamping” — are we right?
Question 1. We link a contact to a course by associating them to the Course record — not by copying the course details onto the contact. Is that the right call?
Our approach today
One association per relationship. The data lives once, on the Course — always current, never duplicated onto contacts or deals.
Question 2 — if the need arises
If we do need course data on a contact (e.g. an email token), is the right move an automatic workflow that re-stamps on every change — so the copied value triggers on any update and can never go stale?
HubSpot's guidance favors associations over duplicated properties — so we think we're right. The open question is the escape hatch: when a stamp is unavoidable, are workflow-maintained stamps that refresh on any change the pattern you'd use?
WordPress integrationHubSpot authors, the website reflects
Down: Course → Website
Create the Course in HubSpot → the event page, dates, venue, and tickets appear on hue.life. No one hand-builds events anymore.
Back: Registration → HubSpot
Someone registers → they come back as a Contact associated to that Course, with the order as a Deal. The link closes the loop.
WordPress integrationEstablished plugins + one custom bridge
Off-the-shelf plugins
- The Events Calendar — the public event pages & calendar
- Event Tickets Plus — turns each tier into a sellable ticket
- WooCommerce — checkout, payment & orders
- MakeWebBetter — the established WooCommerce↔HubSpot sync; brings orders, contacts & line items back into HubSpot
HueLife Course Sync
The one piece we built — a thin bridge.
- Reads the HubSpot Course → builds & updates the event + tickets
- After MakeWebBetter syncs an order, it adds the association linking the attendee to the Course
Off-the-shelf for events, ticketing, checkout & the HubSpot sync — plus a thin custom bridge so HubSpot stays the single source of truth. Is that the right division of labor — and is MakeWebBetter the sync you'd use?
The course-creation processFrom one HubSpot record to a live, sellable event
wp_readythe go-live switchOrange = HubSpot owns it · purple = the website. One record in, a live sellable event out.
The fields built to make this workA handful of Course fields drive the website
| Field | What it drives on the website |
|---|---|
cohort_code | The unique class ID — ties the event, tickets & orders together |
class_template | Which content template the event page is built from |
has_tiers | Whether to build 4 tier tickets or a single ticket |
session_start / end, venue_* | Event date, time & location |
wp_ready | The go-live switch — nothing builds until it's on |
external_event_id | Written back by the plugin — the link to the live WP event |
event_url | Written back too — the public link to the live event page on hue.life |
These exist specifically to serve the integration. Everything else about a cohort is either a normal Course field or lives on the association. Are we missing anything — or carrying fields we shouldn't?
A field-hygiene question for youWhere did 615 contact properties come from?
Only about a third are ours by hand. The rest are HubSpot defaults and one integration's auto-installed bundle.
| Source | Fields |
|---|---|
| HubSpot defaults (every portal ships these) | 407 |
| MakeWebBetter e-commerce bundle — auto-installed | 102 |
| Team — course / email project | 53 |
| Forms & campaigns, 2024–26 (registration, scholarship, a book push) | ~50 |
The flag
Half of our 208 custom fields are MakeWebBetter's auto-installed e-commerce set — abandoned cart, RFM, ROI tracking, products-bought.
A sample showed ~80% completely empty — they power cart-recovery & RFM features we don't run.
Question: keep the full bundle, or trim it back?
What we'd love your read onThe questions that matter to us
1 · The Courses object. Right home for a cohort on Professional — or would you model it differently?
2 · Associations, exclusively. Are we right to link everything by association and refuse to duplicate data onto records?
3 · The integration split. Off-the-shelf plugins for events/tickets/checkout + MakeWebBetter for the WooCommerce↔HubSpot sync + a thin custom bridge, HubSpot as source of truth — sound architecture, and the right sync plugin?
4 · The fields. Is our small set of website-driving Course fields the right set — too many, too few, or named wrong?