Auditing a sub-account you inherited: the 30-minute GHL health check

You win a client from another agency, or a business owner who has been self-managing hands you the keys. You log into the sub-account for the first time and it looks completely fine. Contacts are there. Pipelines have cards in them. Workflows have names that sound reasonable.

It looks fine because GoHighLevel has no opinion about whether it is fine. The interface will not tell you that a workflow action points at a pipeline stage somebody deleted last spring, or that the SMS number the account sends from was added after the A2P campaign was approved. It reports what exists. It does not report what is broken.

Meanwhile the account is not waiting for you. Published workflows fire the moment a form is submitted, and they were built by somebody who has stopped answering your email. That is the actual position you are in on day one, and it is why the first half hour should not be spent tidying anything.

What follows is the order I work in. Thirty minutes, six passes, arranged so that the things that can hurt the client this week get looked at before the things that merely offend you. This is a map and a risk list, not a repair.

Why an inherited account is a different animal

An account you built carries context in your head. You know why that tag exists. You know which workflow is the real one and which is the abandoned first attempt. An inherited account gives you none of that, and if it changed hands formally, it arrives with documented holes.

HighLevel's sub-account transfer guide is direct about the split. Contacts, conversations, supported assets and account history remain together. What does not come along: users and team members, saved payment methods, custom branding elements, snapshots, agency-assigned dedicated email domains, and dedicated IP addresses. Phone numbers depend on who provides them. With LC Phone on both sides, numbers transfer with eligible A2P registration; if either agency is on Twilio, they do not transfer automatically and have to be coordinated separately.

Read that list again with an operator's eye. Users do not transfer. Snapshots do not transfer. So on the morning you take over, a meaningful share of the account's operating context is simply gone, and nothing in the interface marks the hole. Every one of the six passes below exists because of something on that list.

Minutes 0 to 4: who can still get in

Two questions, both about access, and they have different answers.

The first is human. Open the sub-account's staff list and read every user and their role. HighLevel documents two role types: Admin, described as full access to all modules and settings in the sub-account, and User, with restricted access and granular permissions. There is also an assigned-data restriction that limits a user to contacts assigned to them, opportunities where they are the owner, and appointments or tasks linked to their name. Because users and team members do not transfer with a sub-account, a short clean list may be clean by accident. A list with names you do not recognize means people from the previous arrangement still hold working logins.

The second is programmatic, and it is the one that gets skipped. Check the Private Integration Tokens issued in this account. HighLevel's support article on private integrations notes you can create up to five at the agency level and five at the location level, and the token documentation says the tokens are static, that they do not automatically refresh unless you rotate them from the interface, and that you cannot copy the value a second time. Practically: you can see that a token exists and what it is called, and you cannot see what it is. Any integration you cannot identify and account for is an open door with an unknown key behind it. Rotate it.

Output of this pass: a named list of every human and every token that can act inside this account.

Minutes 4 to 10: what is sending right now

This is the highest-risk pass, so it comes before anything that feels like real work.

Start with the draft and published distinction, because it is the whole safety boundary. Per HighLevel's workflow builder walkthrough, draft mode means the workflow will not trigger and take actions for real, and published mode means it will. So list the published workflows and, for each, note whether it contains an SMS or email action. That subset is the only part of the account capable of reaching a real person today. Everything else can wait an hour.

Then read the settings on each of those, because they set the blast radius. HighLevel's workflow settings overview documents the ones that matter here. Allow Re-entry means a contact can re-enter the workflow after they have fully completed it or been manually removed. Stop on Response ends the workflow for a contact who replies to a message from that workflow. The Time Window restricts when communication actions execute, and an action scheduled outside the window is paused and resumes at the next available time slot. Sender Details set the default from-name, from-email and from-number for everything the workflow sends.

The combination that bites is a published nurture with re-entry enabled, no stop-on-response, and a bulk import the previous agency queued before they left. Nobody sees it until a contact gets the same sequence twice and replies something you have to explain.

