Running email sequences inside Salesforce, without a sync

Two ways to build it

Nearly every email sequencing tool that works with Salesforce falls into one of two camps. Neither is right for every org, but they create very different work for whoever looks after Salesforce.

1. An external tool that syncs with Salesforce

The sequencing tool is its own application with its own database. People, sequences, emails and engagement data live there, and a connector copies records between the two systems: people come in from Salesforce, and activity such as emails sent, opens and replies is written back as tasks or custom records.

This approach is mature and widely used, and a standalone app can offer a rich interface of its own. What it asks of an admin:

• Field mappings to set up and maintain in both directions, and to revisit whenever someone adds a field or changes a picklist.
• Activity logging rules: which actions create tasks, on which records, and under whose name.
• API usage. Syncing runs on Salesforce API calls, which count against your org's daily allowance alongside every other integration.
• Duplicate or missing records when the two systems disagree about who someone is, or a record exists in one and not the other.
• A second database of contacts, with its own permissions, its own copy of personal data and its own retention settings to keep in line with Salesforce.

2. A managed package inside Salesforce

The tool is installed into your org as a managed package. Campaigns, steps and sent emails are Salesforce records, so they follow your sharing rules, appear in standard reports and sit on the same Lead or Contact your reps already use. There's no separate contact database to keep in sync.

This approach has trade-offs too. The interface lives inside Salesforce, so it works within Salesforce's look and limits, and the package's records count towards your org's storage. Most packages also rely on an external service for some jobs, such as sending through Gmail or Outlook, tracking opens or spotting replies, so it's worth asking exactly what that service does and what it stores.

What to check before you choose

Whichever way you lean, these questions will save you a painful second implementation.

Permissions model

Who can create sequences, who can enrol whom, and who can see the results? Does access follow your existing profiles and permission sets, or is it a separate user list in another admin console? When someone leaves, how many places do you need to switch them off?

Where data lives

List every place that contact details, email content and engagement data will be stored, including any external servers. Ask about region, retention and deletion. If someone asks to be forgotten, can you remove them in one place?

API limits

Ask the vendor for an estimate of daily API calls at your team's size, and what happens as you approach the limit. You can see your current usage in Setup, under Company Information, before you add anything new.

Who can email whom

Can two reps enrol the same person? Is there a rule that someone can only be in one active sequence at a time? These are the rules that prevent awkward double sends, which we cover in how to stop two reps emailing the same prospect.

Opt-outs

When someone unsubscribes, where is that recorded, and does every sequence check it before sending? Is there a domain blocklist for customers, partners and anyone else nobody should be prospecting?

Security review

Your security team will want the vendor's documentation, the permissions the mailbox connection asks for, how access tokens are stored, who at the vendor can see your data and how incidents are reported. Ask for these early. They take longer than the technical setup.

A simple way to decide

If your reps spend their day in a separate sales app and Salesforce is mainly a system of record, a syncing tool may fit how they already work. If your reps live in Salesforce and you'd rather not maintain a sync, a managed package keeps the work and the data where you already administer them.