Event: subscription.cancelled · Destinations: Intercom, Salesforce, Slack
The problem
A cancellation signal trapped in your billing system is too late by the time it reaches customer success manually. RevOps wants the revenue context, support wants the reason, and lifecycle teams want the signal in Intercom fast enough to start offboarding or a win-back flow.
Teams often patch this together with one CRM webhook, one Slack notifier, and one internal job that writes churn data somewhere later. The result is inconsistent timing and conflicting data across tools exactly when the account is most at risk.
If the cancellation event fails to reach one destination, the customer record stays stale, the alert never lands, and your churn analysis has holes in it. This is where delivery guarantees matter, not just basic webhook forwarding.
The event flow
Each use case follows the same product story: Meshes receives the source event once, maps it to the right destinations, and keeps delivery visible when downstream APIs fail.
Event payload
{
"customer_id": "cus_5501",
"subscription_id": "sub_5501",
"email": "sam@bluebird.app",
"plan": "pro",
"reason": "missing_salesforce_sync",
"cancellation_date": "2026-03-20",
"mrr_lost": 249,
"tenure_months": 14
}Intercom
Meshes tags the user so win-back or offboarding sequences can branch on cancellation state.
Lifecycle messaging starts from the real cancellation event instead of an export or support note.
Salesforce
Meshes updates cancellation reason, MRR impact, and date fields in Salesforce.
CS and RevOps can prioritize outreach and analyze churn with current revenue context.
Slack
Meshes sends a structured alert to #cs-alerts with plan, reason, tenure, and MRR lost.
The team sees churn signals in real time instead of after someone refreshes a report.
How Meshes handles it
Instead of maintaining separate workers, retry logic, and visibility per destination, Meshes gives you one event path, destination-aware routing, and built-in delivery guarantees.
From your product
import MeshesEventsClient from '@mesheshq/events';
const meshes = new MeshesEventsClient(
process.env.WORKSPACE_PUBLISHABLE_KEY!,
);
await meshes.emit({
event: 'subscription.cancelled',
resource: 'subscription_plan',
resource_id: 'pro',
payload: {
customer_id: 'cus_5501',
subscription_id: 'sub_5501',
email: 'sam@bluebird.app',
plan: 'pro',
reason: 'missing_salesforce_sync',
cancellation_date: '2026-03-20',
mrr_lost: 249,
tenure_months: 14,
},
});Across destinations
On every delivery
Why this matters
If the right team sees the cancellation immediately, you have a chance to recover the account or at least understand the churn reason while context is still fresh.
Slack needs a human alert, Salesforce needs structured revenue fields, and Intercom needs segmentation. Routing one event cleanly keeps those views consistent.
Cancellation routing should not be a black box. Meshes makes it clear which downstream system received the signal and which one needs attention.
Related
Docs
See the same event-routing pattern behind this cancellation workflow.
Open linkDocs
See how Meshes routes one cancellation signal to multiple downstream systems.
Open linkIntegration
Apply tags so lifecycle and support messaging can react to churn signals.
Open linkIntegration
Update revenue and cancellation context inside Salesforce from event-driven rules.
Open linkIntegration
Send churn alerts directly into the channel your CS team monitors.
Open linkBlog
See how cancellation signals can route to different destinations based on the event itself.
Open linkCompare
Compare observable churn routing with maintaining cancellation workers and queue logic yourself.
Open link