Migrate from SendPulse to Twenty CRM

SendPulse CRM Contacts map directly to Twenty Person records. The first_name, last_name, email, phone, and custom properties migrate as standard and custom fields on Person. SendPulse's contact avatar URL migrates as a custom text field. We deduplicate by email address during the extract phase and flag duplicate SendPulse contacts (same email, different IDs) for the customer's review before import into Twenty. Any SendPulse contact with a linked Company record gets the Company-_person link preserved via the Twenty relationship model.

SendPulse CRM Companies map directly to Twenty Company records. Company name, domain, address, industry, and custom fields migrate 1:1. The company domain is used as a dedupe key and populates the Company URL field in Twenty. SendPulse's company-contact linkage migrates as a primary contact relation in Twenty's data model. Companies without contacts are imported as standalone records.

SendPulse Deals map to Twenty Opportunities. The deal name, value, stage, responsible user, and custom fields migrate to Twenty's Opportunity object. SendPulse pipeline stages map to Twenty pipeline stages, which we configure in Twenty's Data Model before migration. Closed-won and closed-lost reasons from SendPulse custom fields become custom text fields on the Opportunity in Twenty.

SendPulse CRM Tasks map to Twenty Task records. Task title, due date, assignee, status, and linked contact or company migrate directly. The linked entity reference (contact_id or company_id) is resolved to the corresponding Twenty Person or Company record ID during the transform phase. Open tasks migrate with their original due dates preserved; completed tasks migrate with completion timestamps.

SendPulse Subscribers from the email marketing module are distinct from CRM Contacts. We extract subscribers with their subscription status (subscribed, unsubscribed, bounced) and segment membership, then map them as Person records in Twenty tagged with the original mailing list name and a subscription_status field. Bounced and unsubscribed addresses are imported with their status preserved as custom fields. Active subscribers from mailing lists that are also in the CRM become merged with existing Person records; mailing-list-only subscribers are imported as new Person records with a custom source field set to SendPulse mailing list.

SendPulse campaign statistics (open rate, click rate, bounce count, unsubscribe count per campaign per subscriber) are extracted as structured records and written to Twenty as custom number or text fields on the corresponding Person record. For aggregate reporting, we create a custom CampaignHistory object in Twenty linked to Person, capturing campaign_id, send_date, opens, clicks, and bounces. This preserves historical performance data that SendPulse exports to CSV.

SendPulse verified sender addresses (SMTP senders used for campaigns) are platform-specific and tied to SendPulse's sending infrastructure. They cannot be transferred to Twenty because Twenty does not include an email sending module. We document every verified sender domain and address for the customer's reference so they can configure DNS records (DKIM, SPF, DMARC) for their chosen email sending provider (Resend, AWS SES, Postmark) in parallel with the CRM migration.

SendPulse CRM Products (name, price, SKU, category, and hidden integration fields) map to Twenty as a custom object named Product if the customer tracks products independently of opportunities. We extract hidden integration fields via the targeted API call with the integration_fields parameter and write them as custom text fields on the Product custom object. If the customer uses products within deal contexts, we recommend a Product custom object linked to Opportunity rather than Twenty's built-in opportunity line item model.

SendPulse Automation 360 flows have no API export endpoint. Flow definitions exist only in the SendPulse UI and cannot be programmatically extracted. We provide a written inventory of every active Automation 360 flow documenting its trigger, conditions, delay steps, and actions based on screenshots and walkthroughs with the customer. The customer's admin rebuilds each flow in Twenty Workflows post-migration. Complex multi-branch flows may require significant reconfiguration time in Twenty.

SendPulse chatbots (Telegram, Facebook Messenger, Instagram, WhatsApp, TikTok, Viber) cannot be exported via API. Chatbot flow logic, trigger conditions, and message content are stored on SendPulse's platform and tied to their messenger integrations. We document the messenger channels in use, the primary use cases (lead capture, FAQ automation, order tracking), and recommend a replacement chatbot platform (ManyChat, Tidio, or native messenger developer tools) to be configured separately from the CRM migration.

SendPulse CRM owners (assigned users on contacts, companies, deals, tasks) map to Twenty Workspace Members. We resolve SendPulse owner email addresses against the Twenty destination workspace's member list. If a SendPulse owner has no matching Twenty account, we hold the assignment in a reconciliation field and flag it for the customer to provision the corresponding Twenty user before record import. Active vs inactive status is preserved.