Hi everyone,

I’m submitting this as a formal feature request because this is causing significant real-world problems for clients. I’ve also emailed LeadConnector support directly about this issue.

Context:

I manage inbound call and message handling inside GoHighLevel for service businesses that receive a high volume of spam and robocalls. We use GoHighLevel workflows to screen inbound events using number intelligence, IVR gating, and conditional logic. From a workflow perspective, the filtering works correctly.

The issue is where client notifications sit in the system relative to workflows.

Current behavior:

When an inbound call or message hits a GoHighLevel number, LeadConnector immediately sends a “You’ve got a new lead” notification to the client.

Only after that notification is sent do workflows and number intelligence run.

What this causes in practice:

From the client’s perspective, this looks like false alerts, disappearing leads, and an unreliable system, even though the workflows are functioning correctly.

Core problem:

LeadConnector “new lead” notifications are tied to raw inbound call or message events, not to qualified or workflow-approved events such as IVR completion or number intelligence pass. Because notifications fire before workflows complete, there is currently no way to prevent spam calls from generating client-facing “new lead” alerts, even when GoHighLevel filters those calls out almost immediately.

In a world without spam this design wouldn’t matter. In the real world it is extremely disruptive, especially for non-technical or tech-averse clients who rely on notifications to know when to act.

Current workaround (not ideal):

The only reliable workaround I’ve found is to have clients completely disable LeadConnector notifications at the phone or app level. I then send a separate SMS via workflow to their personal phone number once a lead passes filtering, instructing them to open LeadConnector and find the conversation manually.

This technically works, but it adds friction, creates confusion, defeats the purpose of real-time in-app notifications, and makes the platform feel brittle to end users.

Feature request:

Please introduce a way to decouple client notifications from raw inbound events and instead trigger them only after inbound events have been evaluated or qualified. Examples could include notifications firing only after IVR completion, notifications gated behind a workflow condition, or notifications tied to qualified events rather than initial ingestion.

I’m not asking for better spam detection. The filtering already works. This is specifically about notification timing and control.

Why this matters:

This is not a flashy feature, but it is a critical quality-of-life and client-retention issue. For real-world service businesses, especially those that already dislike tech, this is one of the fastest ways to destroy trust in the system. If you’ve dealt with spam calls triggering false “new lead” alerts for clients, this deserves attention and upvotes.

Screenshots Attached:

I am attaching two screenshots to illustrate the real-world impact this issue has on an actual client.

The first screenshot shows the client’s phone call log. It is flooded with repeated “Scam Likely” robocalls throughout the day. This is the baseline environment the client is operating in.

The second screenshot shows what the client’s LeadConnector app actually looks like in practice. Every notification shown is a “New Lead” alert generated by spam or robocalls that were later filtered out by workflows. At the same time, I am actively running paid ads that generate legitimate leads.

The problem is that real, paid leads trigger the same notification as spam, so they get buried immediately in a flood of false alerts. From the client’s perspective, there is no reliable way to distinguish a real opportunity from noise, and genuine leads are easily missed or ignored entirely.

Without my current workaround in place, genuine paid leads are effectively lost in the noise. For a non-technical client, this creates confusion, frustration, and missed opportunities. The client has difficulty distinguishing real leads from spam and has expressed that the volume and randomness of notifications makes them want to ignore their phone entirely.

This is not a hypothetical or edge case scenario. This is exactly what a real service business owner sees on their device while paying for advertising and expecting reliable lead delivery.

I am including these screenshots to demonstrate how notification timing, filtering, and workflow order directly affect whether a legitimate lead is ever seen or acted on.