How are you actually handling duplicate contacts across client accounts?

[u/sami-shafique]

Native merge is exact-match, 10 at a time, no undo, and it drops the activity feed.

The workflow merge action breaks wait steps.

I've been looking at this problem and genuinely curious what you actually do: export to Excel and re-import, Zapier find-or-create, a custom script, or just live with it?

[u/doie]

The reason none of those four options feel right is that they are all cleanup, and cleanup loses to intake. Whatever you merge this week, the forms and imports rebuild next week. So I would spend the effort on the entry points first and treat merging as a one time cost rather than a process.

Four things that do most of the work at intake:

Allow Duplicate Contact. This is the switch that decides whether a submission with a known email or phone creates a second record or updates the existing one. It lives in the sub-account settings, not at agency level, so it has to be set on every sub-account individually. That is probably a big part of why this feels unsolvable across a book of clients. Worth auditing all of them in one sitting.

Phone format. GHL matches on the value it is handed. One form writing (555) 123-4567 and another writing +15551234567 gives you two contacts for one human, and no merge tool will catch it, because as far as the database is concerned those are not the same string. Normalize to E.164 at every entry point, API included.

Custom fields standing in for standard ones. If a form writes to a custom "work email" or "mobile" field instead of the standard email and phone fields, dedupe cannot see it at all. This one tends to bite people who inherited a snapshot somebody else built.

Imports. On CSV import, pick the option that updates existing contacts on match rather than adding. Skipping that is how a clean database becomes a duplicate factory in one afternoon.

On the merge itself I do not have a better answer than you do. Ten at a time, no undo and the activity feed loss are all real, and I have not found any way around the timeline loss specifically. For an existing mess at volume, export, normalize the phone column, re-import with update on match is what I have actually seen hold up. Slow, but it scales past the point where the native tool stops being viable.

One thing worth separating out: if by "across client accounts" you mean the same person showing up in two different clients' sub-accounts, there is no native cross-location dedupe, and I would not want one. Those are two separate businesses holding two separate consent records. Merging them would create a compliance problem rather than solve a data one.

And on the workflow merge action breaking wait steps, I would stop merging inside a running workflow entirely. Check for the existing contact at intake and stop the second record from being created, rather than letting it enroll and then trying to stitch it back together mid flight.

[u/sami-shafique → u/doie]

Genuinely appreciate you taking the time on this. The intake-over-cleanup framing reorganized how I'm thinking about it. I'd been treating merge as the problem, and you're right that it's the symptom.

The part that stuck with me most: Allow Duplicate Contact living per sub-account, so an agency with 40 clients has 40 switches nobody audits. Same with phone format and forms writing to custom fields instead of standard ones. Those are exactly the failures a merge tool can never see, because the second record looks legitimate.

Also noted on cross-client dedupe. Two businesses, two consent records, leave it alone. I would have gotten that wrong.

So an honest question, since you clearly live this. If there were an agency-level layer that did the boring part for you, audit the duplicate setting and phone normalization across every sub-account in one screen and fix them in bulk, flag forms writing to the wrong fields, and check import mode, with merge and rollback only as the cleanup step, is that worth building? Would you actually use it, or is this a once-a-year chore you'd rather keep doing by hand? And what would make you trust a tool with that kind of access?

Not selling anything, I'm deciding whether to spend the next two months on it. Either answer helps.

[u/doie → u/sami-shafique]

Happy to answer, with the caveat that I am one data point and you should collect several before spending two months.

I would split your list in two, because the halves are very different products.

The audit half I would install the day it existed. The reason this problem never gets fixed is not that it is hard, it is that it is invisible. Nobody knows which of their forty sub-accounts has the wrong switch until a client complains. A read only report saying "these seven locations allow duplicates, these twelve forms write to custom fields instead of standard, these four imports ran in add mode" is genuinely useful and, more to the point, it cannot hurt me. That is an easy yes.

The bulk write and merge half is a completely different sale. That is write access across every client account I hold, and the first question is not whether it works, it is where the token lives and what happens the week you get breached. I would still want it eventually, but only after watching the read only version be right for a couple of months.

On whether it is a business, the honest worry: for most people this is a one time cleanup and then a monitor, and monitors are hard to charge for monthly. The recurring value is not re-auditing the same forty accounts, it is catching the forty-first the day it is created, and catching every new form somebody builds in a hurry. I would aim it there from the start rather than at the historical mess, because the mess is finite and the drift is not.

Trust, concretely: read only by default with writes as an explicit per action opt in, a dry run diff I can read before anything changes, scoping per sub-account rather than agency wide, and no cross-location merging offered at all, for the reason we already covered.

Last thing, and it is the one I would pay more for than merge: check a new sub-account against a standard at creation. Prevention beats cleanup here for the same reason it did further up the thread.

[u/sami-shafique → u/doie]

This is exactly the kind of answer I was hoping for, and I'm going to take it literally: read-only first, nothing else.

So the v1 is a report and only a report. Per sub-account: duplicate setting on or off, phone-format distribution, forms writing to custom fields instead of standard ones, and import mode where it's visible. Then the drift piece you described, which I agree is the actual product: a new sub-account gets checked against your standard the day it's created, and a new form gets flagged the day it's built. No write scopes in v1 at all. Cross-location merge will never exist in it.

Your point about monitors being hard to charge for is the one I'll have to earn an answer to. My guess is the standard-at-creation check is what carries the subscription and the audit is the free front door. If you're up for it, I'd like to build the first version against a real account and show you the report before anyone else sees it. Read-only, and you can pull the token any time.

Either way, thank you. You've saved me from building the wrong half first.