Syncing HubSpot and AlayaCare Without Storing Health Data
A national privacy law barred an aged care provider from storing health information inside its CRM, but sales staff needed it captured the moment a prospect was ready. We built a hosted middleware form that forks each submission: sensitive fields go to AlayaCare and a local database, non-sensitive fields go to HubSpot, linked by ID.
Executive Summary
Context
A not-for-profit aged care, home care and retirement living provider ran sales in HubSpot but managed clinical records in AlayaCare. Every prospect needed a CRM record sales could work and a compliant case file care managers could act on.
What We Built
We built a hosted intake form that forks each submission at capture: health and care-plan fields go straight to AlayaCare, name and lifecycle fields go to HubSpot, and a PDF attaches to the AlayaCare record for staff without CRM access.
Tech Stack
- PHP 8
- MySQL
- HubSpot CRM
- AlayaCare External API
- AlayaCare External Files API
Not a fit if your organisation doesn't have an internal team capable of hosting a custom application, since this hands sensitive-data handling to a script your IT staff run, not a vendor connector. It also assumes the receiving system exposes a real API for records and attachments.
The Challenge
Sales reps worked every prospect inside HubSpot, but home care enquiries often included data that the CRM couldn't safely store: health conditions, hazards and care-plan detail protected under Australia's Privacy Act 1988. Native webhooks and custom code needed a higher hub tier the provider lacked, so the fork logic could not run inside the CRM.
AlayaCare exposed an external API and a files API, but the files API didn't have a notes field. And because the platform didn't retain history, later resubmissions were overwriting data that was already there.
Our Approach
We considered four hosting options: a vendor-run connector, HubSpot custom code on a higher hub tier, a Google Forms and Zapier bridge, and a standalone script on the provider's own server. The higher-tier option cost too much in licence fees, and Google Forms and Zapier were dismissed once IT confirmed it could host a custom application. The standalone script won: a PHP 8 and MySQL middleware layer that gets triggered when a rep marks a prospect ready for a first face-to-face meeting.
Sensitive fields write to the local MySQL table and to AlayaCare's external API; non-sensitive demographics reach both systems. The HubSpot contact ID stores on the AlayaCare record as a reference field, and AlayaCare's internal ID writes back, so that records get deduplicated on resubmission.
Because AlayaCare's files API has no notes field, every submission renders a PDF for the care managers who don't have HubSpot seats. Punch testing found the trade-off: AlayaCare keeps no field history, so a blank field on resubmission overwrites a correct value.
Impact
Sensitive health data reaches the care team without touching the CRM
The intake fork keeps health conditions, hazards and care-plan detail on the provider's own server and inside AlayaCare, so the CRM never stores regulated health information that it isn't licensed to hold. Sales reps capture everything in one form, because the split happens automatically.
Care managers read the full intake without a HubSpot login
A PDF of every submitted field attaches to the AlayaCare record the moment the form is sent, so care managers who don't have HubSpot seats get the same detail a rep captured, not a re-typed summary. That removed a manual handoff and its errors.
One entry point on the HubSpot contact record itself
The intake form opens from a custom card on the HubSpot contact record, so a rep working a deal never leaves the CRM to start the compliance-safe capture. That entry point carries the contact's HubSpot ID into the form, populating the AlayaCare join key.
An architecture the provider extended when funding rules changed
When a funding reform changed which fields intake had to capture, the provider extended the same form and fork rather than starting over, adding classification and approval fields. The open defect from punch testing, where a blank field overwrote a value on resubmission, has been flagged and is scheduled to be fixed.
The intake form splits on submission: health, hazard and care-plan fields write only to the provider's MySQL table and to AlayaCare, while contact and lifecycle fields write to both AlayaCare and HubSpot. This logical partitioning keeps sensitive fields out of the CRM.
The HubSpot contact ID writes to AlayaCare as a reference field on creation, and AlayaCare's internal ID writes back once the record exists. A later submission checks that stored ID, so that the existing record gets updated instead of a duplicate being created.
AlayaCare's files API accepts attachments but doesn't expose an authorised notes field, so the custom API layer renders the form to a PDF and attaches it through that API. Care managers open the PDF instead of a notes tab the platform doesn't have.
A custom card on the HubSpot contact record is the only way a rep opens the intake form, keeping the compliance-safe path the fastest one. The card carries the contact's HubSpot ID into the form, populating the AlayaCare join key.
A rep marks a prospect ready for a first face-to-face meeting and opens the intake form from a custom card on the HubSpot contact record. The form, a PHP 8 and MySQL application on the provider's own server, decides where each field goes: health, hazard and care-plan fields go only to the local MySQL table and AlayaCare's external API, while name, contact and lifecycle fields also go to HubSpot. It then renders the full submission as a PDF and attaches it to the AlayaCare case record through the files API. AlayaCare returns its internal ID to the HubSpot contact, so a later submission updates the record instead of duplicating it.
FAQ
The intake form decides what each field is before anything is sent. Health, hazard and care-plan fields write only to the provider's database and to AlayaCare; everything else also writes to HubSpot. HubSpot never receives the regulated fields.
Care managers don't need HubSpot access, because every submission generates a PDF and attaches it to the AlayaCare record through AlayaCare's files API. That gives them the same detail a rep captured.
