• Use Cases
  • Pricing
  • Security
  • Docs
Sign InStart free

The outbound integration layer for SaaS products: emit once, then let Meshes handle routing, retries, fan-out, and delivery history.

© Copyright 2026 Meshes, Inc. All Rights Reserved.

About
  • About
  • Security
  • Blog
  • Contact
  • FAQ
Product
  • Pricing
  • Demo
  • Integrations
  • Guides
  • Changelog
  • Status
Compare
  • All comparisons
  • Build vs buy
  • vs Zapier
  • vs Make
  • vs n8n
  • vs Paragon
  • vs Merge
Use Cases
  • All use cases
  • Payment failed
  • User signup fan-out
  • Churn prevention
  • Trial expired events
  • Lesson completion flows
  • Page completion triggers
  • Page visit Intercom flows
Developers
  • Documentation
  • Agents
  • API Reference
  • MCP Server
  • llms.txt
Legal
  • Terms of Service
  • Privacy Policy
  • Acceptable Use Policy
  • Cookie Policy

IntegrationCRM destination

Salesforce logoSalesforce Integration - Route Product Events to Salesforce

Meshes routes product events into Salesforce through campaign membership and property updates. That gives sales, success, and RevOps a cleaner path from product activity to CRM action without tying your application code to Salesforce availability.

Start freeView documentation
DestinationSalesforce|AuthenticationOAuth|Example eventsaccount.plan_changedpayment.failedchurn.risk_changed|Actionsadd_to_campaignremove_from_campaignupdate_property

The event names shown here are examples. In Meshes, event types are fully customized for each organization.

What you can do

Supported actions with real product context behind them

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_campaign

Add contacts to campaigns

Use product qualification, onboarding, or expansion events to place the right contacts into Salesforce campaigns for follow-up and reporting.

remove_from_campaign

Remove contacts from campaigns when state changes

Stop the wrong follow-up path when the event means the user converted, churned, or moved into a different motion.

update_property

Update Salesforce contact properties

Write plan, health, qualification, or revenue context into Salesforce so the CRM reflects the latest state from your product.

Common use cases

How Meshes teams usually put Salesforce to work

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.

Keep plan and account-state changes visible to RevOps

Use account.plan_changed to keep Salesforce fields current when customers upgrade, downgrade, or move between contract states.

See the plan-change guide

Push churn or billing risk into the CRM quickly

Surface payment.failed or risk-scoring events in Salesforce so customer teams can react before the account goes cold.

See the churn-prevention use case

Drive campaign membership from product qualification

Add or remove contacts from campaigns when enterprise leads, onboarding milestones, or expansion signals happen in-product.

Avoid stale CRM context during customer handoff

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

Connect the destination, define the rule, emit the event

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.

1

Connect Salesforce

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.

2

Create routing rules in Meshes

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.

3

Emit the event and review delivery

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

Emit the product event once

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

OAuth

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

Why teams use Meshes for Salesforce

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.

CRM updates stay close to the source signal

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.

Campaign membership and field updates can coexist

The same event can move contacts into the right campaign and update the properties downstream automation depends on.

Retries matter more when the CRM drives follow-up

A missed Salesforce write can become a missed customer conversation. Meshes keeps the attempt visible, retryable, and replayable.

You keep CRM coupling out of product handlers

Your app can emit the account event once and let Meshes absorb Salesforce auth, action data, and delivery concerns separately.

Keep exploring

Related guides, use cases, docs, and comparison pages

These links are the next layer down: concrete patterns, supporting documentation, and the build-vs-buy context that usually comes up during evaluation.

Catalog

All integrations

Return to the catalog and compare Salesforce with other CRM, messaging, and email destinations.

Open link

Docs

Salesforce integration docs

See the Salesforce connection, rule configuration, and testing flow in the product docs.

Open link

Use Case

Churn prevention event routing

See how lifecycle and risk events can update the systems that customer teams already rely on.

Open link

Use Case

Payment failed notifications

See how payment.failed can reach CRM, support, alerts, and email from the same product event.

Open link

Guide

Update Salesforce on plan change

Use account.plan_changed to keep the Salesforce record aligned with the current subscription state.

Open link

Compare

Meshes vs. DIY

See what it costs to build Salesforce fan-out, retries, and replay into your own product code.

Open link

Next stepStart free, read the docs, or browse the catalog

Start routing product events to Salesforce

Emit account.plan_changed once, let Meshes update Salesforce campaigns and properties, and keep customer teams working from live product context.

Start freeView documentationSee all integrations