Ad Reporting and Attribution

Trying to connect Claude with GoHighLevel sub account so that I can speak automations into existence, but it appears we only have the ability to toggle on "readonly" instead of "write". This would be a game changing feature and save people hundreds of hours during account setup and ongoing maintenance of sub accounts! I'm getting tired of manually creating workflow automations over here! (the built in ai inside workflow automations told me he cannot do that yet)

The problem: When a SaaS sub-account's payment fails and the account is paused, the connected custom domain(s) are not disconnected — they stay live. So a client who has stopped paying keeps their website, funnels, and domain fully served with no interruption. The pause hits internal functionality, but the most public-facing asset — the live domain — keeps running for free. There's currently no way to automatically pull the domain when payment fails. The ask: An agency-configurable setting — attached to the SaaS home sub-account — that automatically disconnects (or takes offline) the sub-account's connected custom domain(s) when a payment fails. Ideally: Trigger on payment failure, on the agency's own timeline (e.g. immediately, or after a configurable grace period). Handle all connected domains on the sub-account, not just the primary. Optionally redirect the disconnected domain to a "please update your billing" page instead of leaving a dead/live site. Why it matters: Right now there's no leverage on the one asset the client actually cares about staying up. A non-paying account can keep its public site live indefinitely, which removes urgency to resolve billing and effectively gives away the most visible part of the service for free. Auto-disconnecting the domain (with an optional billing-update redirect) gives agencies real recovery leverage and closes an obvious gap in the SaaS dunning flow.

The problem: When a SaaS sub-account's payment fails, the only current lever is to pause the sub-account — and it fires instantly on a single failed charge. The agency gets a notification, but there's no built-in way to notify the customer. So the first thing the client experiences is everything breaking: workflows paused, marketplace apps dead, features offline — with no heads-up that a card just failed. The pain scales with the agency. The current workaround is to manage dunning entirely through Stripe's own reminder/failed-payment emails, which works but lives outside GHL and means the customer-facing communication is disconnected from the CRM. The ask: A native, agency-configurable setting — attached to the home/agency sub-account, since GHL already knows which sub-account is the SaaS home — that automatically notifies the customer when their payment fails. Ideally: Trigger a customizable email/SMS to the client on payment failure ("Your payment didn't go through — please update within X days or services will pause"). A configurable grace period before the pause actually takes effect, so a single failed charge doesn't instantly kill a live account. Templates the agency can brand/customize, routed through the SaaS home sub-account. Why it matters: Right now the pause is punitive and silent from the client's side. A grace window plus native dunning notifications would cut support tickets, recover more failed payments, and stop a one-time card decline from taking down a customer's entire operation in real time. This would be a big win for anyone running SaaS mode at scale.

Problem In high-automation accounts, real one-to-one conversations get buried. A contact replies to an automated email or SMS, and by the time staff open the thread there are 20+ automated sends stacked on top of it. The existing automated/manual filter doesn't solve this: an inbound reply to an automated message is attached to the automated thread, so filtering to "manual" drops the reply out of view, and filtering to "automated" buries it again. Keyword search doesn't help either, because you don't know what the customer said — that's the thing you're trying to find. Real impact: I run a loyalty program that sends scheduled follow-ups across ~200 locations. A customer told me they liked the product but weren't sure they could use it, because there was too much noise in the inbox to find actual replies. Proposed solution A thread-level view toggle that separates conversation signal from automation noise: Collapse or hide outbound automated messages in the thread, while always keeping inbound messages visible regardless of what they replied to Treat inbound replies as first-class: an inbound message never gets filtered out by an outbound-automation filter Make it a saved/pinnable view so staff don't rebuild it each time Ideally the same distinction is available as a smart-list / conversation filter, not just an in-thread toggle Why it matters Response time and SLA depend on staff finding real replies fast. "Jump to unread" helps once, but doesn't fix the noise problem at scale — and the more automation an account runs, the worse the inbox gets. Related: the reply-to address on campaigns always resolves to the sending domain, which removes another signal that could distinguish these threads.

When a location sends a bulk SMS campaign, HighLevel continues attempting to process every queued message even if the location’s wallet runs out of funds. This causes hundreds or potentially thousands of contacts to fail with an “insufficient funds” error. After the wallet is reloaded, there is no simple way to resume the bulk action or retry only the contacts who failed. The current workaround is to identify and export the failed contacts, add the funds, and then manually create another bulk action. Requested enhancements: Before starting, estimate whether the location has enough wallet funds to complete the bulk action and warn the user if the balance appears insufficient. If the balance reaches zero while processing, automatically pause the bulk action instead of allowing the remaining contacts to fail. Resume processing after the location’s automatic wallet reload is completed or funds are manually added. Add a “Retry Failed Contacts” option that retries only contacts who failed because of insufficient funds, without duplicating messages to successful recipients. This would prevent unnecessary errors, reduce manual cleanup, and make large bulk SMS campaigns much more reliable for agencies and their clients.

As of June 2026, Meta is rolling out WhatsApp usernames, allowing users to hide their phone numbers by default. When a user adopts a username, businesses will no longer receive their phone number via webhook. Instead, Meta will deliver a Business Scoped User ID (BSUID), a unique identifier per business account. Currently, GHL identifies and matches contacts exclusively by phone number. This means that once a contact adopts a WhatsApp username and hides their number, any incoming message from that contact will either fail to match an existing contact record, create a duplicate, or simply land as an unassigned conversation in the inbox. For businesses using GHL with direct Meta integration, this is not a hypothetical edge case. It will affect real conversations, automations, and workflow triggers that rely on contact identification. And also unable to reply even tho it's still under 24 hrs window chat for Mobile Apps(Lead Connector) Requested solution: Store and index the BSUID returned by Meta's webhook as a secondary contact identifier, alongside the phone number. When an incoming WhatsApp message carries a BSUID, GHL should attempt to match it against existing contacts before creating a new record. This would preserve conversation history, workflow context, and contact data integrity as Meta's username rollout expands. This is a foundational fix that will become increasingly necessary as WhatsApp username adoption grows throughout 2026 and beyond.

It would give us so much flexibility to manage the code as Lovable offers if there is a GitHub connection in the AI Studio. This would be awesome!

I want you to have another AI Superagent or bot that talks to all the AI on Gohighlevel that as i individually have to ask each AI to do a task if i have one that i can speak to and ask it to each task and it can automate to use each AI bot in one place maybe like an employe for me

Private integrations are currently limited when interacting with third-party APIs such as Meta because some endpoints are blocked or unavailable. It would be extremely useful if HighLevel allowed developers to create inbound endpoint URLs as part of a private integration. External services could POST data to these endpoints, and HighLevel would process the payload as if it had originated from the native integration. This would: Keep developers within the HighLevel ecosystem. Reduce the need for external middleware. Enable more custom integrations while respecting third-party API restrictions. Give developers a supported extension point instead of relying on unsupported workarounds.

Add a way to "pin" an internal comment, so that everyone can see it and it doesn't get lost in the midst of an ongoing conversation with a prospect.