Alexandre Pericão When an automation stops working in HubSpot or Zoho CRM, the problem is not always the platform itself. In many cases, the technical failure is only the most visible symptom of an earlier issue: poorly defined processes, inconsistent data, incorrect enrolment criteria, fragile integrations, excessive automation or unclear responsibilities between Marketing, Sales and IT.
This is why recovering a CRM or Marketing Automation implementation should not begin by rebuilding workflows.
It should begin by understanding what failed, what impact it had on the business and whether the existing configuration still reflects the process the company actually wants to run.
HubSpot and Zoho CRM both provide mechanisms to identify automation failures. In HubSpot, for example, administrators can review automation issues and analyse errors at workflow and record level. Current documentation identifies errors related to connected applications, webhooks, custom code, usage limits and other conditions that may prevent or delay actions from being executed. Some of these errors are automatically retried by the system.
Zoho CRM follows a similar logic. Workflow reports allow administrators to analyse successful and failed actions, including the reason for the failure and the record involved. After the issue has been corrected, certain actions can be executed again. Failed functions are also available for analysis and, in some scenarios, can be retried by an administrator.
However, correcting the error displayed by the system does not necessarily mean correcting the implementation.
If an automation is technically correct but executes a badly designed commercial process, the technology is simply automating the problem.
See why Marketing Automation can fail even in platforms such as HubSpot or Zoho CRM
Why does Marketing Automation fail even with tools such as HubSpot or Zoho CRM?
Marketing and Sales automation usually fails for six main reasons: unclear processes, poor data quality, incorrect automation criteria, fragile integrations, excessive complexity and lack of governance.
Software rarely compensates for these problems on its own.
A company may, for example, build a workflow to automatically assign new leads to salespeople. At first glance, the process looks simple. A lead enters the CRM, the system identifies the territory, selects the salesperson and creates a task.
But incomplete postcodes, companies without defined territories, inactive owners or undocumented commercial exceptions are enough for the workflow to start producing inconsistent results.
The problem may look technical, but its origin is operational.
In Zoho CRM, the troubleshooting documentation includes examples where workflows are executed for the wrong records because logical conditions were built incorrectly. It also identifies function failures caused by missing values, usage limits or errors in the implemented logic.
In HubSpot, failures may result from connected applications reaching usage limits, webhooks taking too long to respond, custom code failures, competing record updates or limits associated with certain AI actions.
But there is another category of problems that does not necessarily generate an obvious error.
The workflow executes exactly what was configured, but what was configured is wrong.
This distinction is what makes an automation audit different from a simple technical review.
How can you tell whether the problem is in the automation or in the process?
The first question should be: if this automation were carried out manually by a person, would the process make sense?
If the answer is no, there is little value in starting with the CRM.
Imagine a process where every person who submits a form automatically enters a commercial sequence. If Marketing and Sales have never defined what constitutes a commercially relevant lead, the problem is not the workflow. The problem is the absence of qualification criteria.
The same happens when a deal automatically changes stage, duplicate tasks are created, emails are sent at inappropriate moments or the system assigns contacts to the wrong people.
An audit should separate three levels:
Process: what should happen in the business?
Configuration: how was that process translated into HubSpot or Zoho?
Execution: is the platform actually executing the intended configuration?
This distinction avoids a common mistake: changing dozens of workflows when the real problem is the definition of the process itself.
Step 1. Stop adding new automations
When an implementation begins to fail, there is often an instinctive reaction: create more automation to correct the automation that already exists.
That is usually the wrong approach.
One workflow does not work, so another is created. A field is incorrect, so an additional rule is added. An integration does not update information as expected, so a function is introduced. A few weeks later, nobody can explain with confidence why a particular record changed status.
The first stage of recovery should limit unnecessary changes.
The goal is to stabilise the system, identify critical workflows and understand the existing dependencies.
This does not mean disabling all automation. Some automation may be essential for commercial operations, notifications, lead distribution or customer service.
It means stopping the growth of complexity before understanding what already exists.
Step 2. Map every critical automation
Before correcting anything, the company needs an inventory.
In HubSpot or Zoho CRM, the organisation should be able to answer questions such as:
Which workflows are active?
Which objects or modules do they change?
Which criteria enrol a record?
Which actions do they execute?
Which fields do they modify?
Which emails do they send?
Which other workflows can be triggered by the same changes?
Which external applications are called?
Which custom functions are involved?
Who owns the business process?
This inventory is particularly important when the account has been configured over several years or by different people.
In Zoho CRM, the order of automation is also relevant. Different mechanisms such as assignment rules, scoring, workflows, approvals and Blueprint can interact with each other.
For that reason, analysing one workflow in isolation may not be enough.
The same field can be involved in several automations and integrations.
Step 3. Analyse errors and execution history
Once the critical processes have been mapped, the next step is to analyse what the system actually executed.
In HubSpot, the workflow area can be used to identify automations with issues and inspect error details. It is important to distinguish between problems in workflow configuration and problems associated with the enrolled records themselves.
In Zoho CRM, the Workflow Usage Report provides information about successful and failed actions, making it possible to analyse the reason for each failure and, after correction, rerun certain actions.
When custom functions exist in Zoho, failed execution areas and logs should also be reviewed. Missing values, code errors, execution limits and problems with external APIs can interrupt processing.
This analysis should answer two different questions.
The first is technical: was the action executed successfully?
The second is functional: was the result of that action what the business actually intended?
A function can execute successfully and still update the wrong field.
A workflow can correctly send an email that should never have been sent.
An automation can create every task that was configured and still generate unnecessary work for the team.
Technical success and operational success are not the same thing.
Step 4. Review the data before relaunching automation
Automation and data are deeply connected.
If the CRM contains incomplete or inconsistent information, workflows will use that information to make decisions.
The company should review mandatory fields, duplicates, owners, opportunity statuses, associations between contacts and companies, countries, segments, consent, lead sources and any other data used by workflows.
Fields that exist only because an old automation depended on them should also be identified.
Over time, CRMs frequently accumulate properties that no longer have a clear purpose.
Deleting fields indiscriminately is also dangerous because hidden dependencies may exist.
The recovery process should therefore include a map connecting data, workflows and integrations.
Step 5. Review Marketing and Sales together
Many CRM implementations fail at the boundary between teams.
Marketing considers a lead qualified and sends it to Sales. Sales believes there is not enough intent yet. The CRM has no clear criteria for returning the lead to nurturing. Nobody knows who is responsible for the next follow up.
Automation ends up reflecting this lack of alignment.
Before relaunching lead qualification, routing, nurturing or follow up workflows, Marketing and Sales should jointly define essential concepts.
What is a lead?
What is a Marketing Qualified Lead?
When should Sales receive the lead?
How quickly should Sales act?
What happens when there is no response?
When should the lead return to Marketing?
Which information must be completed in the CRM?
When is an opportunity created?
When is it considered lost?
These decisions may seem basic, but they determine a large part of the automation architecture.
See the CRM process gaps that misalign Sales and Marketing and how to correct them
Step 6. Rebuild only what is necessary
After the audit, not every workflow needs to be rebuilt.
Some may only need corrected criteria.
Others should be simplified.
Some may no longer be necessary at all.
A good recovery project reduces complexity wherever possible.
If a process can be handled with a simple workflow and three clear conditions, there is no benefit in using multiple automations, auxiliary fields and custom functions.
Functions and customisations should exist when the business logic genuinely requires them.
In Zoho CRM, custom functions can execute logic that standard actions cannot support, including updates across related modules and interactions with external applications. That flexibility is powerful, but it also increases the need for testing, documentation and monitoring.
The same principle applies to HubSpot. Custom code, webhooks and integrations add capability, but they also create additional dependencies and points of failure.
The objective is not to use as much technology as possible.
It is to create the simplest process that can execute the business requirement correctly.
Step 7. Test real scenarios before reactivating
An automation should not be considered ready simply because it worked with one test contact.
Different scenarios need to be tested.
A complete lead.
A lead with missing fields.
A contact that already exists.
A company with several associated contacts.
An opportunity that changes stage and then returns to the previous stage.
A person who replies to an email during a sequence.
A record whose owner has left the organisation.
An error in an external integration.
The objective is to test not only the ideal scenario, but also the exceptions.
In automation, exceptions are often what create the most serious problems.
When testing is complete, there should be clear evidence of the expected behaviour and the actual result.
What should happen to records affected by failed automation?
Correcting the workflow does not automatically correct the past.
This is one of the most important aspects of a recovery project.
There may be contacts that never received communications, deals that were not updated, tasks that were never created, leads assigned to the wrong person or information sent incompletely to external systems.
Once the logic has been corrected, a remediation plan should be created for historical records.
HubSpot and Zoho provide mechanisms that can help in certain scenarios. HubSpot automatically retries some actions when a failure is temporary, for example when a connected application reaches certain limits or a timeout occurs.
In Zoho CRM, workflow reports allow certain failed actions to be repeated and failed custom functions can be analysed and, within the conditions allowed by the platform, executed again.
However, the decision to rerun an action should be made carefully.
Sending a commercial email again three weeks later may no longer make sense.
Creating a task retroactively may be useless.
Updating a field may trigger another workflow.
Historical remediation should therefore consider the customer’s current state rather than simply trying to recreate what should have happened in the past.
When is it time to change implementation partner?
Not every problem justifies changing partner.
A complex implementation can encounter errors even when it has been designed properly.
The key question is how the partner responds when the problem appears.
There are more concerning signs.
Can the partner clearly explain the existing architecture?
Is there documentation?
Were business processes defined before configuration?
Is there a testing methodology?
Are integrations monitored?
Is there a change control process?
Does the team receive training?
Is there support after go live?
Does the partner challenge requirements when they create unnecessary complexity?
If the answer is repeatedly no, the problem may extend beyond one specific automation.
A CRM implementation partner should understand both the technology and the process being configured. The objective is not merely to build workflows. It is to make sure that the implemented architecture remains understandable, sustainable and aligned with business objectives.
How should a company choose a HubSpot or Zoho CRM partner?
A strong CRM partner should be able to work across three levels: business, process and technology.
Knowing the platform alone is not enough.
A company may hire someone who is excellent at building workflows but still does not understand the commercial process being automated.
For a B2B project, the partner should be able to discuss pipeline, qualification, lead management, Marketing Automation, forecasting, customer lifecycle, reporting and adoption with the same clarity used to discuss properties, modules, workflows and APIs.
Certification or official partner status also matters, but it should not be the only criterion.
The purpose of a CRM partner selection process should not be to find a company that sells licences.
It should be to find a partner capable of translating business processes into a sustainable implementation.
Explore Liminal’s HubSpot consulting and implementation capabilities
Explore Liminal’s Zoho implementation and optimisation capabilities
Which questions should be asked before selecting a CRM partner?
Before hiring a partner, an SMB or mid market organisation should ask concrete questions.
How are requirements gathered?
How are current and future processes documented?
How are exceptions handled?
Who is responsible for data migration and data quality?
How are workflows tested?
How are automations and integrations documented?
How is training delivered?
How is adoption monitored?
What happens after go live?
Who resolves API or external system issues?
How are changes approved?
Which people will actually work on the project?
What experience does the team have with similar projects?
It is also important to request examples of previous projects, clarify responsibilities and understand what will remain with the client and what will be handled by the partner.
Even the strongest implementation partner cannot deliver a CRM project alone.
The client needs to make decisions, validate processes, provide data, make users available for testing and involve leadership.
Is it better to recover the current implementation or move to another CRM?
A failed automation is not, by itself, a reason to change platforms.
HubSpot and Zoho CRM are flexible enough to support a wide range of Marketing and Sales processes.
Moving to another tool without understanding the cause of the problem may simply transfer the same issues into a new system.
An audit should come before migration.
Is the problem caused by a genuine limitation of the platform?
Or is it caused by configuration, process, data, integration or adoption?
If the requirements genuinely sit outside the capabilities of the current system, it may then make sense to evaluate alternatives.
This is where comparisons such as Salesforce vs HubSpot vs Zoho become relevant.
Salesforce may be more appropriate where there are very high levels of complexity, governance, customisation and integration.
HubSpot may make more sense when there is value in unifying Marketing, Sales and Service in a relatively accessible customer platform.
Zoho may be particularly suitable when the organisation needs flexibility, automation and integration across a broader business software ecosystem.
But changing platform simply because a previous implementation failed is usually premature.
The right question is: can the technology not support the process, or was the process never implemented correctly?
What are the main signs that a CRM implementation is at risk?
There are several clear warning signs.
The team maintains parallel spreadsheets.
Users do not trust dashboards.
Nobody knows exactly what certain workflows do.
Several properties or fields have similar meanings.
Records are manually corrected because automation cannot be trusted.
The pipeline does not reflect commercial reality.
Integrations fail without alerts.
Only one person can safely make changes to the CRM.
Teams avoid certain functions because they “usually cause problems”.
Marketing and Sales use different definitions for the same stage of the process.
None of these signs alone means that the implementation has failed.
But several appearing at the same time indicate that the CRM probably needs a structural audit rather than a series of small adjustments.
Team adoption is another particularly important indicator. When the system stops being seen as a working tool and becomes only an administrative obligation, data quality deteriorates and every automation built on top of that data starts to lose reliability.
Frequently asked questions about failed HubSpot and Zoho CRM automation
Why does a HubSpot automation fail?
A HubSpot workflow can fail because of incorrect configuration, problems with enrolled records, custom code errors, timeouts, connected application limitations, webhooks or limits associated with specific functionality. HubSpot provides troubleshooting information and specific areas for analysing automation problems.
Why does a Zoho CRM workflow fail?
In Zoho CRM, causes may include incorrect criteria, logical errors, missing data, execution limits, failed custom functions, webhooks or other technical issues. Workflow reports and Function logs help identify the specific reason.
Can a failed automation be rerun?
In some cases, yes. HubSpot automatically retries certain actions that fail because of temporary issues. Zoho CRM allows administrators to analyse failed actions and rerun certain executions after correction. However, before repeating an action, the company should assess whether it still makes sense given the current state of the record.
How should a CRM implementation partner be selected?
The decision should consider experience, technical capability, understanding of business processes, implementation methodology, data migration, integrations, testing, training, adoption and post implementation support. Certifications and official partner status are relevant, but they do not replace an assessment of methodology and real project experience.
Is it worth hiring an official HubSpot or Zoho partner?
Official partner status provides an additional indication of platform knowledge and connection to the vendor ecosystem, but the decision should still consider specific experience, methodology and the ability to respond to the requirements of the project.
Does a failed implementation mean the company needs a new CRM?
No. The cause should be identified before any migration. If the problem comes from process, data, configuration, integration or adoption, changing CRM may simply move the same problems into another platform.
Recovering a CRM means recovering trust in the system
A HubSpot or Zoho implementation can sometimes be technically recovered relatively quickly when the failure is limited to one workflow.
But when teams have stopped trusting the CRM, the challenge is greater.
Trust in the data, processes and reporting also needs to be rebuilt.
That requires more than correcting technical errors.
It requires simplifying automation, correcting data, redefining responsibilities, documenting processes, testing scenarios, training users and creating governance mechanisms that prevent the platform from returning to the same state a few months later.
That is why recovery projects should be treated as operational projects rather than simple technical support.
Technology can execute thousands of actions without human intervention.
But it only creates value when those actions correctly represent how the business should operate.
How Liminal can recover and relaunch a CRM and automation implementation
When a HubSpot or Zoho implementation is no longer delivering the expected results, starting again from scratch should rarely be the first option.
At Liminal, the starting point is to understand what already exists.
We analyse processes, CRM architecture, data, workflows, automation, integrations, reporting and team usage to distinguish technical issues from operational ones.
This makes it possible to determine what should be corrected, simplified, rebuilt or removed.
Instead of adding more technology on top of an architecture that is no longer understood, the objective is to rebuild a controlled foundation aligned with Marketing, Sales and business objectives.
As a consultancy specialising in MarTech, CRM, Marketing Automation, Business Intelligence and Artificial Intelligence, Liminal works across both the strategic and technical sides of implementation. This means that a lead assignment rule is not analysed only as a workflow. It is analysed as part of the commercial process. A dashboard is not simply a collection of charts. It needs to support decisions. An integration is not assessed only on whether it transfers data. It needs to ensure that the right information reaches the right system at the right time.
Experience across HubSpot and Zoho also makes it possible to assess pragmatically when the current platform should be recovered and when there are genuine reasons to consider another architecture.
For B2B companies in Portugal evaluating CRM implementation partners, this distinction is critical.
The objective should not be to find someone who can simply configure HubSpot or Zoho.
It should be to find a partner capable of understanding the process, correcting the existing architecture, relaunching automation safely and creating the conditions for Marketing and Sales to use CRM as growth infrastructure.
Because recovering an automation does not simply mean making it work again.
It means making sure it executes the right process.