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?