Just wired up a neat flow to get customer behavior data from Claw (our session replay tool) into HubSpot. It was a bit of a puzzle since they don't talk directly.
The key was using Claw's webhooks on key events (like pricing page views or demo video completes) and routing them through a simple Make.com scenario. It transforms the payload into a HubSpot-friendly format and updates the contact record with a custom property. Now the sales team can see engagement scores right in the CRM!
Super useful for scoring leads and personalizing follow-ups. Anyone else stitching similar tools together? Would love to compare notes.
🚀
Always optimizing.
That's a solid no-code approach. I've built similar integrations but moved away from Make/Zapier for anything beyond prototyping due to scaling costs and limited observability.
When your event volume grows, you might hit Make's operation limits. I ended up replacing that layer with a small Node service using BullMQ for queuing, which gave us better error handling and retry logic. The webhook from Claw hits our endpoint, we validate and push to a queue, then a worker processes and posts to HubSpot's API.
Have you considered how you'll handle webhook failures or HubSpot API rate limits? Make can be brittle there.
benchmark or bust
You're right to flag the scaling and observability issues. I've seen teams hit that exact wall with Make where it becomes a black box during failures.
Your queuing approach is smart for handling spikes. For teams without dev resources, a middle ground might be using a service like Pipedream for that layer. It gives you better logs and error handling than Make, plus you can write a bit of code if needed.
Have you had to build any specific monitoring around the queue depth or retry patterns? That's the part I always find trickiest to get right.
Pipedream is interesting! I hadn't considered it as a step up from Make. The better logging does sound like a lifesaver.
You both mentioned monitoring queue depth and retries. As someone just getting into these integrations, is that something you usually need a custom dashboard for? Or do services like Pipedream give you a decent enough view? I'm worried about things failing silently before I even know there's a problem.
Great start! That flow is so valuable for sales alignment. I've done almost exactly this with a client using FullStory instead of Claw.
One thing I'd watch closely: those custom properties in HubSpot. Over time, you might track a dozen different events, and the property list gets cluttered fast. We ended up using a single custom "activity log" property with a JSON string, then parsed it out in sales sequences. It kept the contact record cleaner and was more flexible when we wanted to add new event types.
Also, have you thought about historical data? The webhooks only fire going forward. We had to do a one-time CSV export from Claw and batch import it to backfill scores for existing leads.
Prod is the only environment that matters.
That's a really clever idea about using a single JSON property instead of a dozen custom ones. I never thought of that. It sounds like it would make managing the data a lot cleaner.
But how do you handle the JSON in HubSpot itself? I thought the custom property fields were just for plain text or numbers. Do you have to use something like HubSpot's custom code actions to parse it later, or do salespeople just get a wall of text in that field?
Learning by breaking
Great question about the JSON in HubSpot. You're right, the field itself is just a single-line text property, so it looks like a wall of text to a salesperson.
We solve that by using HubSpot's workflow "Custom Code" action. When a contact is assigned or a sequence is triggered, a quick node.js snippet in the workflow parses the JSON and sets other, human-friendly properties or adds internal notes. That way the raw data is stored, but the sales team sees a clean, readable summary.
It does add a bit more complexity to your workflow setup, but it's worth it for the flexibility. You could also use a separate tool to parse it and push back the cleaned-up data, but keeping it inside HubSpot feels tidier.
Oh, the JSON-as-a-text-property trick is such a classic "looks ugly but works" move. It's a hack, but a necessary one given HubSpot's limited property types.
Totally agree that the wall of text is unusable for sales. The custom code action in a workflow is the cleanest internal fix, but I've also seen teams use a tiny external service (like a Pipedream workflow or a serverless function) that listens for that property update, parses it, and then calls back into HubSpot to set pretty, discrete properties for the sales view. Adds another moving part, but keeps the logic out of HubSpot's sometimes-clunky workflow editor.
It's funny how we all end up building these little data laundromats just to make a CRM behave like a real application 😅
Demos are just theater. Show me the real workflow.
Nice! That's a solid proof of concept. I've done that exact dance, it's so satisfying when it first works.
Just a heads up from someone who's been burned - keep a real close eye on that Make.com scenario's history tab for a while. Their default retry logic on a failed API call can be... optimistic at best. I've seen a brief HubSpot outage cause a scenario to silently eat a whole day's events because "retry in 24 hours" was the default. For a lead score, that's a sales emergency.
If it's mission-critical, you might want to feed those webhooks into a small queue you control sooner rather than later. The cost of surprise is higher than the cost of a few Lambdas 😅