How we added live cohort tracking to a HubSpot Professional portal, with no custom object, no double-counted revenue and no change to the school sales process
Summary
Key results: every student cohort now has a live record showing its schools, students, capacity, seats remaining, fill percentage and status, while school deal revenue stays untouched and nothing is counted twice.
How: a required Deal Type property splits the standard deal object into School Deals and Cohort Deals, backed by calculated cohort properties, conditional record views, Deal Type filters on existing workflows and reports, and a repeatable process for operations. No custom objects and no HubSpot upgrade.
What if one CRM record had to represent a batch of students from five different schools, with no custom object, no duplicated revenue and no disruption to the sales process already running?
That was the question an education-sector client brought to us. Their sales team already closed school deals with accurate, automatic deal amounts. Now operations needed a different view: the cohort, one batch of students drawn from several schools, with live seat counts and a clear status. This is how our HubSpot consulting team built it on top of the existing HubSpot setup.
The client runs a school outreach programme. Each school signs up for one or more courses, and the students at that school opt into them. Every school deal already calculated its own amount: the fee for each course multiplied by the number of students who opted into it, added up across courses.
The new requirement was to create cohort deals by hand. Each cohort deal had to link every school feeding the batch and every paid student who opted for that course, without touching school deal revenue. The client was on Sales Hub and Marketing Hub Professional, so custom objects were not available.
Amwhiz delivered a cohort deal design inside the existing deal object: a Deal Type property, a set of cohort properties and calculations, conditional record views, guardrails on the existing workflows, and a repeatable manual process for the operations team.
Figure 1. One deal object, two jobs: school deals carry the money, the cohort deal carries the batch (demo data).
Before this work, the client faced five problems:
Example: where double-counting would come from
Demo Student 01 opted into Program A through Demo School A. Their fee is already part of School A's deal amount. If the cohort deal also calculated fees for its 12 students, Student 01's fee would appear in revenue twice: once under the school and once under the cohort.
Model the cohort as a second type of deal inside the standard deal object, and keep all the money on the school deals. We did it in seven steps.
We created a Deal Type dropdown on the deal with two values, School Deal and Cohort Deal. It is required when a deal is created. All existing deals were bulk-updated to School Deal, and the workflow that creates a school deal now sets School Deal automatically.
Figure 2. The Deal Type property and what each value controls.
The operations team creates each cohort deal by hand:
| Property | Type | Demo value |
|---|---|---|
| Cohort Name | Text | Demo Program A - Cohort 07 |
| Cohort Course | Dropdown | Program A |
| Cohort Code | Text | PRG-A-007 |
| Cohort Start Date | Date | 5 Jul 2027 |
| Cohort End Date | Date | 14 Jul 2027 |
| Cohort Capacity | Number (default 35) | 35 |
| Cohort School Count | Calculated | 3 |
| Cohort Registered Student Count | Calculated | 12 |
| Cohort Seats Remaining | Calculated | 23 |
| Cohort Fill Percentage | Calculated | 34% |
| Cohort Status | Dropdown | Filling |
Cohort Capacity is a number property that defaults to 35 and can be edited for each cohort. Cohort School Count counts the schools associated with the deal, and Cohort Registered Student Count counts the students associated with it. Cohort Seats Remaining is the capacity minus the registered student count, and Cohort Fill Percentage is the registered student count divided by the capacity. The four calculated properties update on their own, so the team only types the name, course, code and dates, and changes the capacity only when a cohort differs from the default.
Example: how the numbers work out
Demo Program A - Cohort 07 has a capacity of 35. With 12 students associated, Seats Remaining shows 35 − 12 = 23 and Fill Percentage shows 12 ÷ 35 = 34%. Associate a 13th student and both update immediately, with no one recalculating anything.
The team associates the three to five schools that feed the cohort, and Cohort School Count updates automatically. Associating a school does not change the Programs Offered field on the cohort deal, which is the behaviour the client wanted: a school's own program selections stay on its school deal.
For each course, we built an active list with two conditions: the contact opted for that course (alone or with other courses), and payment is confirmed. The list has no school filter, which is what lets a cohort span schools.
The team then adds the list's contacts to the cohort deal by importing them with the deal's record ID. As an option, a workflow using the Create association action can match a Cohort Code on the contact to the Cohort Code on the deal. Once students are associated, Registered Student Count, Seats Remaining and Fill Percentage update immediately.
Figure 3. A cohort deal record with the Cohort Program section, feeder schools and their owners, and paid students (demo data).
The Cohort pipeline follows the life of the batch:
| Pipeline stage | Meaning |
|---|---|
| Open | Cohort created and accepting schools and students |
| Filling | Students are registering and seats remain |
| Full | Capacity reached, no more students added |
| At risk | Start date is close and registrations are low |
| Started | Cohort is running |
Figure 4. The five stages of the Cohort pipeline.
To show who owns the schools behind a cohort, the Schools card on the cohort deal displays each school's owner and updates by itself. For filtering and reporting we added a multiple-checkbox property, Cohort School Owners, filled by a deal workflow. The workflow clears the property, then runs one branch per sales owner. Each branch checks whether any associated school belongs to that owner and, if so, adds the owner's name.
Example: owners behind a cohort
Demo Schools A and C belong to Demo Owner 1, and Demo School B belongs to Demo Owner 2. The workflow writes "Demo Owner 1; Demo Owner 2" to Cohort School Owners, so leadership can filter every cohort that Demo Owner 2's schools feed into, without opening a single school record.
Using conditional sections in the deal record layout, the Cohort Program section appears only when Deal Type is Cohort Deal. Programs Offered, program count, fee and Total Deal Amount fields appear only when Deal Type is School Deal. Sales staff never see cohort fields on a school deal, and operations never see fee fields on a cohort deal.
| Workflow or report | Change |
|---|---|
| School deal creation | Sets Deal Type to School Deal, and ignores existing cohort deals when checking whether the school already has a deal |
| Update Deal Amount | Runs only for Deal Type = School Deal |
| Contact-to-deal association | Targets the school deal only |
| Company-level total of deal amounts | Counts School Deals only |
| Revenue and closed-won reports | Filtered to School Deal |
Guardrails like these are the core of good CRM architecture and governance: a new use of an object should never quietly change what existing automation does.
| Challenge | How Amwhiz addressed it |
|---|---|
| Custom objects were not available on the client's plan | Modelled the cohort as a deal type inside the existing deal object, separated by the Deal Type property |
| A cohort spans several schools, while a school deal is built around one school | Linked several schools to the cohort deal and associated students directly. The money stays on the school deals. |
| Program count fields on a cohort deal showed every course a student had opted for, not only the cohort's course | Hid the program section on cohort deals and relied on the cohort registered count |
| Automation could treat a cohort deal as a school deal | Added Deal Type filters and tested the case where a school already linked to a cohort deal later needs its own school deal. The school still gets its own school deal. |
| Capacity had to work as a benchmark rather than a hard limit, because cohorts can run above or below it | Added a Cohort Capacity property with a default benchmark the team can edit per cohort. Seats Remaining and Fill Percentage show the gap, and counts above the benchmark remain valid. |
| Before | After |
|---|---|
| No way to represent a batch drawn from several schools | Cohort deal with feeder schools and students linked |
| Batch information spread across school records | Registered count, seats remaining and fill percentage calculate automatically |
| One deal type, with automation assuming every deal is a school deal | Deal Type separates the two, and workflows and reports filter on it |
| Risk of counting the same students' fees twice | Fees stay on school deals. Cohort deals carry no amount. |
| Owners of feeder schools looked up school by school | Owners visible on the deal and filterable through a property |
| Cluttered deal screen | Each deal type shows only its relevant fields |
Figure 5. A cohort fill report, one row per cohort, filtered to Deal Type = Cohort Deal (demo data).
Yes. Add a required Deal Type property so the standard deal object holds both school deals and cohort deals, then give cohort deals their own properties, pipeline and record view. This works on Sales Hub and Marketing Hub Professional.
Keep all fees on the school deals and leave Amount and fee fields blank on cohort deals. Amount workflows, company totals and revenue reports are filtered to Deal Type = School Deal.
Yes. Several schools are associated to the cohort deal, and students are added from an active list filtered on course and confirmed payment, with no school filter.
Seats Remaining is Cohort Capacity minus Registered Student Count, and Fill Percentage is Registered Student Count divided by Cohort Capacity. Both update as soon as students are associated.
No. Capacity is an editable benchmark that defaults to 35. Cohorts can run above or below it, and the counts stay valid.
The Schools card on the cohort deal shows each school's owner, and a workflow fills a multiple-checkbox Cohort School Owners property for filtering and reports.
No. School deals are created and priced exactly as before. Workflows were only given Deal Type filters so they ignore cohort deals.
Custom objects are not always the answer, or even an option. With the right property design, record views and workflow guardrails, one HubSpot object can serve two teams without either getting in the other's way.
Talk to our HubSpot consultants about modelling your own process inside the plan you already have, or contact Amwhiz to scope it. You can also browse more Amwhiz case studies.
All names and figures in this case study are demo data. No client name, school name, student detail or real screenshot is used.