Skip to main content

Command Palette

Search for a command to run...

How QBS Governs HubSpot Workflows At Scale

Updated
11 min readView as Markdown
How QBS Governs HubSpot Workflows At Scale
C
Founder of Howly.io - I help HubSpot Admins and Agencies move from manual spreadsheets to automated workflow mapping. Building the visibility layer for the modern RevOps stack.

How QBS Governs HubSpot Workflows At Scale

Key Takeaways

  • QBS is a mission-driven organization focused on behavioral de-escalation and crisis management training across K-12 education, ABA-centric organizations, and hospitals.

  • Daniel Semenuk previously managed HubSpot across six or seven client portals at once, some carrying seven to eight hundred active workflows, before moving in-house as Marketing Manager at QBS.

  • Portals that pass through multiple consultants or agencies accumulate workflow debt: automations nobody documented, and nobody can safely audit without a dependency map.

  • Permission sets alone create single points of failure. A visual dependency map lets a team extend workflow-building access without losing oversight.

  • Connecting Howly is one of the first steps Daniel takes in any new portal, a practice that carried over directly from his consulting work to his role at QBS.


https://www.youtube.com/watch?v=FazmeUBQ3Us


From six portals to one

Daniel spent years working across client HubSpot portals in an agency and freelance capacity, in industries ranging from finance and insurance to legal and manufacturing. At any given time, he was managing six or seven instances. Some of those portals carried seven to eight hundred active workflows.

The audit work was constant, and it was repetitive in a specific way. Each new portal meant re-learning a system somebody else had built, usually without documentation, usually under a different set of assumptions than the client currently had. Daniel said he found himself sitting with the problem directly: staring at a messy workflow environment and wondering how to build something that could show him the whole system at a high level, fast.

That search led him to Howly, which he found through a LinkedIn post. When he made the move to an internal role at QBS, the habit stuck. Turning on Howly when he walks into a new portal is not a step he added for this job. It is a step he brought with him.


Why QBS, and why the internal move

QBS has been operating for about 30 years, focused on behavioral de-escalation and crisis management across vulnerable populations, including K-12 education systems, ABA-centric organizations, and hospitals. The organization's approach is grounded in clinical validation rather than reactive intervention: training people to make sound judgment calls before a crisis happens, not handing them a pamphlet after one starts.

Daniel described the move to QBS as a deliberate choice. He wanted a mission-forward organization, but one mature enough to support bringing go-to-market engineering, RevOps, and marketing automation in-house rather than continuing to outsource it. Owning HubSpot end to end, for one organization, is a different kind of responsibility than rotating through client portals. It means being internally accountable for a system that a lot of different people depend on for a lot of different functions.

That shift changes the clock. An outside consultant or agency is typically given room. Clients expect an audit period, some strategic meetings, a ramp before results show up. An internal hire does not get that runway. Daniel was direct about this: you do not get 90 days to analyze a portal internally. You need to know where to act on day one, and you need wins that read as strategic, not just a tally of tickets closed.


Workflow debt, and where the term comes from

During the conversation, Christian introduced the term workflow archaeology to describe a specific kind of problem: coming into a portal that has passed through multiple consultants or agencies, each of whom built workflows to solve an immediate need without documenting how those workflows connect to what already existed. Daniel responded to the term immediately, saying it captured something he recognized from his own consulting work: taking on a portal from a previous freelancer or agency, and inheriting technical debt that kept multiplying because the underlying problems never got fixed, only reassigned.

Christian offered a concrete version of what that looks like in practice: a workflow still actively running in 2026, built back in 2021 for a webinar the company no longer promotes. Nobody remembers it exists. It is still firing. Finding something like that in the first 30 minutes in a new portal is an immediate, visible win, because it identifies exactly what can be archived and what it touches on the way out.

Daniel drew a clear line between this and the more familiar problem of data hygiene. Duplicate contacts are visible. Three records with the same name and a similar email address is a problem anyone can see and understand instantly. Workflow debt does not work that way. It sits behind the interface. Four hundred workflows firing for reasons nobody can trace look, on any given day, like a problem for tomorrow, not today. The debt is real, but it does not announce itself the way duplicate data does.

The distinction matters because it explains why workflow debt survives so long in a portal. Nobody triages a problem they cannot see. This is the same reason workflow sprawl tends to go unaddressed long after a portal has outgrown what any one person can hold in their head.


Governance without gridlock

The conversation turned to how portals stay clean once they are clean, and Daniel connected this directly to HubSpot's Breeze Assistant and the increasing ease of workflow creation. If nearly anyone on a team can spin up a workflow, some form of governance becomes necessary, not optional.

Daniel was clear that permission sets are not the problem. They are a requirement, particularly for anyone new to a portal who could otherwise make a change without realizing its effect. But permission sets used as the only layer of governance create a different failure mode: a single point of failure, or a small handful of people who are the only ones authorized to touch workflows. When one of them goes on vacation, or leaves, the organization is stuck waiting on a bottleneck it built for itself.

