AI workflow editing enters private beta

NEWS / PRIVATE BETA

1. AI workflow control arrives with a pause to understand

Announced 28 October · Checked 29 October 2026

What changed

HighLevel announced a Workflows API and related access through its LeadConnector MCP server. The API lets software read, create, update, publish and delete workflows, and inspect execution records. The MCP connection exposes workflow tools to compatible AI assistants. Both releases are private beta for selected sub-accounts, not a general release.

New workflows begin as drafts. The vendor says changing a published workflow requires putting it into draft first: its triggers are then off and contacts in it are paused. Publishing is a separate step. API updates replace the whole workflow definition, so the release notes instruct developers to read it before sending an update.

The vendor says execution logs cover live runs, exclude builder test runs, and allow up to 30 days per request within 60 days of history. MCP requests operate in one sub-account; agency connections covering multiple sub-accounts are rolling out. Permanent deletion stops contacts currently in the workflow.

Who this affects

Australian businesses whose operator manages enquiry, booking or follow-up workflows on the underlying platform, especially those exploring AI-assisted administration. Growthcenter account access must be verified. If the current process works and nobody needs code or AI control, there is no need to join a private beta.

Our analysis: what it means for your business

Hypothetical example: a Melbourne maintenance business uses a workflow to assign new service requests. An operator asks an assistant to change the assignment rule. If that requires switching the published workflow to draft, the vendor’s stated pause affects the live process while the edit is being made. A request to “make one small change” is therefore also a decision about when the business can tolerate an interruption. This is a scenario to plan for, not an incident observed in a customer account.

The useful distinction is between inspecting a workflow and authorising a change. Asking which step failed may support investigation. Publishing a new rule, replacing a definition or deleting a workflow changes what the system does. Our recommendation is to agree which actions the operator or assistant may perform, who reviews a draft and who can approve publication. The release offers separate workflow permissions; it does not establish that every connected tool will enforce the business’s preferred approval process.

For an initial trial, a read-only investigation or an unpublished draft may be enough to answer the business question. Before any approved live change, name the person covering incoming requests, define how the original workflow can be restored, and check what happened to work waiting during the pause. Do not assume turning a trigger back on automatically recovers every request received while it was off; that behaviour needs an account-specific test.

The log window is another practical limit. A clean report for the requested period does not prove older work was completed, and a builder test is not part of the live-run log described here. Keep test evidence and operational reconciliation distinct. This announcement establishes capability, not measured time savings, fewer missed calls or more bookings. HighLevel’s descriptions of compatible AI tools are vendor claims, not independent confirmation from those tool providers.

What to do next

1. Ask the existing account operator whether the specific sub-account is enabled and which workflow permissions would be granted.
2. Start with the smallest useful inspection or draft task; review the complete change before authorising publication.
3. For a live edit, agree a change window, temporary enquiry coverage and a recovery check for paused or newly arriving work.
4. Verify the relevant live-run records and original request outcomes after the authorised change, rather than relying only on a successful tool response.

NEWS / LABS

2. Portal records need a customer-visibility check

Announced 28 October · Checked 29 October 2026

What changed

HighLevel announced custom objects in Client App Builder, available through Labs. Members can submit information that becomes CRM records. The builder previews proposed data structures and access permissions before approval. Visibility options include a member’s own records, their company’s records, or all records in read-only mode.

The vendor lists up to three objects per request within a limit of ten custom objects per sub-account. Payment actions depend on an already connected payment provider. Its related mobile-builder release supports generating Android APKs and lists iOS publishing as coming next. Neither an APK nor the announcement establishes approval or distribution through an app store.

Who this affects

Service businesses already considering a customer portal for recurring requests, applications or job information, with an operator able to review the data model and access. Growthcenter users need to confirm Labs access and account limits. A business with occasional one-off enquiries and a working form or phone process may have no reason to add a portal.

Our analysis: what it means for your business

Hypothetical example: a property-maintenance business wants clients to submit repair requests and see their status. A person managing several buildings may need company-level visibility. An individual tenant may need access only to their own request. Those are different permissions, even if both screens look like a simple list. This example does not describe a tested portal or an approved data-sharing arrangement.

Our recommendation is to define who should see each record before asking a builder to generate the interface. Use two authorised sample customer accounts with clearly separate records, then check both ordinary navigation and the links the portal exposes. Confirm that a company relationship grants exactly the access intended. A visually correct preview is useful, but it is not evidence that every access path has been tested.

Record creation is also only the start of service delivery. Decide who receives a new request, how urgency is identified, what acknowledgement the customer sees and how staff mark the work as handled. A portal that accepts a request without an accountable recipient can create a new queue for the business to miss. The announcement does not prove an automatic booking, a response-time improvement or completion of the customer’s job.

The mobile option should follow a real customer need. Producing an Android installation file is different from supporting customers across devices, distributing updates and handling sign-in problems. Because iOS publishing is listed as future work, do not promise an equivalent iPhone app on the strength of this release. A small portal trial may answer the business question before a branded app is justified.

What to do next

1. Confirm Labs access, existing object use and the relevant account limits before committing to a portal design.
2. Write down own-record and company-record access rules, then test them using authorised sample accounts before customer use.
3. Assign a named staff owner and check the complete submission-to-response process, including exceptions.
4. Verify supported devices and distribution requirements separately; do not treat future iOS support or payment-provider setup as already available.