HIPAA compliant workflow automation in GoHighLevel means four things at once: the HIPAA add-on and BAA are active on the sub-account, every message carries only the minimum necessary information, every tool the data touches has its own BAA, and the activity can be reviewed later. The add-on handles encryption. The other three are build decisions inside each workflow, and that is where most healthcare accounts we audit go wrong. This guide goes workflow by workflow: what to trigger on, what a message may say, which federal rule applies, and which HighLevel features its HIPAA documentation does not mention. Every rule below links to its source, read October 28, 2026. It is information, not legal advice. Your compliance officer or counsel makes the final call.
What makes workflow automation HIPAA compliant in GoHighLevel?
Workflow automation in GoHighLevel is HIPAA compliant when the account is covered by a signed BAA and each workflow limits, routes and records patient data the way the HIPAA rules require. Turning the add-on on is the first condition, not the whole job. We check five things before any healthcare workflow is published:
| Condition | What it means in a workflow | Rule behind it |
|---|---|---|
| 1. Covered account | HIPAA is enabled on the sub-account the workflow runs in, and the agency has signed HighLevel's BAA and its own BAA with the practice | Business associate contracts, 45 CFR 164.502(e) |
| 2. Minimum necessary content | Messages and internal notifications use only the merge fields the task needs: no treatment, condition or provider specialty | Minimum necessary standard, 45 CFR 164.502(b) |
| 3. Covered destinations | Every webhook, Zapier step, spreadsheet or storage target that receives patient data has a BAA with you | HHS cloud computing guidance; 164.502(e)(1)(ii) on subcontractors |
| 4. Patient channel choices honored | A patient who asks not to be texted or emailed is routed to another channel, by a field the workflow checks | Confidential communications, 45 CFR 164.522(b) |
| 5. Reviewable activity | Audit logs are exported before HighLevel purges them, and test results are filed | Audit controls, 45 CFR 164.312(b) |
The add-on purchase, the BAA chain and the per-sub-account switch are covered in is GoHighLevel HIPAA compliant, and the price in the HIPAA add-on cost. This page assumes that part is done.
Which GoHighLevel features does the HIPAA add-on cover?
HighLevel's HIPAA help article says the add-on covers "all objects that can store PHI": contacts, notes, custom fields, SMS and MMS, voice recordings, email bodies and attachments, form and survey submissions, calendars and invoices. It does not give a feature-by-feature list. Workflows, AI features, webhooks and exports are not mentioned at all. We read HighLevel's articles one by one and graded each feature by what HighLevel actually states.
| Feature | What HighLevel's documentation says | Our build rule | Grade |
|---|---|---|---|
| Contacts, notes, custom fields, forms, calendars, invoices | Listed as covered data types once HIPAA is on | Use them, with role-limited access | A |
| SMS, MMS, email bodies and attachments | Listed as covered. LC Email: "There is a signed BAA with Mailgun" | Covered in storage. Message content still follows the minimum necessary rule | A |
| Mobile app (Conversations, Calendars, Contacts) | "Inherit the same encryption & MFA controls" | Allowed; enforce MFA for every user | A |
| Reviews AI | Responses in HIPAA sub-accounts "follow HIPAA-compliant handling" | Allowed; replies still must not confirm someone is a patient | A |
| Conversation AI, Voice AI, Workflow AI, Content AI | Not mentioned in the HIPAA article | No patient data in prompts, knowledge bases or AI actions until HighLevel confirms coverage in writing | Not addressed |
| Webhooks, custom code, exports | Not mentioned | Treat every destination as needing its own BAA | Not addressed |
| Documents & Contracts | Named as the system that generates the BAA paperwork, not as patient document storage | Keep clinical documents in the EHR or a BAA-covered document tool | Partial |
| Uploaded files and media | A user report on HighLevel's ideas board (90 votes, under review since July 2023) says uploads open by link without login, even with HIPAA on. HighLevel has not replied | Do not collect clinical files through form uploads until this is answered | Unconfirmed risk |
| Audit logs | Entries "are retained for 60 days and then purged"; CSV export available | Export monthly and file the CSV | A |
| Deleted contacts | "In HIPAA-compliant accounts, deleted contacts cannot be restored" | No automatic delete actions in workflows | A |
| Data retention settings | HighLevel "does not currently provide customers with the ability to define custom data retention policies" | Write a retention policy and apply it by hand | A |
Grades: A means stated on a HighLevel help page we read. Partial means HighLevel mentions the feature in the HIPAA context but not as storage for patient data. Not addressed means no HighLevel page we found says either way. Not addressed does not mean excluded. It means you should get a written answer from HighLevel before patient data goes there.
How to build each healthcare workflow so it stays HIPAA compliant
Each healthcare workflow has its own HIPAA risk and, for texts, its own TCPA rule. The table is the build sheet we use. The steps for each workflow type are on the linked pages; this table adds the compliance layer on top.
| Workflow | Trigger | What the message may say | Rule that decides it |
|---|---|---|---|
| Appointment reminders | Customer Booked Appointment, with a wait before the start time | First name, practice name, date, time, confirm or reschedule link, STOP line | HHS: reminders are treatment and need no authorization. FCC: exempt texts are 160 characters or less, at most one a day and three a week |
| Intake and consent forms | Appointment booked, or form submitted | "Please complete your forms before your visit: [link]" | Form answers are PHI once stored. The form must live in the HIPAA sub-account |
| No-show recovery | Appointment status changed to No Show | "We missed you today. Want a new time? [link]". Never the reason for the visit | Minimum necessary. Two or three messages, then stop |
| Recall | A due-date field reaching today | "You are due for your next visit with [practice]" | Wellness checkups are on the FCC's exempt list. A promotion for a new paid service is not |
| Review requests | Appointment status Showed, after a delay | A thank-you and the review link. No mention of treatment | Not an exempt healthcare purpose under the FCC rule, so texting needs consent. A public review also shows the person is a patient |
| New inquiry response | Form, call or ad lead | Booking link and practice name | A prospect who types symptoms into a form has just given you PHI. Store it in the HIPAA sub-account |
| Billing and balance reminders | Invoice due or overdue | Amount due and a payment link by email, or text only with consent | The FCC healthcare exemption excludes "accounting, billing, debt-collection, or other financial content" |
| Staff notifications | Any of the above | "New booking for [first name], see the contact record" | Internal emails and texts to staff are disclosures too. Link to the record instead of copying data |
Sources: HHS FAQ 286 on appointment reminders (last reviewed December 28, 2022) and the FCC healthcare exemption at 47 CFR 64.1200(a)(9)(iv) (eCFR, October 1, 2026). Under that exemption a text must go only to the number the patient gave, name the provider and give contact details, offer STOP, and must not be charged to the patient's plan.
How many reminder texts can a HIPAA workflow send?
A healthcare reminder workflow that relies on the FCC's exemption can send one text a day and three a week per patient, each 160 characters or less, with a STOP option in every message. That fits a three-touch reminder sequence if each touch lands on a different day, which is how we schedule it in the timeline below.
The cadence is our recommendation, and the limits it respects are from 47 CFR 64.1200(a)(9)(iv). A workflow that also sends review or recall texts in the same week can push a patient past the cap. Give exempt texts their own tag and check it before any other text goes out.
- Booking dayText 1: confirmation, practice name, STOP line
- Day beforeText 2: reminder with confirm or reschedule link
- Visit dayText 3: final reminder; weekly cap of three reached
- Rest of weekNo more exempt texts; use email or a call
Source: 47 CFR 64.1200(a)(9)(iv), eCFR October 1, 2026 (one a day, three a week, 160 characters). Cadence is our recommendation
How to write patient messages that meet the minimum necessary rule
A patient message meets the minimum necessary rule when it carries only what the task needs, and for most automations that is a first name, the practice, a date and time, and a link. The rule at 45 CFR 164.502(b) asks you to make "reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose". In a workflow, every merge field is a decision under that rule. We keep an allowlist in the build document:
| Merge field or content | In patient texts and email subject lines | Why |
|---|---|---|
| {{contact.first_name}} | Yes | Needed to address the message |
| {{location.name}}, practice phone and address | Yes | The FCC exemption requires the provider's name and contact details |
| Appointment date and time | Yes | The purpose of the reminder |
| Calendar or service name | Only if generic ("Appointment") | A name like "Fertility consult" discloses the treatment |
| Provider name | Only for general practice | A specialist's name can reveal the condition |
| Custom fields with clinical data (reason for visit, medication, results) | No | Not needed for any reminder; keep in the record |
| Last name, date of birth, insurance details | No | Identity details that add risk if the phone is shared |
Email bodies can carry a little more than texts, because HHS says unencrypted email to patients is allowed for treatment communication when you limit "the amount or type of information disclosed" (HHS FAQ 570). We still keep subject lines generic, because they show on lock screens. Wording examples by specialty are on our medical practices page.
What should a workflow do when a patient asks not to be texted?
When a patient asks not to be texted, the workflow must route them to another channel, because HIPAA requires providers to accommodate reasonable requests for communication "by alternative means or at alternative locations" without asking why (45 CFR 164.522(b)). In GoHighLevel we build it like this:
- Create a field. A dropdown custom field, "Preferred contact channel": Text, Email, Phone call, Portal only.
- Capture it. Put it on the intake form, and give front-desk staff a one-click way to change it from the contact record.
- Branch on it. Every patient workflow starts with an If/Else on that field, so one workflow serves all four preferences.
- Set DND to match. Turn on Do Not Disturb for the channels the patient declined. A STOP reply sets SMS DND by itself; a spoken or written request has to be entered by staff, because the FCC rule says consent can be revoked "by using any reasonable method".
- Record the request. Add a note with the date and who took it. The provider may ask for the request in writing; it may not require a reason.
Can you use Zapier, Make or Google Drive in a HIPAA workflow?
You can use an outside tool in a HIPAA workflow only if it signs a BAA with you, because HHS treats any service that stores or processes patient data as a business associate, even if the data is encrypted. HHS's cloud computing guidance limits the "conduit" exception to transmission-only services. An automation tool that runs steps on the data is not a conduit.
| Tool | Signs a BAA? | Source | Use in a HIPAA workflow |
|---|---|---|---|
| Zapier | No | Zapier: "No, Zapier isn't HIPAA compliant" | Only for data with no PHI (for example, an internal "new booking" count) |
| Make | No public BAA offer found | No official Make statement found; a community thread from November 2025 says it does not sign them | Same as Zapier until Make publishes otherwise |
| Google Drive, Sheets, Forms | Yes, under the Google Workspace BAA | Google Workspace HIPAA guide (updated October 26, 2026) | Allowed once the BAA is accepted in the Admin console. Third-party add-ons are not covered, and files should be shared with named people, not "anyone with the link" |
| LC Email (Mailgun) | Covered through HighLevel | HighLevel LC Email FAQ | Allowed with the HIPAA package active |
| Your EHR or practice system | Depends on the vendor | The vendor's BAA | Check before any webhook sends data to it or from it |
Which practice systems actually connect to GoHighLevel, and how, is covered in our healthcare integrations study. For the connection methods themselves, see GoHighLevel integrations and the API guide. A webhook to a HIPAA-covered middleware is usually the clean answer when the EHR has an API.
How to build HIPAA compliant document workflows
A HIPAA compliant document workflow in GoHighLevel tracks the document's status, while the document itself lives in a system covered for clinical files. Because HighLevel's documentation does not confirm patient files are safe in Documents & Contracts or in form uploads, we split the job:
- Patient gets a link
- Document completed in the EHR portal or a BAA-covered tool
- Status sent back (webhook or staff)
- GoHighLevel moves the stage
- Reminder stops
In practice that means GoHighLevel holds a tag or pipeline stage such as "Intake forms received", not the PDF. Claims documents, insurance cards and lab results belong in the billing system or EHR. HighLevel's own ideas board shows fillable HIPAA PDFs with signatures as "in progress" since September 21, 2025, so check its HIPAA ideas page before you design around a feature that may now exist.
Do AI features belong in a HIPAA workflow?
AI features belong in a HIPAA workflow only where HighLevel has confirmed coverage, and as of October 28, 2026 its HIPAA article names one AI feature: Reviews AI. Conversation AI, Voice AI agents on phone lines, Workflow AI and Content AI are not mentioned either way. Until HighLevel confirms them in writing, we build healthcare accounts so the AI only handles booking and general questions, with no clinical details in the knowledge base or prompts and a handoff to staff the moment a patient describes symptoms. Recordings and transcripts from AI calls are treated as PHI. The voice AI chat widget is different: HighLevel says its calls "are streamed only; recording is disabled". More on what the AI tools do in GoHighLevel AI.
How to audit and test a HIPAA workflow before it goes live
Test a HIPAA workflow with a test contact on every branch, read every message it sends as the patient would, and keep the results. The Security Rule requires mechanisms "that record and examine activity" in systems holding ePHI (45 CFR 164.312(b)), and Security Rule documentation has to be kept for six years (164.316(b)(2)(i)). HighLevel keeps audit log entries for 60 days, so the record you need later is the one you export now.
- Run a test contact through every If/Else branch, including each preferred-channel value.
- Read each SMS on a phone: under 160 characters, practice name present, STOP line present, nothing clinical.
- Check the email subject lines on a locked phone screen.
- Confirm the week's exempt texts stop at three for a patient with several bookings.
- List every webhook and outside step and match each to a signed BAA.
- Remove workflow steps that delete contacts. Deleted contacts cannot be restored in HIPAA accounts.
- Limit user roles so front-desk staff do not get export or bulk-action rights they do not need.
- Export the audit log CSV each month and file it with the test results.
The HIPAA Security Rule may get stricter. HHS proposed an update on January 6, 2025 (90 FR 898), and the federal regulatory agenda lists it as a long-term action with a final rule targeted for July 2027 (RIN 0945-AA22). It is a proposal, not a rule, but documented testing and access control are in it, so building them now costs nothing later.
Already running healthcare workflows in GoHighLevel? Our GoHighLevel audit checks each one against this page: message content, channel routing, outside tools and audit exports. You get a written list of what to change. Builds for practices are part of our healthcare clinic setup, quoted in writing (see pricing).
Sources
- HighLevel: HIPAA Compliance With HighLevel (modified June 11, 2026)
- HighLevel: Audit Logs (modified October 12, 2026)
- HighLevel: Restore deleted contacts (modified September 22, 2026)
- HighLevel: Security and Compliance Overview (modified June 16, 2026)
- HighLevel ideas board: exposed media uploads (user report, read October 28, 2026)
- 45 CFR Part 164: 164.502(b), 164.502(e), 164.522(b), 164.312(b), 164.316 (eCFR, October 1, 2026)
- 47 CFR 64.1200: healthcare text exemption and consent revocation (eCFR, October 1, 2026)
- HHS FAQs 286 and 570, and the HHS cloud computing guidance
- Zapier: Is Zapier HIPAA compliant? and Google Workspace HIPAA guide
Frequently asked questions about HIPAA compliant workflow automation
Do appointment reminders need patient authorization under HIPAA?
Appointment reminders do not need patient authorization under HIPAA, because HHS counts them as part of treatment (HHS FAQ 286). Texting them is a separate question under the FCC's rules: the healthcare exemption allows one text a day and three a week, each 160 characters or less, with a STOP option, sent only to the number the patient gave.
Can GoHighLevel workflows send protected health information by text?
GoHighLevel workflows store texts under the HIPAA add-on, but the text itself still reaches the patient's phone over carrier networks, so we send only the minimum necessary: first name, practice, date, time and a link. Clinical details stay in the record or the patient portal. HHS allows limited unencrypted email to patients, and the same caution is the safe reading for texts.
Is Zapier HIPAA compliant for GoHighLevel automations?
Zapier is not HIPAA compliant, by its own statement, and it does not sign Business Associate Agreements. That means a Zapier step must never receive patient names, appointment details or form answers from a healthcare GoHighLevel account. Use it only for data with no PHI, or replace it with a webhook to a tool that signs a BAA.
How long does GoHighLevel keep audit logs?
GoHighLevel keeps audit log entries for 60 days and then purges them, according to HighLevel's Audit Logs article modified October 12, 2026. Logs can be filtered and exported to CSV. For a healthcare account, we export them monthly and file them with the practice's security records, because HIPAA documentation has a six-year retention rule.
Does the HighLevel HIPAA add-on cover Conversation AI and Voice AI?
The HighLevel HIPAA add-on's help article does not say whether Conversation AI or Voice AI agents are covered. The only AI feature it names is Reviews AI. Until HighLevel confirms the others in writing, keep clinical details out of AI prompts, knowledge bases and AI actions, and hand patients to staff when they start describing symptoms.
Can you restore deleted contacts in a HIPAA GoHighLevel account?
You cannot restore deleted contacts in a HIPAA GoHighLevel account. HighLevel's help article says that "in HIPAA-compliant accounts, deleted contacts cannot be restored due to strict data security regulations." For that reason we never put a delete action in a healthcare workflow. Deletion is a manual step that follows the practice's written retention policy.
Can you text a patient who asked to be contacted by email only?
You should not text a patient who asked to be contacted by email only, because HIPAA requires providers to accommodate reasonable requests for alternative communication channels without asking for a reason. In GoHighLevel, store the choice in a preferred-channel field, set DND for SMS, and branch every patient workflow on that field.
What is the difference between HIPAA compliant automation and normal automation?
HIPAA compliant automation runs the same triggers and actions as normal automation, but adds four limits: a BAA covering every system the data touches, message content cut to the minimum necessary, routing that honors patient channel requests, and records of activity kept for review. The workflow builder is the same; the decisions inside each step are not.