A visual dependency map changes this calculus. Instead of locking down who can create workflows, a portal owner can see what has been built and how it connects, which makes it possible to extend a longer leash to more team members without losing oversight. Governance stops depending entirely on restriction and starts depending on visibility. That same visibility is what a full workflow audit is built to surface before a portal grows past the point where any single person can track every connection.


Evaluating who solves this for you

Daniel also spoke to the evaluation problem organizations face before they hire, whether that hire is a freelancer, an agency, or an internal role. Every candidate pitches. Every candidate sounds credible. The organization still has to make a choice, usually without a reliable way to compare outcomes ahead of time.

A visual workflow map changes what that evaluation looks like. An organization that already has a picture of its own workflow connections, built independently, can hand that map to whoever they are vetting and ask a much sharper question than "how would you approach this." Daniel's point was that this shortens the distance to actually getting value, because the person being hired is not starting from zero, and the organization is not relying entirely on a pitch to make its decision.

The same logic applies to the tools consultants and agencies already use. Daniel noted that a Lucidchart or Miro map is common practice, but it is static. It does not update as the portal changes, and it misses context that only shows up when the mapping reflects what is actually enrolled and connected inside HubSpot, not what someone remembers from the last review.


Speed to impact

Daniel returned more than once to a single idea: speed to impact is what every stakeholder actually wants, whether that stakeholder is evaluating a new hire's first 90 days or an agency's first engagement. Nobody wants to wait 30 days for a comprehensive audit before seeing a single actionable item. The alternative he described is knowing, within minutes, what the top priorities are and where the actual bottlenecks sit.

For Daniel, that is what changed between his consulting work and his role at QBS. The tool did not change. What changed is that the speed it enables now serves one portal, one team, and one clear owner, instead of resetting with every new client engagement.


Summary

Daniel Semenuk moved from managing HubSpot across six or seven client portals to owning a single instance as Marketing Manager at QBS. The shift changed the timeline he had to work with, but not the first move he made: mapping the portal before making any changes to it.

Three things stand out from the conversation:

  • Workflow debt hides in plain sight. Unlike duplicate data, a portal full of undocumented workflow connections does not look urgent until someone maps it.

  • Governance works better as visibility, not just restriction. Permission sets prevent damage, but a dependency map lets a team extend trust without losing oversight.

  • Speed to impact is the real evaluation criteria, whether the person being evaluated is a new hire, a freelancer, or an agency.

If your portal has been through more than one pair of hands, connect it to Howly and see the full dependency map before you decide what to touch next. The trial is seven days, no credit card required.


Frequently Asked Questions

What is workflow debt in HubSpot? Workflow debt is what accumulates in a HubSpot portal after it passes through multiple consultants, freelancers, or agencies, each of whom builds workflows to solve an immediate problem without documenting how those workflows connect to everything already in the portal. Over time, this leaves a portal with automations that are difficult to audit safely because nobody has a complete record of what depends on what.

What is workflow archaeology? Workflow archaeology describes the process of digging through an undocumented HubSpot portal to figure out what a given workflow does, what it connects to, and whether it is safe to change or remove. It is a slower, more careful version of a standard audit, made necessary by the absence of documentation from whoever built the portal originally.

How is workflow debt different from data hygiene problems like duplicate contacts? Duplicate contacts are immediately visible. Anyone looking at a list of records can spot two entries with the same name and know something is wrong. Workflow debt is not visible the same way. It sits behind the interface, in enrollment logic and property dependencies that do not show up unless someone maps them, which is why it tends to get deprioritized in favor of problems that are easier to see.

How quickly can a new hire or consultant find quick wins in an unfamiliar HubSpot portal? With a dependency map available immediately, a new portal owner can identify orphaned or outdated workflows, such as an automation still running years after the campaign it supported ended, within the first 30 to 60 minutes in the portal. Without a map, the same discovery typically requires a manual audit that can take weeks.

Why does workflow governance matter more as HubSpot's AI tools make workflow creation easier? As tools like HubSpot's Breeze Assistant make it easier for more people to build workflows without deep technical knowledge, portals are more likely to accumulate automations that nobody who owns the system directly reviewed. Visual governance, seeing what has been built and how it connects, gives a portal owner a way to extend workflow-building access to more of the team without losing the ability to catch problems before they compound.

Is Howly read-only, and will it change anything in a live HubSpot portal? Yes, Howly is read-only. It connects to a HubSpot portal through OAuth and maps existing workflow connections without the ability to write, edit, or change anything inside the portal. It is available as a featured app on the HubSpot Marketplace.


Howly is a read-only HubSpot workflow mapping and audit tool. It maps workflow connections, flags structural issues, and shows the impact of property changes before you make them. Used by RevOps teams and HubSpot agencies managing complex portals at scale.

5 views

More from this blog

H

Howly Blog | HubSpot Workflow Audits & Automation Guides

38 posts

Practical tips and video guides for HubSpot power users. We share how to map your workflows, fix broken automations, and keep your portal clean.