One warning about this pass. The instinct is to unpublish everything until you understand it. Do not. Unpublishing the workflow that handles the client's inbound lead follow-up is a visible outage in your first week, and it will be your outage, not the previous agency's. Read, list, then take specific things offline you can justify.

Minutes 10 to 15: messaging compliance before messaging volume

A2P is where inherited accounts hide the most expensive surprise, because approval is not a single account-level fact.

HighLevel's explanation of A2P 10DLC describes two required components: a Brand, which identifies the business sending messages to carrier networks, and a Campaign, which describes the type of messages being sent. It is explicit that US carriers and their registration partners review and make the approval decision and that HighLevel has no part in the vetting. It also states that each applicable local number must be linked to the approved campaign, and that sending before that is in place produces filtered messages and a 30007 error.

The carrier-side view matches. Twilio documents error 30034 as a message sent from a +1 10DLC number that is not associated with an approved A2P campaign, and lists among its causes a number that is not in the sender pool of the messaging service linked to the approved campaign.

So the question to answer is not "is this account A2P approved." It is "is every number this account sends from attached to the approved campaign." The classic inherited-account failure is a registration that was completed correctly a year ago, and a number added afterwards that nobody attached. The account shows an approval. The new number does not deliver. If you want the longer version of what gets these submissions rejected in the first place, we wrote it up in the A2P 10DLC submission mistakes that get GHL agencies denied.

While you are here, note who the registration is actually about. If the previous agency registered the Brand, the business details, contact and consent language on file describe an arrangement that no longer exists.

Minutes 15 to 21: the referential integrity pass

Now the quiet class of failure, and the reason inherited accounts rot without anybody noticing.

Most workflow actions do not carry a name. They carry an identifier: a pipeline id and stage id on an opportunity action, a custom field id on an update-field action, a user id on an assign, notify or task action, a workflow id on a remove-from-workflow action. In our operating experience, when that identifier no longer exists, GoHighLevel skips the action rather than reporting it, and the actions after it can stop too. We covered the mechanics of that in how invalid IDs kill GHL automations without showing an error.

Inherited accounts are the worst case for this, and not by chance. Users and team members do not transfer with a sub-account. So every internal notification aimed at a named recipient, every task assignment, and every contact-owner action built by the previous agency is now pointing at a person who is not in this location. That is not an edge case in a transferred account. It is the expected state, and it is worth assuming until you have checked.

Check the same way for custom values. A custom value that is referenced in an SMS body but holds nothing will publish without complaint and arrive at a real contact as a raw merge token in a real message. GoHighLevel is capable of blocking a workflow that is missing a required field. It does not block this one.

The honest problem with this pass is time. Doing it properly through the interface means opening each workflow and reading it node by node, and thirty minutes buys you a spot check, not coverage. Prioritize: the published workflows that send, first.

Minutes 21 to 26: the entry points

A workflow is only as safe as the things that can start it. Inventory them: forms, surveys, calendars, trigger links, inbound webhooks, and tags used as triggers.

Tags are the sneaky one. A tag-triggered workflow fires for anything that applies that tag, including a bulk action you run yourself while cleaning up. Before any bulk tag operation on an inherited account, list every workflow with a tag trigger and read what it does. You only have to skip that step once to never skip it again.

Calendars deserve a look for the same reason as workflows: a calendar still pointed at a team member who left will keep taking bookings that nobody owns. And check the forms that are actually embedded on the client's live site, which is not always the same set as the forms that exist in the account.

Minutes 26 to 30: write the baseline before you change anything

Spend the last four minutes recording the state you found, not improving it.

Export the contact data. Save the list of published workflows. Write down the counts: contacts, published workflows, pipelines and stages, custom fields, tags, phone numbers, users. Note what you deliberately did not touch and why.

