Run a database reactivation over iMessage from GoHighLevel
A database reactivation is the one campaign where pacing matters more than copy. This build does two things: checks every contact for an iPhone, then drips the sequence to the ones that have one, so non-iPhone contacts exit quietly instead of failing. Build the shell once and clone it into every sub-account — remembering to swap the line ID each time.
What you will be able to do
- Trigger a reactivation on a tag rather than a list import
- Pace the drip with batch size and interval so a line is not asked to burst
- Filter for iPhone before the sequence rather than after a failure
- Clone the workflow across sub-accounts and change the sending line ID
- Tell the four failure points apart: trigger, iPhone check, line, media URL
Chapters
Timestamps open YouTube at that moment. 16 sections across 13:07.
- 0:03
What this workflow does
Checks each contact for an iPhone, then drips the reactivation sequence only to those. Mechanics, not copywriting.
- 0:27
Create the workflow
Switch into the right sub-account, Automation → Create Workflow → Start from Scratch.
- 0:42
Trigger on a tag
Contact Tag Added, with the filter set to the tag you will apply to the reactivation cohort.
- 1:37
The drip action
Batch size and interval, set so the workflow does not push a line past its sending limits.
- 2:15
Check iMessage
Search for the Tuco action under Apps. It fills contact.phone_raw for you.
- 2:32
Branch on availability
If/Else on Check iMessage Available = true. iPhone contacts go left, everyone else goes right.
- 3:06
The first message
Plain text, no links, no attachments, with the sending line ID pasted from the Lines page.
- 3:52
Wait, then voice note
Upload an MP3 under Leads → Upload Audio and confirm the URL plays in incognito before pasting it.
- 4:50
SMS fallback branch
The non-iPhone branch needs an approved A2P phone system in that sub-account, or the SMS step has nothing to send through.
- 6:25
Clone it to other sub-accounts
Copy the workflow across, then change the sending line ID — it does not belong to the new workspace.
- 7:03
Enrollment history and execution logs
Enrollment history shows whether the contact entered; execution logs show which branch they took.
- 8:44
The step everyone forgets
An unpublished workflow enrols nobody. Publish it, then re-apply the tag.
- 10:10
Tuco activity logs
Where you see the availability check itself, and why a contact was routed to SMS rather than iMessage.
- 10:52
Send detail in the inbox
When the send was requested, whether it was delayed, and whether it was rescheduled.
- 11:07
The common failures
Bad phone number, duplicate message, line offline, daily limit reached, and an empty template variable.
- 12:11
Re-entry and send windows
Allow re-entry controls whether a contact can run through twice; the send window stops messages outside allowed hours.
