Automations

Guys, I know I'm not the only one struggling with slow loading times on a lot of GHL. We replaced the 9 dots of death with the ring of stress.. We all absolutely LOVE all the new features coming out, but can we pause for a sec and just update the servers or whatever needs to be done in order to make the GHL experience even better for our clients? I'm an affiliate for GHL as well, so when I make videos promoting GHL and my load times are 30-60 seconds, it can be difficult to be confident in this for new users. So please, let's just take a second to improve overall speed and performance of GHL! Me love you long time!

Currently, there is no way to modify a Workflow using the API. I'm forced to return to something like Selenium to automate those tasks. It would be nice if we could do this in a "headless" environment using an API instead of being forced to use the UI. I have a template that I use for workflows and I'm forced to click through the entire process every time. Something that could be as simple as running node generateWorkflow.js ends up taking me at least an hour every time.

Currently, workflows triggered by the Scheduler run without a Contact context. Because the Math Operation action requires a Contact, it gets skipped even when the calculation only involves global Custom Values. This creates an unnecessary limitation for scheduled automations that do not need any Contact data. Use Case: For example, we have a global Custom Value that stores the current date of a recurring onboarding event. A Scheduler workflow runs daily and checks whether the current date matches the onboarding date. Once the date is reached, the workflow should automatically calculate the next onboarding date by adding a certain number of days and update the global Custom Value. The logic would be: Scheduler → Check current date → Compare with global Custom Value → Math Operation: Add X days to the date → Update global Custom Value Currently, the Math Operation is skipped with: “This action requires a Contact and none has been provided.” Even though no Contact data is involved in the calculation. Requested Improvement: Please allow Math Operations to run without a Contact context when the inputs and outputs are global Custom Values. This would make Scheduler workflows much more flexible and would avoid having to create artificial Contacts or external workarounds just to perform simple calculations. Expected Behavior: If a Math Operation only references global Custom Values, it should be executable inside a contactless workflow. This could also potentially apply to other workflow actions that technically do not require Contact-specific data but currently still depend on a Contact context.

Current Behavior: When a wait step extends past the Advanced Window, the system continues counting down in real time overnight, exhausting the delay before business hours reopen. This creates severe issues for team SLA tracking and lead distribution, as staff are deprived of their allotted response windows when the office opens. Requested Behavior: Add a setting for wait steps to pause the countdown when outside the Advanced Window and resume the remaining time once the window reopens (e.g., if a 30-minute timer starts at 4:15 PM and business hours end at 4:30 PM, the timer should pause with 15 minutes remaining and finish at 7:45 AM the next morning). Impact: Eliminates complex multi-branch workaround stacks and ensures accurate tracking of staff response SLAs.

Hi GHL Support, I’d like to escalate an issue with the Afterglow Medical Med Spa sub-account involving the SMS Alert automation. The issue is that leads are getting stuck on the Wait step after the automated SMS is sent. I previously contacted support and was advised that the workflow is expected to wait for the customer to reply before proceeding. However, this behavior is not practical for our use case. It’s not guaranteed that a customer will reply immediately, or even reply at all, to the automated SMS. Because the workflow is waiting for a response, the lead can remain stuck on the Wait step indefinitely, which prevents the next actions in the automation from taking place. We’d like to understand if there is a way to configure the workflow so that it does not depend entirely on the customer replying to the previous SMS before continuing. Could you please escalate this to the appropriate technical team and confirm whether there is: * A way to prevent leads from remaining indefinitely on the Wait step * A different trigger or condition we can use to detect the intended response without blocking the workflow * A recommended workflow structure that would allow the SMS to be sent while still allowing the automation to continue if the customer does not respond The main concern is that waiting for a customer response is not a reliable condition in every scenario , since customers may take hours or days to respond, or may not respond at all. We’d appreciate it if the technical team could review the workflow behavior and advise on the best way to handle this.

NESTED: ability to have custom values used within a custom value, such as for concatenation FALLBACK: Example: {{custom_ values.phone _number_for_display:fallback="(111) 222-3333"}} ABILITY TO BLANK: If I have fallback functionality, it makes sense to allow blank values. They're already allowed upon initial Snapshot import anyway. Why not allow resetting to blank whenever I want? FIELD TYPES: (Custom Fields already has multiple field types.) Link color picker Media picker (saves the URL value of the chosen/uploaded media item) WYSIWYG (saves the HTML value) Code Editor VALIDATION: trim no spaces minimum length maximum length string must include (e.g. ' facebook.com ') email address regex

With the recent change of Meta, some contacts now arrive identified by a username instead of a telephone number (for example, contacts that type on WhatsApp and arrive without a registered telephone field). This is causing the Conversations AI action within the automations to be skipped for the reason “No Phone number”, since the action depends on the existence of a telephone number to be able to execute. This directly affects automations that we already have configured and working, and would force us to modify several flows if it is not solved. It would be very helpful if the Conversations AI action could also be executed when the contact does not have a telephone but does have a valid identifier (such as the WhatsApp/Meta username).

The prostecting tool is already great, but I think it would be better if it was able to be integrated with forms so that when an agency offers a free audit report on their website, the form could automatically populate the prospecting tool based on what the user enters. Then, the automation happens whereas the report is generated and automatically sent to the address/phone number on the form in printable pdf format.

While premium actions is a great feature the pricing strategy is odd to me. Why is an api call $.01/ action when an email is $.000675/email? Also this service is cheaper than Zapier at 750 actions/mo but more expensive once a certain volume is reached. There should at least be volume discounting to be comparable to Zapier. Not to ruffle feathers, but all these prices are pretty high when compared to other platforms like Make.com as well.

Please add optional HMAC signature validation directly inside the Inbound Webhook workflow trigger. The Problem: Many third-party platforms (payment processors, custom SaaS tools,etc) issue an HMAC key and send a signature header (e.g., X-Signature) to verify payload authenticity. Currently, HighLevel cannot validate header signatures on incoming webhooks. This forces users to route webhooks through middleware (Make, Zapier, or a custom server) just to verify the request before forwarding it to HighLevel. Proposed Solution: Add an optional HMAC Verification configuration block inside the Inbound Webhook trigger settings: Secret Key Field: Input for the shared secret/HMAC key. Header Name Field: Input to specify the signature header (e.g., X-Signature, X-Hub-Signature-256). Algorithm Selection: Dropdown to select the hashing algorithm (e.g., SHA-256, SHA-1). Behavior: Automatically reject or drop incoming requests if the computed signature does not match the header. Why This Matters: This would allow users to build secure, direct integrations with external tools without needing expensive third-party middleware or custom code servers.