Handling 5k Salesforce case emails / week reliably
How we designed the path from a Salesforce support case to the right HubSpot transactional email — and back, so every send leaves a delivery record on the case it came from.
The company works in renewable energy: it monitors and maintains equipment installed at customers' properties, on behalf of the businesses that hold the service contracts.
Around five thousand Service Cloud cases a week, many of them opened automatically — the monitoring platform notices equipment has stopped reporting, and a case exists before the customer knows anything is wrong.
Every one of those cases needs a message to go out.
The question was how to send that many reliably, with each message driven by the parameters the case already carries, and keep license costs manageable while doing it.
Two things turned out to be the real work:
Step 1: Multiple scenarios, and the what-ifs
Equipment down, scheduled maintenance, a request for property access, an advance warning: each case type wants a different message, with different content, at a different point in the life of the case.
The job isn't sending. It's resolving which template applies, filling it with the right values from the case, and firing it at the right moment.
At five thousand cases a week, getting that choice wrong on even a small fraction means hundreds of customers receiving the wrong message.
So the design puts the decision in one place. A case event fires a native Salesforce action. A small Cloudflare Workers layer picks it up, resolves which template and which variables apply, and sends through HubSpot — where the templates are built by the people who already build the company's customer-facing email, in the tool they already use.
Three ways a send is triggered: immediate, for events that fire on their own; manual, the moment someone changes a status in the Salesforce UI; and scheduled, on a fixed interval — which exists because when one upstream fault opens dozens of cases at once, sending per case turns into a flood of near-identical messages. The interval collapses them into one.
Step 2: Auditability and verified reads
Today a broken address fails silently. Nobody knows whether a customer received a critical notice — no opens, no clicks, no way to tell if a message landed in spam.
That matters twice over in this business model.
Contractually, because the businesses that pay them require visibility into how end customers are contacted, surfaced on the case record. Logging deliverability isn't a reporting nicety here; it satisfies an obligation that already exists.
And as protection, because the company sends advance warnings when conditions will reduce equipment performance. If a customer later disputes that performance, the defense is a record that the warning was sent and opened — not a belief that something went out.
So the design closes the circle. Opens, clicks and bounces come back on a schedule and are written to Salesforce, threaded onto the case that started it — sitting in the same activity history as anything a service agent typed by hand.
No public endpoint is exposed: the trigger uses Salesforce's own native actions rather than standing up an internet-facing URL. And customer data never leaves Salesforce — the Cloudflare Workers layer holds case metadata only, enough to reconnect a send to its case when metrics return. No message bodies, no customer records.
A license that did more than required
The vendor’s answer was a full license for about a tenth of its features.
Deliverability nobody could see
A broken address fails silently, and a contractual obligation depends on it not doing that.
Customer data that stays in the CRM
The middleware holds case metadata only — no message bodies, no customer records.
Every email sent, on the case it came from.
Each case type gets the message written for it, rather than one generic notice stretched across every situation.
Every case carries a delivery record, so "did the customer get it?" stops being a question nobody in the company can answer.
The contractual obligation to the businesses that pay them is satisfied by the case record itself, rather than by a separate report someone assembles.
Advance warnings become defensible. A disputed performance claim meets a record that the notice was sent and opened.
One upstream fault stops producing a flood of near-identical messages to the same customers.
And the people who write the company's customer-facing email write these too, in HubSpot, where they already build its campaigns — no engineering ticket to change a sentence.
Data problems shaped like this one?
If some of this reads like your situation, say which part. Datsugi replies within 2 business hours, guaranteed (CET).
Arrigo Lupori
Founder & Managing Director