The busiest workflow in the portal had enrolled records 729,866 times. The second busiest had run 751,403 times. Both were HubSpot workflow re-enrollment loops; between them they accounted for more automation volume than everything else in the portal combined, and neither of them did anything a person would recognize as work. One copied a company’s name onto its contacts. The other stamped today’s date onto a deal. The portal held 4,873 contacts and 704 deals.
That is what most automation in a mature HubSpot portal looks like once you sort it by volume. It is not the nurture program or the renewal logic. It is HubSpot copying its own data from one record to another, over and over, because the record that needs the value cannot read it from the record that has it. We call it the property-copy treadmill, and in the portal we audited it was 23 of 90 live workflows. When the company moves to a CRM with real relations, none of the 23 are rebuilt. They stop being necessary, and the portal gets smaller by a quarter before anyone has written a line of new logic.
Why HubSpot copy-property workflows exist
HubSpot links records through associations: a contact belongs to a company, a deal is attached to both. The link is real. What it does not give you is the ability to filter a contact list by a property stored on the company, or to put a deal’s industry on a company report. Lists and standard reports read one object’s properties at a time. 1 Definition 1 Association: HubSpot’s link between two records, such as a contact and its company. The link exists, but a list, view or standard report filtering on contacts can read only the contact’s own properties. A value that lives on the company has to be copied down before a contact list can filter on it. A relation in a relational CRM is readable in both directions without the copy.
So the day a marketer wants a list of contacts at companies in a given state, someone builds a workflow: when a company’s region changes, write it onto every associated contact. The day sales wants deals filtered by industry, another one: copy the company’s industry onto the deal. The day someone needs to know when a lifecycle stage last moved, a third: stamp the date onto a property, because the stage field does not remember. Each workflow is sensible on the day it is built. None of them is business logic. They are the platform’s own plumbing, and they accrete for as long as the portal is in use.
In the portal we audited, the 23 broke down as eleven pure property syncs, four timestamp captures, four lifecycle propagations, three lead-status rollups and one odd one out that marked a customer as called once a meeting was booked. Every one of them wrote a value onto a second record so that a list or a report could see it. A company’s state copied to its contacts. A company’s industry copied to its deals. The contact owner copied to the company owner, and the company owner copied to the contact owner, in two separate workflows, both switched on.
Why do the biggest workflows do the least?
Volume is the tell. A workflow that does work runs about as often as the thing it responds to happens: a form fill, or a deal changing stage. A workflow that copies a property runs every time the property changes, and in HubSpot a copy is itself a change. If the enrollment criteria are written loosely, and they usually are, the copy satisfies its own trigger and the record re-enters. That is a re-enrollment loop, and it is why the two largest workflows in the portal had run 729,866 and 751,403 times in a portal with fewer than 5,000 contacts.
The company-name copy is the plainer case. It had enrolled records 729,866 times in its lifetime, 8,634 of them in the seven days before the audit. The portal held 8,634 companies. The week’s enrollments matched the company count exactly: the equivalent of every company in the portal, once, to write a name that had not changed onto contacts that already had it.
The deal date stamp is the stranger one. It had run 751,403 times, more than a thousand runs for every deal record the portal had ever held, and it carried no error flag of any kind. It ran cleanly. Every day it stamped today’s date onto the deals so that a report could subtract one date field from another and get a deal’s age, because the report builder on this portal’s tier cannot do relative-date math without a stored date to subtract from. Nothing downstream needed it.
The third loop is the one that touched attribution. A workflow copying HubSpot’s lead-source fields into a set of custom attribution fields had run 83,223 times, seventeen passes per contact. It was firing on its own output: the copy changed the custom field, the change re-enrolled the contact, the copy ran again. Original source is the one value a CRM should write once and never touch again, and this portal had a workflow re-copying it seventeen times per contact.
Not every high-volume workflow is a loop, and it matters to say so. The third largest in the portal, at 493,380 enrollments, managed HubSpot’s billable marketing-contact flag for unengaged contacts. A first reading dismissed it as pure HubSpot billing. On review it turned out to encode a real engagement-sunset rule, expressed as a billing flag because that was the only action the platform offered. It moves to the email platform. It is not treadmill. Sorting by volume finds the suspects; it does not convict them.
Every day it stamped today’s date onto the deals so that a report could subtract one date from another. Nothing downstream needed it.
The treadmill is where the errors live
HubSpot’s own health view flagged 17 workflows in this portal with active issues, 12 of them switched on, and reported 22 enabled workflows that had logged an execution error at some point since 2021. Read without context, that looks like an automation estate falling apart. Read against the inventory, most of it is the treadmill thrashing.
Seven enabled workflows had errored in the 30 days before the audit. Four of them were property-copy loops, and the reason they were erroring is the reason they had run hundreds of thousands of times: a loop that re-enrolls every record on every write will eventually write a value HubSpot rejects, or hit a property that no longer exists, or collide with its own sibling copying in the other direction. 2 Editor's note 2 The four erroring copy loops, by lifetime enrollments: the company-name-to-contact copy (729,866), the company-to-contact owner sync (62,055), the company-insights copy (40,991) and the contact-owner-to-company copy (2,785). The remaining three were the two nurture sequences and an engineer-count copy. The deal date stamp, at 751,403, carried no error flag. The 729,866-enrollment workflow carried both of HubSpot’s error flags, active issues and execution error, and had last errored on the day of the audit. The 83,223-enrollment attribution loop carried an execution-error flag too.
The two erroring workflows that mattered were not loops. They were the company’s welcome and nurture sequences, the only email nurturing it had, and they were failing on a portal whose business case for leaving was that inbound had dried up. That is the practical cost of the treadmill: it fills the workflow errors view with noise, and the two rows that needed attention were sitting between four that did not. An errors badge nobody reads is how a portal decays quietly, and the treadmill is what makes the badge unreadable.
Where the 90 workflows went
After classification and review, the 90 live workflows landed as follows.
| Disposition | Count | Share |
|---|---|---|
| Collapses into the data model | 23 | 26% |
| Real CRM logic, rebuilt | 18 | 20% |
| Dead: disabled, never enabled or superseded | 15 | 17% |
| Moves to the email platform | 14 | 16% |
| Needs a decision from the company | 9 | 10% |
| Moves to website code | 7 | 8% |
| Replaced by an ads integration | 4 | 4% |
Forty-two percent of the estate disappears on migration: the 23 that collapse and the 15 that are dead. The rest carries forward, and only 18 of the 90, one in five, are real CRM logic: deal-stage automation for both pipelines, closed-won and closed-lost handling, renewal deal creation, the education-domain and international disqualification rules, target-account promotion and churn lifecycle. That is the company’s actual revenue process. The work to rebuild it is modest. A migration scoped from the workflows page would have quoted all 70 switched-on workflows, and would have rebuilt the loops along with the logic.
Why the 23 are not rebuilt
The honest answer is architectural, and it is the one that applies to any relational CRM, not to a particular product.
In a CRM with real relations, a contact view can filter on the company’s lead status by reading through the relation. The value lives once, on the company, and is visible where it is needed. There is no copy, so there is no workflow, so there is no loop and no error. The disqualification rule in this portal is the clearest example. One HubSpot workflow, at 29,871 enrollments, wrote a disqualification reason onto a company’s lead status and then onto every contact at the company, so that contact lists could exclude them. In the new design the company half is rebuilt as one rule. The contact half is not rebuilt at all. Contact views filter through the company relation, and 29,871 enrollments of plumbing go to zero.
The attribution loop goes the same way, for a different reason. Attribution in the new architecture is written once, server-side, at the moment of form submission. First-touch fields are set on create and are absent from every later update. There is no trigger, so there is nothing to re-enter. The workflow that had run 83,223 times is replaced by the absence of a workflow.
One caveat belongs here, because a CTO will ask. Relations solve the reading problem for views and reports, which is what most of the 23 served. They do not make automation free. In the replacement CRM’s own automation engine, a rule’s filter evaluates the triggering record only; reading a related record’s value inside a rule is an explicit lookup step, and the engine runs one trigger per workflow with no retry. The design rule that follows is that a CRM workflow may trigger, branch on one record and write one simple field, and anything with arithmetic, cross-object branching or an outbound message lives in a small piece of code in the website repository. That is where the “five pieces of code” come from. The treadmill is the bulk of Lock 3, the Logic Lock. 3 See also 3 See The Five Locks, Lock 3, the Logic Lock: business rules encoded in a platform’s configuration rather than in a form you can carry out of it. The treadmill is the Logic Lock’s bulk, and most of that bulk is not logic.Read The Five Locks: How SaaS Vendors Keep You Trapped
The number was argued, not asserted
A figure like “42 percent of your automation can be deleted” is worth nothing if it came from one read of a spreadsheet. This one was produced twice.
The adversarial pass made the number more conservative, not less. An uncertain drop is a worse error than an uncertain keep.
An independent first pass classified every workflow against the raw export and proposed 27 deletions. An adversarial review then challenged each proposed drop, one by one, against the same export. It overturned 12 of the 27. All seven workflows the first pass had dismissed as “only HubSpot billing” were among them: each turned out to encode a real suppression, engagement-sunset or geographic rule, with the billing flag merely the only action HubSpot gave anyone to express it. Two workflows that had been classified twice with conflicting answers were both resolved toward keeping the logic. One of them wrote to a custom object nobody had mentioned in discovery and was erroring, and the review’s position was that you cannot retire something whose consumer you cannot name.
The adversarial pass made the number more conservative, not less. The pre-review split was 54 percent gone. The post-review split is 42 percent. The grounds were stated plainly in the working notes: continuity of operations had been promised to this company, so an uncertain drop is a worse error than an uncertain keep. Every overturned record keeps its original call alongside the final one, and confidence on the 90 individual dispositions breaks down as 50 high, 34 medium and 6 low, with the assumption stated on any row that rests on one.
That is the part of this work another agency cannot copy from the workflows page. The count is defensible because it was contested, and because the contest is written down.
What the company gains
The away-from case is easy to state: the four erroring loops are gone, and so are the two workflows that had run 729,866 and 751,403 times to no purpose. The toward case is the one that changes how the company operates.
The marketer’s stated worry about leaving HubSpot was losing the ability to see a list of all her workflows. What she gets instead is a list short enough to read. The signed scope rebuilds the revenue process as six CRM workflows and five website handlers, covering closed-won and closed-lost, renewal creation, disqualification and demo interest. Seventy switched-on workflows become eleven things, and the five that are code have a history: every rule is a reviewed diff, with an author and a reason, and a change to it can be rolled back. A HubSpot workflow has none of that. It has whoever last touched it.
Some of the rebuilt rules come out better than they went in. In the new design the renewal opportunity is created the moment the original deal closes, with a future close date, so it is in the forecast the day the deal is won. Consent, which HubSpot had expressed as a billable marketing-contact flag set by a form fill, becomes an explicit, timestamped, sourced record, which is what makes a re-permissioning program defensible. Attribution is written once and cannot drift.
And the data model itself becomes an asset rather than a maintenance burden. When a value lives in one place and is read through relations, a new report is a view, not a workflow. A new segment does not need a copy built first. The operations team stops spending its time keeping the portal consistent with itself and starts spending it on the rules that move revenue. That is the capability a relational data model buys, and it is why the migration is smaller than the workflows page says. 4 See also 4 See The Integration Tax, on the hidden cost of glue between systems. A property-copy workflow is glue inside one system, and it is priced the same way: in operations nobody counts until they fail.Read The Integration Tax: HubSpot's Best Defense is a False Narrative
How to find your own treadmill
You do not need an exit planned to do this. You need the complete workflow inventory, which is not the workflows page, and an afternoon.
Sort every workflow by lifetime enrollments and put the portal’s record counts beside the list. Any workflow whose enrollments exceed the number of records it acts on has run more than once per record, and if its only action is to write a property, it is a loop. In the portal we audited that test alone surfaced the three largest workflows and the four most persistent errors.
Then read the enrollment criteria of each copy workflow against its action. If the action changes a property the criteria watch, the workflow is feeding itself. Fix the criteria if you are staying. Mark it as “collapses into the data model” if you are leaving, because in a CRM with relations it has no equivalent and needs none.
Do the same for the errors view, and separate the loops from the rules. The rows that matter are the ones that are not loops. In this portal, two of seven.
If you want to know how large the gap between the workflows page and the inventory can be, the five workflows that were seventy is the piece to read next: the same portal, scoped from a screen-share at six workflows, with 70 switched on. And if you have decided to leave, the rules in the treadmill are not the ones you need to extract before the contract ends. What dies with the portal lists the ones that are.
The research is free. So is the diagnosis. 60 seconds →