Demonstrator / work sample
CourseSync: a Make.com automation from MindBody course purchases to HubSpot class lists and parent emails
A working Make.com build on invented data, with a walkthrough page and an importable blueprint. It is a work sample, not a customer project and not a product.
The problem
A business that sells multi-session courses wrote a specification for this automation. Parents buy a course in MindBody and then book the sessions themselves, often a few minutes later and not always in order.
The specification asked for an automation that then updates the student's contact in HubSpot, adds the student to the right class list, records the enrollment and prepares a confirmation for the parents. The class lists were named inconsistently, and several bookings from one purchase could each start the flow again.
The approach
- A purchase in MindBody starts the scenario through a webhook, because the MindBody connector for Make has no trigger for sales. The scenario checks the webhook's signature before it uses the data.
- It waits about ten minutes and then reads whether any session of the course is booked. It only reads from MindBody and never books or changes anything there. If nothing is booked yet, it emails the parents to ask for their dates and stops, and staff finish the booking by hand.
- Staff can tick a box on the contact to skip the wait and the booking check. The record updates still run.
- It picks the class list whose date range contains the booked session and whose name matches the course level and format (in person or remote). The list names follow no fixed pattern, so the parsing happens in a small piece of code outside Make that the scenario calls. If no list fits, or more than one does, the scenario emails the admin with the details and changes nothing.
- Before it writes anything, it checks whether the contact is already on that list. If so, an earlier booking from the same purchase has done the work and the run ends there.
- It then adds the course to the contact's course history without overwriting earlier courses, adds the contact to the class list, writes a row to a Google Sheet as a record outside both systems, and alerts staff when the course rules call for it. It only writes HubSpot properties with its own prefix and leaves every other field alone.
- The confirmation to the parents is built from a HubSpot template but goes to an admin as a draft. A person approves the wording before the family sees it.
-
The whole flow, with the three places where the scenario stops. Two of them hand the case to a person. -
Choosing the class list: only one list covers the booked date and matches the course level. -
The duplicate check: a student already on the class list means the purchase has been handled. -
The confirmation to the parents goes to an admin as a draft first.
What the demonstrator shows
A walkthrough page runs the whole flow on an invented student and shows what each step reads and writes. It comes with an importable Make blueprint, twenty modules across three routes, and a runbook that describes every module.
I imported the scenario into a live Make account and ran it there. The HubSpot updates, the list membership and the Sheet row were checked against real test accounts. The MindBody reads and the list matching ran against a mock of the MindBody API, and for the emails I checked that each path made the right decision about whether to send.
The first live run found two faults that a structural check of the blueprint had passed. Some hand-written HTTP modules failed at runtime, and Make evaluated one filter expression to an empty value, so the filter let everything through. I fixed both in the script that generates the blueprint and ran it again without errors.
I built it to that specification, on invented data and without access to the business's accounts.