Nobody manages your HubSpot: what decays, what expires, and how to hand it over

Nobody owning your HubSpot is a state, not a gap

An unowned portal is rarely an unused one. Everyone uses HubSpot a little: sales works the deal board, marketing sends the campaigns, and somebody in operations built a workflow once before moving on to other things. Every individual piece has a user. The portal as a whole has nobody.

The tell is not that HubSpot is broken. It is that small problems sit there for months: a deal stage that stopped matching how you sell, a form writing into a property nobody can explain, a report that quietly stopped being true. Each one is a ten minute fix, and each one survives, because ten minutes of somebody’s job is exactly what nobody has been given.

That state has a recognisable shape. Requests get raised in a chat thread and dealt with whenever somebody has a spare afternoon. Nobody can say which workflows are live. The licence renews on the same date every year, unreviewed since the day it was bought. None of that is negligence. It is what happens when a system is everybody’s tool and nobody’s responsibility.

Every HubSpot safety net has a clock on it

This is worth reading before anything else here, because it is what catches people out. HubSpot gives you real ways to undo damage. All of them expire, and the clock starts when the damage happens, not when you notice it.

The restore tool rolls records back to a previous point within the last 14 days. It undoes updates made by workflows, imports or manual edits, across contacts, companies, deals, tickets, calls, products, leads, marketing events, orders, tasks and custom objects. It is genuinely powerful and genuinely short: a bad import on the first of the month is fully reversible on the tenth and gone completely by the sixteenth.

Deleted records get longer. HubSpot holds them in the recycle bin for 90 days, filterable by date, user or workflow. Permanent and privacy related deletions are the exception: they are never held in the recycle bin at all, so there is nothing to restore from the moment they happen.

In a portal with an owner, none of this matters much, because someone notices a bad import the same week. In a portal without one, the pattern repeats: a workflow starts writing the wrong value in April, somebody spots the odd looking report in June, and by then the restore window closed seven weeks earlier. The only route back is rebuilding the data by hand from whatever export happens to still exist.

There is one more catch worth knowing before you need it. The restore tool requires Super Admin permissions, not edit rights and not admin of a single hub. If the person who held Super Admin has left, the undo button exists and nobody remaining can press it.

What decays first in an unmanaged portal

Portals do not fall over. They drift, and they drift in a fairly predictable order.

Deal stages go first, because they are the easiest thing to change and the hardest thing to change back. A stage gets added for one unusual deal and stays. Two stages come to mean the same thing to two different reps. Within a year the board no longer describes how you sell, so the forecast built on it stops describing anything either.

Workflows go next, and they decay in a way most teams get wrong. Turning a workflow off stops new records enrolling and stops its actions executing. It does not hold the records already inside it where they are: those records keep moving through the workflow, and pausing them at a specific step needs pause dates instead. So the sentence we turned that one off describes less than most people think, and it matters a great deal on the day someone turns it back on.

Duplicates build the whole time, quietly and by default. HubSpot compares record property values daily and surfaces the pairs it thinks are the same person or company. For contacts it matches on first name, last name, email address, IP country, phone number, zip code and company name. For companies it uses domain name, company name, country, phone number and industry. The tool does the finding; somebody still has to open it and decide, and in an unowned portal nobody does, so the pairs accumulate for as long as the portal has existed.

That tool also has a subscription floor worth knowing before you plan around it. Reviewing individual duplicates needs Professional or Enterprise. Handling them in bulk needs Data Hub Professional or Enterprise, which caps at 5,000 duplicate pairs on Professional and 10,000 on Enterprise.

Properties are the slowest decay and the worst. Every form, integration and well meant experiment leaves one behind. Nobody deletes them, because nobody is certain what would break. After a few years the property list is the archaeology of everyone who ever touched the portal, and choosing the right field to report on becomes a research task rather than an obvious one.

The person who left still has Super Admin

Access decays differently from data, because HubSpot has started making decisions about it on your behalf.

HubSpot can automatically deactivate users who have been inactive for more than 90 days, and that setting is switched on by default. At the start of each month it identifies who qualifies. Super Admins get an email on the first weekday, a reminder two weeks later that also goes to the users themselves, and a final warning the day before. On the last weekday of the month, anyone still inactive and not exempted is deactivated.

Read that as three emails sent to a Super Admin who may no longer work at your company, about seats nobody has reviewed. In a managed portal it is useful hygiene, and a Super Admin exempts the people who only log in occasionally. In an unmanaged one it is an automation quietly making access decisions with nobody reading the notice, which is a strange way to run the system holding your customer data.

The other half of the problem does not resolve itself. Someone who leaves keeps their access until a person removes it. Their integrations keep running under their name, and their workflows keep sending. The 90 day automation catches the dormant account eventually. It does nothing about the API key they set up, or the connected inbox still quietly syncing, or the fact that the only Super Admin login left may now be an address nobody reads.

Who should own HubSpot, and what the job actually is

The answer is one named person, not a committee and not a hub. Shared ownership of a CRM produces the state described above, every time.

The job is smaller than most people assume, which is why it keeps failing to get assigned. It is not building. It is holding Super Admin and knowing that is a responsibility. It is opening the duplicates tool once a month rather than once a year. It is checking every quarter that the deal stages still describe how the team sells. It is knowing which workflows are on. Above all, it is being the person allowed to say no to a new property.

Done properly that is a few hours a month, not a role. The problem is rarely the hours. It is that the work needs someone who knows the portal deeply enough to make those calls, and the people who know it best usually have the least room in their week.

Which leaves three honest options: give it to someone internal and give them the time to do it, not just the title; bring in someone from outside to hold it; or leave it, and accept the drift as a running cost, which is a legitimate choice as long as it is made deliberately rather than by default.

What a HubSpot handover actually involves

Handing a portal over is mostly a documentation problem. Somebody has to work out what is actually in there before anybody can be responsible for it, whether the new owner is internal or external.

It starts with a conversation: twenty minutes on what is going wrong and what you want out of HubSpot. That one is free, and you can stop after it. Plenty of people do, because sometimes the answer is an afternoon of someone’s help rather than an ongoing arrangement.

If it goes further, the next step is a paid audit of the portal: going through what is there and writing it down. Which workflows are on and what they touch. Which properties are genuinely in use and which are leftovers. Whether the pipelines and stages still match how you sell now, and what the integrations are actually doing. Who holds Super Admin, and the state of the data underneath all of it.

What comes back is a plain list: what is broken, what is missing, and what is worth doing first. That list is useful on its own. Taken to an internal hire or another consultancy, it still does its job, which is the point of writing it down rather than keeping it in somebody’s head.

Then you agree what gets picked up and the work starts: builds and automation where needed, the tidy up of whatever the last few years left behind, and someone to tell when something breaks. Everything stays in your portal and in your account. You own what gets built and can take it with you, which is the only arrangement that makes sense for a system you will depend on for years. That is what a systems audit is for.

Common questions