Sometime around the end of July, a workflow you built two years ago is going to stop working, and nothing in HubSpot will tell you. No error, no failed-action notification, no red banner. The HubSpot recorded meetings call record change quietly rewrites how logged conversations enter your CRM, and every automation, list, and report that keys off the call object for those meetings simply stops matching. If your team runs SDR-to-AE handoffs, activity-based lead scoring, or a Salesforce activity sync off recorded calls, this is the kind of change that breaks forecasting for a month before anyone traces it back to the source.
Here is the practical version of what is happening and, more importantly, the specific work to do before the deadline so you cross it with nothing broken.
What actually changes
Today, when a meeting is recorded through HubSpot Notetaker or a connected video conferencing integration (Zoom, Microsoft Teams, or Google Meet), HubSpot creates two records for that single conversation: a meeting record and a call record. Transcripts, recordings, and summaries have been attaching to the call record, which is why so many teams built their reporting and automation on the call object.
After the cutover, a recorded meeting creates only a meeting record. Transcripts, recordings, summaries, and duration all live on the meeting. The stated goal is to end the duplication so one conversation produces one CRM record instead of two. Call objects still exist for genuine phone-call activity, and your historical call records are not deleted or altered. This change touches recorded meetings only.
One caution on timing. HubSpot has communicated a July 31, 2026 cutover, and its own knowledge base has at points listed a date as early as July 10, 2026. Treat the exact day as something to confirm inside your own portal notifications rather than a fixed fact, and plan to be ready by the earlier date. HubSpot has said new meeting property data begins populating in early July and historical meeting data is backfilled by the end of the month, so you can build and test against real data before the switch.
Where the silent gap opens
The reason this matters is that the call object quietly became load-bearing for a lot of RevOps infrastructure. Walk your own portal and you will likely find the change touches four areas at once:
- Workflows triggered by call creation. Any enrollment trigger set to "Call is created," or any workflow filtering on call properties, will stop firing for recorded meetings. Think post-call task creation, deal-stage nudges, rep notifications, and follow-up sequences.
- Reporting and dashboards. Activity reports and dashboards that count or filter on the call or engagement object will show a drop in volume. That drop is deduplication working as intended, not a performance problem, but it will look alarming in August if nobody rebuilt the views first.
- Rep scorecards and activity metrics. If you measure rep activity partly on logged calls, recorded meetings will quietly fall out of the count, and the comparison to prior periods breaks.
- Downstream syncs. Salesforce activity sync, BI warehouse pipelines, and any integration reading the call object for meeting data will miss recorded meetings going forward.
The common thread: none of these throw an error. They just return fewer results than they used to, which is the hardest kind of failure to notice.
The audit: inventory before you rebuild
Do not start rebuilding blindly. Spend an hour building a map first, because most portals have a mix of automations that genuinely mean phone calls and automations that only ever cared about recorded meetings. You only need to migrate the second group.
Work through this inventory:
- List every workflow with a "Call is created" trigger or a filter on call properties. For each, decide: is this meant for real phone calls, or for recorded meetings? Flag the meeting ones for migration and leave the phone-call ones alone.
- List every active list and report that filters on the call or engagement object. Flag any that were counting recorded meetings.
- List every integration and sync that reads call records, especially Salesforce activity sync and any warehouse export. Note which ones need to point at the meeting object.
- Note where your team currently opens recordings and transcripts. After the change, those live on the meeting index, not the call index.
The output is a short list of exactly what has to move. That list is your migration scope, and it is almost always smaller than teams fear.
The rewire: move automations onto the meeting object
For each flagged item, the fix is to recreate it against meeting data instead of call data. HubSpot has added meeting properties to support this, including whether a transcript exists, a transcript identifier, and meeting duration, so the triggers and filters you relied on have equivalents.
The core moves:
- Switch triggers from "Call is created" to a meeting-based trigger such as "Meeting is logged." To build meeting-triggered workflows you may need to opt into HubSpot's Meetings in Workflows beta, so check that first.
- Switch filters from call properties to the new meeting properties (has transcript, transcript ID, duration) so your enrollment logic behaves the same way.
- Repoint reports and dashboards to the meeting object, then validate the activity counts against a known period so you can explain the expected volume drop before your leadership sees it.
- Reconfigure downstream syncs to read meeting records for recorded meetings, and test the Salesforce or warehouse side end to end, not just the HubSpot trigger.
Because HubSpot backfills historical meeting data before the cutover, build these in parallel now and test them against real records rather than waiting for the switch and hoping they fire.
What this looks like in practice
Consider a mid-market building-materials manufacturer running Sales Hub. Two things ran off recorded-call records without anyone thinking about it. First, an SDR-to-AE handoff workflow enrolled on "Call is created" with a transcript present, then created a task for the AE and moved the deal to a discovery stage. Second, a nightly Salesforce activity sync pushed those call records into the AE's Salesforce view for pipeline reviews.
Left alone, both would have gone dark after the cutover. The SDR calls would still record and transcribe, but the handoff task would never generate, and deals would sit in the wrong stage. The Salesforce sync would show a sudden gap in activity that a sales manager could easily misread as reps slacking off.
The fix took a focused couple of weeks: rebuild the handoff workflow on "Meeting is logged" with a has-transcript filter inside the beta, repoint the activity sync to the meeting object, and rebuild the pipeline-review dashboard on meeting data. Because the historical meeting data was already backfilled, the team tested the new handoff against last month's real meetings and confirmed the deal-stage automation fired correctly before flipping off the old call-based version.
Your pre-deadline checklist
The HubSpot recorded meetings call record change is not complicated, but it is unforgiving of teams that wait. Here is the sequence to run before the end of July, in order:
- This week: Confirm the exact cutover date in your portal, and inventory every call-triggered workflow, call-based report, and integration that reads the call object.
- Next: Separate the phone-call automations (leave alone) from the recorded-meeting automations (migrate).
- Then: Opt into the Meetings in Workflows beta and rebuild the flagged workflows, reports, and syncs on meeting data using the new meeting properties.
- Before the deadline: Test each rebuilt automation against backfilled historical meetings, then retire the old call-based versions.
- Communicate: Tell your sales managers the call-activity count will drop after the cutover and that it is deduplication, not a performance dip.
If you do one thing on Monday morning, open your workflow list, filter to anything triggered by "Call is created," and tag each one as either "real calls" or "recorded meetings." That single pass turns a vague, scary deadline into a concrete, finite to-do list, and it is the difference between a quiet cutover and a month of debugging silent failures in live pipeline.