This is general operational guidance, not legal, clinical or regulatory advice.
Here's a failure I see more often than I'd like. A patient completes an assessment. HubSpot creates the record, generates the document and sends the email to the clinic. Every step shows green. The clinic never sees it.
Nobody finds out until the patient rings two days later asking why they haven't heard back. By then you have an unhappy patient, a confused clinic and a workflow history that says everything worked.
This is a process-design problem, and email is only one place it shows up. The fix is to design telehealth workflows around delivery states and exceptions, then build the happy path on top.
When a HubSpot workflow action completes, you have proof that a configured action ran. You don't have proof that the clinic got what it needed. Delivery can still fail because of an invalid address, filtering, a third-party API, attachment rules, permissions, timing or an unhandled error further down the line.
So for every important patient or clinic communication, write the outcome in plain language. For example: "The clinic received the assessment, can open it and knows what to do next." Then model the states you need to prove it.
The front door fails in messy ways too. A patient presses Submit and sees an error. Their connection drops. The browser times out after the clinic system has already accepted the record. Or they give up halfway through a long assessment and nobody knows.
The risk in each case is uncertainty. Did the clinic get the information? Should the patient try again? Will a second attempt create a duplicate? A simple submitted or not-submitted flag can't answer those questions, so give the uncertain case its own state.
Start with one record. The patient's contact record holds the context. A related assessment or service request record holds its own operational state. Don't treat the email timeline as the source of truth.
A workable set of states:
Record a timestamp for each change, the system that made it, and a reason code when something fails. That gives you a usable audit trail without putting clinical decisions inside the automation. If your records are already crowded, look hard at what the CRM is telling you before adding more fields.
Most workflow diagrams show what happens when every step works. In production, the exception path deserves at least as much design time. A pattern that works:
HubSpot gives you some of the raw material. The workflow details page includes action logs you can filter for errors, such as an email that failed to send. That's useful for diagnosis. Someone still has to be accountable for acting on it, which is why the exception queue matters.
A timeout doesn't prove a failure. Before anyone tells a patient to submit again, check the destination system and the record for a successful arrival. If it's already there, a second attempt can create duplicates, repeat notifications and conflicting documents.
The sequence:
An exception alert usually needs a timestamp, a non-sensitive error category, a record reference and enough routing detail for the right team to investigate. It shouldn't copy health answers into routine alerts or shared channels.
Split the routes, too. The clinic may need identifiable details so an authorised person can follow up. A technology supplier usually needs only the error code, software version, device type and timing. Send each party what it needs, and nothing extra.
This also helps with what's coming. From 10 December 2026, the Privacy Act will require organisations to explain in their privacy policy when computer programs are used to make, or substantially and directly inform, decisions that could significantly affect people. The OAIC has published resources on automated decision-making transparency to help. Knowing exactly what each workflow does with personal information makes that job far easier.
A bounded agent can take real load off the team when its tools, data and actions are clearly limited. In a telehealth setting it can:
It must not diagnose, interpret pathology, recommend treatment or prescribe. The TGA's guidance on clinical decision support software is a useful reminder that software supporting clinical decisions can fall under medical device regulation. Named clinicians keep every clinical decision, and people approve anything that could materially affect a patient.
A lot of "did you get my form?" calls disappear when patients can sign in and see where things stand: assessment received, documents received, appointment booked, payment received, action needed, support requested. The portal should show administrative status only. It should never present an automated clinical conclusion.
You don't need to rebuild everything. Pick the one flow where a silent failure would hurt most, usually intake or assessment hand-off, and map where proof of delivery is missing. Reliable automation comes from a few well-understood workflows. Five good ones will beat fifty fragile ones.
If your team only finds failures when a patient or clinic chases you, talk to us about telehealth. We'll map one flow with you, find the silent failure points and design the exception path with people kept in control.