CONDITN. · Internal Operations Reference
Written for anyone who needs to understand or take over the setup without reading the code.
Everything starts in Mindbody and ends as either a message to a member or a number on a dashboard.
Every studio runs on Mindbody. That is where joins, trials, bookings, payments and attendance actually happen, and nothing we have built changes anything inside it.
Our system notices what happened in Mindbody and does two things with it. It flags the right people in GoHighLevel so the right automated email or text goes out, and it writes the activity into our own database so the dashboards can show what is going on across all the studios.
In between sits the engine room: small programs running on Amazon Web Services that watch Mindbody and pass what they find to the other two. Four platforms, one direction of travel.
The chain runs left to right. Each stage only ever hands off to the next one, which is why a problem can usually be traced to a single link.
Where the gym actually runs. One Mindbody site per studio.
Watches Mindbody and decides who deserves which message.
The database keeps the facts. GoHighLevel sends the messages.
What people actually see at the other end.
Traffic only ever flows this way. The dashboards read the database, they never write to it or send anything.
Everything hinges on a tag, which is just a label
stuck on a person's contact record in GoHighLevel, like
journey_trial_purchased. The engine's job is to work out who should
get which label and when. GoHighLevel's job is to watch for labels appearing and
start the matching sequence of emails and texts.
So when someone asks why a member got a particular email, the answer is always a tag: either it was added when it should not have been, or it was not added when it should have been. That is the first thing to check, every time.
There are two separate ways activity gets out of Mindbody. They run at the same time on purpose and they cover for each other.
Like a smoke alarm
webhooks → per-studio program
The moment something happens in Mindbody, it pings us. A small program for that studio picks it up and tags the person in GoHighLevel within a couple of seconds, day or night.
Like a guard doing rounds
conditn-v4 → every studio
Once an hour, roughly 8am to 9pm local time, we ask Mindbody what changed for each studio, pull it all down, write it to the database and tag whoever needs tagging.
The instant feed is fast but can miss things. The hourly check catches everything but is slower. Running both means a member normally hears from us in seconds, and if the fast path drops something the slow path picks it up within the hour.
They never send twice because both write to the same shared record before they act. Whichever one reaches an event first claims it, and the other sees the claim and stands down. That record is also how we can answer, after the fact, whether a given member was messaged and why.
Five platforms carry the whole thing. This is what each one is for and what would stop if it went away.
| Platform | What it does for us | If it stopped |
|---|---|---|
| Mindbody | Runs the gyms. The source of every fact about a member. One site per studio. | Everything stops. This is the source. |
| AWS | The engine room. Runs the instant feed and the hourly check, and holds the rules about who gets which message. | No new tags and no new data. Members stop being messaged, dashboards freeze at the last sync. |
| Supabase | Our own database. Every member, purchase, booking, class and attendance record, plus the log of every messaging decision. | Dashboards go blank and the engine cannot record what it has done. |
| GoHighLevel | The CRM. Holds contacts and actually sends the emails and texts. One sub-account per studio. | No member communication at all. Data keeps flowing, nothing gets sent. |
| Cloudflare | Hosts the dashboards and controls who can log in to them. | Dashboards unreachable. Messaging and data are unaffected. |
There are two main dashboards. The manager dashboard is per studio and is what a studio manager logs into. The HQ dashboard sits above it and rolls all the studios up. They read the same database, and the rule we hold ourselves to is that any number on HQ matches the same number on that studio's manager dashboard. Both are read-only.
| What | Account | Whose login | What lives in it |
|---|---|---|---|
| AWS | 480015207338Region ap-southeast-2 (Sydney) | Macca | The engine room. The hourly check, the instant-feed programs, the schedules that run them, the alerting. |
| Supabase | trcaxxdbfadpesjyubhcOne project, all studios | Macca | The database behind every dashboard, plus the log of every messaging decision and the end-of-day wraps. |
| Cloudflare, ours | 95559b8838c8fcf66ec671c6c26dd436 | Macca | Manager dashboard, HQ dashboard, the Week Zero trackers and the review sites. |
| Cloudflare, James's | a252a0fecd38135644040f4272451c9c | JamesMacca invited as a member | James's own tools: end-of-day wraps tracker, candidates, shift HQ, post-shift checkout, exec dashboard. |
| Dashboard logins | conditn.cloudflareaccess.comCloudflare Zero Trust, free tier | Macca | Controls who can open the dashboards. Access is by emailed one-time code against an approved list. |
| GoHighLevel | Agency accountMaster gp6aWeQHAu27Gi0e5XuL | CONDITN. | One sub-account per studio holding that studio's contacts and message journeys. The Master is where journeys are built before being copied out. |
| Mindbody | One site per studioPlus a developer account per studio for the connection | CONDITN. and franchisees | The gyms themselves. The developer accounts are only what lets our system read the data. |
| Code | GitHub rumacfit | MaccaDashboards repo shared with James | Three repositories: the engine code, the dashboards, and the planning and documentation workspace. |
| Alerts | Telegram group | Macca and James | Automated alerts: morning and evening reports, and a flag if anyone looks like they were missed. |
Checked live on 30 July 2026. Instant feed counts how many of the eight possible triggers are switched on. Lifecycle journeys counts how many of the ten standard July automations are live in that studio's CRM sub-account.
Every studio also runs the six Week Zero campaign workflows. Those are a campaign rather than part of the standard model, so they are not counted here. Camperdown runs the data and status side of the system but not the automated journeys, which is a settled franchisee position rather than a gap.
| Studio | Hourly check | Instant feed | Lifecycle journeys |
|---|---|---|---|
| Turramurra | On | 8 of 8 | 10 of 10 |
| Maroubra | On | 8 of 8 | 10 of 10 |
| Martin Place | On | 8 of 8 | 10 of 10 |
| Gladesville | On | 8 of 8 | 10 of 10 |
| Sutherland | On | 8 of 8 | 10 of 10 |
| Sans Souci | On | 8 of 8 | 10 of 10 |
| Hornsby | On | 8 of 8 | 10 of 10 |
| Noosa | On | 8 of 8 | 10 of 10 |
| Camperdown | On | 8 of 8 | Not used |
| Subiaco | On | 8 of 8 | 10 of 10 |
| Ingleburn | On | 8 of 8 | 10 of 10 |
| Randwick | On | 8 of 8 | 10 of 10 |
| Manly | On | 8 of 8 | 10 of 10 |
| Melbourne CBD | On | 8 of 8 | 10 of 10 |
| Sydney CBD | On | 8 of 8 | 10 of 10 |
| North Sydney | On | 8 of 8 | 10 of 10 |
| Brookvale | Shell | None | Not set up |
| Brunswick East | Off | Off | Turned off |
| Paddington | Not started | None | Not started |
The standard set that every fully live studio runs. Left is what the member did, right is what happens.
Before any message goes out, four checks run. Has this person already had this exact message, so we never repeat. Are they on the suppression list, which is how a campaign temporarily takes someone out of the standard automations. Is this studio switched on for sending. And is this an existing customer being treated like a new lead, which is the check that stops long-standing members getting welcome emails.
Comps, drop-ins and free products are deliberately excluded from the new member welcome. Someone on a free pass should not get an onboarding sequence written for a paying member.
Worth understanding properly, because it explains why we cannot simply drop one of them. They are not two versions of the same thing. They carry different information.
The instant feed only ever knows about the one event it was just told about. Mindbody says "this person was created" and that is the entire message. It is enough to recognise a moment and act on it, and it arrives in seconds.
The hourly check goes and looks. It asks for everything that changed, pulls down the full records, and works out what they mean together. That is slower, but it is the only way to get anything that requires context, history, or a part of Mindbody that never sends a ping in the first place.
Within seconds, 24 hours a day
Within the hour, 8am to 9pm local
The instant feed makes members hear from us quickly. The hourly check is what makes the dashboards true and the decisions correct. If the instant feed stopped everywhere tomorrow, everyone would still get every message, just up to an hour later. If the hourly check stopped, messages would keep going out for a while but the dashboards would freeze, product types would stop being classified properly and nothing would catch what the pings missed.
That is why the hourly check is the primary engine and the instant feed is the speed layer on top. It is also why the fix for a studio with no instant feed is never urgent, just worth doing.