account.plan_changedpayment.failedchurn.risk_changed|Actionsadd_to_campaignremove_from_campaignupdate_propertyThe event names shown here are examples. In Meshes, event types are fully customized for each organization.
What you can do
Create the Salesforce connection in your Meshes workspace with OAuth. Meshes then loads the campaigns and properties available to that Salesforce account so rules can stay tied to real CRM objects.
Salesforce is where pipeline, account health, and customer follow-up often become operational. When account.plan_changed or payment.failed happens in your product, that context needs to land in Salesforce quickly enough for the downstream process to react.
Meshes lets you keep Salesforce wiring in the delivery layer instead of sprinkling CRM writes across billing jobs, admin tooling, and lifecycle workers. You define the rule once in Meshes, map the event data to the campaign or property you care about, and let Meshes handle the delivery path.
add_to_campaignUse product qualification, onboarding, or expansion events to place the right contacts into Salesforce campaigns for follow-up and reporting.
remove_from_campaignStop the wrong follow-up path when the event means the user converted, churned, or moved into a different motion.
update_propertyWrite plan, health, qualification, or revenue context into Salesforce so the CRM reflects the latest state from your product.
Common use cases
These are the workflows where this destination tends to matter first. The point is to keep the product event, the destination action, and the operational retry path in one place.
Use account.plan_changed to keep Salesforce fields current when customers upgrade, downgrade, or move between contract states.
Surface payment.failed or risk-scoring events in Salesforce so customer teams can react before the account goes cold.
Add or remove contacts from campaigns when enterprise leads, onboarding milestones, or expansion signals happen in-product.
Let support, sales, and success see the same product signal in Salesforce without waiting for a manual sync to close the gap.
How it works
In Meshes, the operating model is simple: create the connection in the workspace, create the rule, then let the event delivery layer handle the last mile.
Create a Salesforce connection in Meshes with OAuth and confirm the campaigns and properties you want to use are available in the connection action data.
Create rules for events like account.plan_changed or payment.failed, choose add_to_campaign or update_property, then map the event fields that Salesforce needs.
Emit the event from your product or trigger Send Test Event in Meshes. Meshes delivers the CRM update, retries transient errors, and records the attempt history for review and replay.
Event example
import MeshesEventsClient from '@mesheshq/events';
const meshes = new MeshesEventsClient(
process.env.WORKSPACE_PUBLISHABLE_KEY!,
);
await meshes.emit({
event: 'account.plan_changed',
resource: 'account',
resource_id: 'acct_913',
payload: {
account_id: 'acct_913',
email: 'owner@northstar.io',
previous_plan: 'starter',
current_plan: 'growth',
monthly_recurring_revenue: 499,
},
});Connection model
Create the Salesforce connection in your Meshes workspace with OAuth. Meshes then loads the campaigns and properties available to that Salesforce account so rules can stay tied to real CRM objects.
Why Meshes
The benefit is not just that the destination is supported. It is that the destination sits inside the same fan-out, retry, replay, and delivery-visibility layer as the rest of your stack.
Instead of asking billing code or admin jobs to know Salesforce, Meshes turns the product event into the CRM update with one dedicated delivery path.
The same event can move contacts into the right campaign and update the properties downstream automation depends on.
A missed Salesforce write can become a missed customer conversation. Meshes keeps the attempt visible, retryable, and replayable.
Your app can emit the account event once and let Meshes absorb Salesforce auth, action data, and delivery concerns separately.
Keep exploring
These links are the next layer down: concrete patterns, supporting documentation, and the build-vs-buy context that usually comes up during evaluation.
Catalog
Return to the catalog and compare Salesforce with other CRM, messaging, and email destinations.
Open linkDocs
See the Salesforce connection, rule configuration, and testing flow in the product docs.
Open linkUse Case
See how lifecycle and risk events can update the systems that customer teams already rely on.
Open linkUse Case
See how payment.failed can reach CRM, support, alerts, and email from the same product event.
Guide
Use account.plan_changed to keep the Salesforce record aligned with the current subscription state.
Compare
See what it costs to build Salesforce fan-out, retries, and replay into your own product code.
Open linkaccount.plan_changed once, let Meshes update Salesforce campaigns and properties, and keep customer teams working from live product context.