Migrate from SendPulse to Salesforce Sales Cloud

SendPulse CRM Contacts map directly to Salesforce Contact records. The Contact's email address is the dedupe key during import. Custom properties on the SendPulse Contact migrate to Salesforce custom fields (__c) with equivalent data types. We resolve the linked Company reference (SendPulse CRM Company) to a Salesforce AccountId before Contact insert so that the Account-Contact relationship is preserved at load time rather than patched afterward.

SendPulse CRM Companies map to Salesforce Account. The company name becomes the Account Name; domain stored in SendPulse becomes the Website field. Account is the parent record for Contact, so we load Accounts first to satisfy the AccountId foreign key on Contact. Account is also the parent for some Deal records, so sequencing matters for referential integrity.

SendPulse Deals map to Salesforce Opportunity. The dealstage property maps to Salesforce StageName, and SendPulse pipeline assignments map to Salesforce Record Types and Sales Processes that we configure before migration. Deal value, close date, responsible user (owner), and custom fields migrate directly. We use SendPulse's pipeline stage order to set up the destination Sales Process with matching stage probabilities.

SendPulse CRM Tasks migrate to Salesforce Task records. Title, due date (ActivityDate), status, priority, and linked contact or company reference migrate with the WhoId and WhatId resolved to the corresponding Salesforce Contact and Account IDs. Task assignment migrates by matching the SendPulse responsible user email to the Salesforce User record.

SendPulse Mailing Lists and their Subscribers require a structural decision at migration time. We map each Mailing List to a Salesforce Campaign and each Subscriber to a CampaignMember linked to that Campaign, preserving the subscription status (active, unsubscribed, bounced) as CampaignMember Status. This preserves historical send-list data. If the customer plans to use Salesforce for ongoing sales process rather than email marketing, we alternatively map Subscribers directly to Contacts without Campaign membership, and document the alternative as a scoping decision.

SendPulse Subscribers that originated from CRM contacts rather than pure marketing lists are mapped to Salesforce Contact records with subscription status stored in HasOptedOutOfEmail and a custom field sp_subscription_status__c carrying the original SendPulse status value. This distinguishes CRM-contacts from pure marketing-only subscribers.

Automation 360 flows cannot be exported via API or any bulk mechanism. We capture each active flow by walking through the UI and documenting the trigger (event type, conditions), each step (action type, delay, branching logic), and the goal of the flow in a written rebuild guide. The guide references Salesforce Flow equivalents (record-triggered Flow, Scheduled Flow, or Flow Builder) for each step. The customer admin or a Salesforce partner rebuilds flows post-migration. This is manual work and must be budgeted separately.

SendPulse campaign results (open rates, click rates, bounce data, unsubscribe counts) are exported as structured CSV and imported into a custom Salesforce object Campaign_Stats__c linked to the corresponding Campaign record. These are treated as historical reference records, not as live Salesforce Campaign statistics. We flag that SendPulse's recorded statistics may underrepresent true deliverability because moderation pauses and blocked sends are not always reflected in the logged data.

SendPulse CRM Products (name, price, SKU, category) map to Salesforce Product2 records with Standard Pricebook entries created during import. The hidden SendPulse Integration fields (POS IDs, payment gateway metadata stored in String/Number type, up to 255 characters) are accessed via targeted API call using the product endpoint with the integration_fields parameter and written as custom properties (sp_integration_field__c) on the Product2 record. This step must be explicitly requested during scoping as it is not part of the standard export UI.

SendPulse sender addresses (verified SMTP senders tied to campaigns) must be re-verified in Salesforce. We document each SendPulse sender address with its From Name, From Email, and reply-to configuration so the customer's Salesforce admin can set up matching Salesforce domains or individual email addresses in Setup > Deliverability. This is a manual re-verification step; Salesforce requires Domain Verification or individual email address confirmation before sending.

SendPulse CRM users referenced on Contact, Company, Deal, and Task records are matched to Salesforce User records by email address. Owners without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before record import resumes. OwnerId references on Opportunities and Tasks are required fields and block import if unresolved.

SendPulse Course Builder student records (enrollment, progress, completion) are exportable individually. We map student records to a custom Salesforce object Course_Enrollment__c linked to the Contact record, preserving enrollment date, lesson progress, and completion status. Course content (video, text) resides on SendPulse's platform and does not migrate; we document the course structure so the customer can plan a rebuild in an LMS or Salesforce Experience Cloud if needed.