Nobody owning your HubSpot is a state, not a gap
An unowned portal is rarely an unused one. Everyone uses HubSpot a bit. Sales works the deal board, marketing sends the campaigns, someone in operations built a workflow once and has since moved onto other things. Every individual piece has a user. The thing 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 shape you can recognise. Requests get raised in a chat thread and dealt with when someone has a spare afternoon. Nobody can tell you which workflows are on. The licence renews on the same date every year and nobody has looked at what you are paying for 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 the part that catches people out, and it is worth reading before anything else on this page. 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 it is genuinely short. A bad import on the first of the month is fully reversible on the tenth and completely gone 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: those 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 is always the same. A workflow starts writing the wrong value in April. Somebody spots the odd looking report in June. By then the restore window closed seven weeks earlier, and the only route back is rebuilding the data by hand from whatever export you happen to still have.
There is one more catch worth knowing before you need it. The restore tool requires Super Admin permissions. Not edit rights, 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. What it does not do is 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 the person saying it usually thinks, 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 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.
- No new records enrol
- No actions execute on records still inside it
- It does not hold enrolled records at their current step
- Those records keep moving through the workflow
- Holding them at a step needs pause dates instead
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 a sequence of three emails to a Super Admin who may no longer work at your company, about seats nobody has reviewed. In a managed portal it is a useful bit of 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 same problem is the half that does not resolve itself. Someone who leaves keeps their access until a person removes it. Their integrations keep running under their name. 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. It does nothing about the only Super Admin login now being an address nobody reads.
- 1Start of the monthHubSpot identifies users who have been inactive for more than 90 days.
- 2First weekdaySuper Admins are emailed the list of users scheduled for deactivation.
- 3Two weeks laterA reminder goes to Super Admins and to the inactive users themselves.
- 4The day beforeA final warning email goes out to everyone involved.
- 5Last weekdayAnyone still inactive and not exempted is deactivated.
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 at the top of this page, 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 who is 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 are usually the ones with 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, and that is true 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, and plenty of people do, because sometimes the answer is that you need one afternoon of someone's help rather than an arrangement.
If it goes further, the next step is a paid audit of the portal. That means going through what is there and writing it down. Which workflows are on and what they touch. Which properties are in real 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. If you take it 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 they are 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 you can take it with you, which is the only arrangement that makes sense for a system you are going to depend on for years.
- 1A free consultTwenty minutes on what is going wrong and what you want out of HubSpot. You can stop after it.
- 2A paid audit of the portalWorkflows, properties, pipelines, integrations, permissions and the data underneath, gone through and written down.
- 3A plain list backWhat is broken, what is missing and what is worth doing first. Useful even if you take it elsewhere.
- 4The work startsYou agree what gets picked up. Everything stays in your portal, in your account, and you keep it.
Related.
Talk it through
If this maps to something you are wrestling with in your own portal, book a free thirty-minute consult and we will tell you where to start.
Book a free consultCommon questions.
Who should own HubSpot in a small business?
One named person, not a committee. The role is not full time. It is holding Super Admin, reviewing duplicates monthly, and knowing which workflows are on. It is checking quarterly that deal stages still match how the team sells. Above all, it is being the person allowed to refuse a new property. A few hours a month done consistently prevents almost everything described on this page. Shared ownership across sales, marketing and operations reliably produces a portal nobody is responsible for.
What happens to a HubSpot portal when the person who set it up leaves?
Nothing automatic, which is the problem. Their access, integrations and workflows keep running until a person removes them. HubSpot can automatically deactivate users inactive for more than 90 days, and that setting is on by default, but it only catches the dormant login. It does nothing about API keys, connected inboxes or the fact that Super Admin notifications may now be going to an address nobody reads. Reassigning Super Admin is the first thing to do, not the last.
Can you undo changes in HubSpot?
Within a limited window. The restore tool rolls records back to a previous point in the last 14 days, undoing changes made by workflows, imports or manual edits across contacts, companies, deals, tickets and most other objects. Deleted records sit in the recycle bin for 90 days. Permanent and privacy related deletions are never held there at all. Restoring CRM changes requires Super Admin permissions, so check who holds that before you need it.
Can someone else manage our HubSpot for us?
Yes, and it is a common arrangement for teams without anyone internal who has the time or the depth. It usually sits alongside an existing marketing or sales team rather than replacing anyone: they keep doing their jobs, and the portal itself becomes somebody's actual responsibility. What matters is that the work lives in your account and stays documented, so you are never dependent on the arrangement continuing.
What does a HubSpot portal audit look at?
Which workflows are on and what they touch. Which properties are genuinely in use versus left over. Whether pipelines and stages still match how you sell, and what the integrations are doing. Who holds Super Admin, and what the wider permission setup looks like. Finally, the state of the underlying data, including duplicates. The output should be a plain list of what is broken, what is missing and what is worth doing first, in an order you can act on.
What happens to the work if we stop working with an outside team?
Everything built in your portal should stay in your portal, in your account, under your ownership. Workflows, properties, pipelines, reports and documentation are all yours to keep and to hand to whoever comes next. Ask that question before any engagement starts rather than at the end of one, and be wary of any arrangement where the answer involves work living somewhere you cannot reach.