Three weeks from now somebody will ask whether a thing was broken before you got there. On an inherited account, that question always comes. Being able to answer it with a dated baseline is the difference between a fixable conversation and one where you are the most recent person to have touched it.

The three findings that show up almost every time

• A user id inside a workflow that no longer exists in the account. Notifications and task assignments built for staff who left. Silent, and it means somebody has been not getting alerts for months.
• A sending number that is not attached to the approved campaign. The account shows an approval, the newest number does not deliver, and the failure looks like poor list quality rather than a registration gap.
• A published workflow nobody has read since the day it was published. Still firing, still costing sends, and sometimes duplicating something else that also still fires.

None of the three announce themselves. All three are cheap to find if you look in a fixed order, which is the only real argument for having a fixed order.

What not to do in week one

Do not delete and recreate assets in production. Recreating a pipeline, a stage or a custom field gives it a new identifier, and every workflow action that referenced the old one is now pointing at nothing. Update in place.

Do not clean up tags before you have mapped which workflows tag changes trigger. Do not unpublish workflows wholesale to feel safe. And do not treat a save confirmation as verification. GoHighLevel is consistently quiet about failure, so anything you have not read back, you have not confirmed. That discipline is the same one that matters when you are deciding whether to trust a snapshot somebody else built.

Making it repeatable

Thirty minutes is honest for one account when you know exactly where to look. The trouble is that an agency does not inherit one account, it inherits a portfolio, and six passes across fifteen sub-accounts is most of a week. That is why this audit usually does not happen, and why inherited accounts stay unaudited until something breaks in front of the client.

The part that does not scale by hand is the referential integrity pass, because reading identifiers out of workflow actions is exactly the work a person is bad at and a machine is good at. It is also the part most GoHighLevel integrations cannot reach. HighLevel's public developer documentation publishes a single workflow route, Get Workflow, and the response it documents is metadata: id, name, status, version, locationId and timestamps. Not the actions inside. Anything that inspects or builds at the action level needs the separate credential we explained in the GHL Firebase capture.

GHL Command is what I use for this on my own accounts. It reads each workflow's full action list, checks the identifiers inside those actions against what actually exists in the location, and reports across every sub-account rather than one at a time, which is the same argument we made for running a portfolio from one console. It runs from Claude on your own machine, so the client credentials stay on your computer rather than on somebody's server.

Flat $97 a month, every sub-account you manage included, never billed per account. Inherit ten more and the price does not move.

Frequently asked questions

What should I check first in a sub-account I just took over?
What is currently published, because that is the only part of the account that can reach a real contact today. HighLevel documents that a draft workflow will not trigger and take actions for real while a published one will. List the published workflows, mark the ones containing an SMS or email action, and treat that subset as live until you have read it.

Does a sub-account transfer bring everything with it?
No. HighLevel's transfer guide keeps contacts, conversations, supported assets and account history together, and explicitly excludes users and team members, saved payment methods, custom branding, snapshots, agency-assigned dedicated email domains and dedicated IPs. Phone numbers move with eligible A2P registration when both agencies use LC Phone, and do not transfer automatically if either side is on Twilio.

Why do inherited workflows fail without any error?
Because actions reference identifiers rather than names, and a dead identifier is skipped rather than reported. Since users do not transfer with a sub-account, notifications, task assignments and owner actions built by the previous agency point at people who are no longer in the location. Assume it until you have checked it.

Is an approved A2P registration enough to trust the account's SMS?
No, because approval is per campaign and delivery is per number. HighLevel states each applicable local number must be linked to the approved campaign, and Twilio's error 30034 covers a message from a +1 10DLC number not associated with an approved campaign, including a number missing from the campaign's sender pool. Check each number, not the account.

Should I pause the previous agency's automation while I audit?
Not as a default. Unpublishing live lead follow-up creates a client-visible outage you will own. Read first, then take specific workflows offline you can show are harmful or duplicated. And never delete and recreate in production: the new asset gets a new identifier and every reference to the old one quietly stops resolving.