Migrate from Rule to Salesforce Sales Cloud

Rule Contacts map to Salesforce Lead or Contact based on lifecycle stage. Contacts with a lifecycle stage indicating an unqualified prospect (subscriber, lead, marketing qualified) map to Salesforce Lead. Contacts with sales qualified, opportunity, customer, or evangelist stage map to Salesforce Contact tied to an Account. We preserve the original Rule lifecycle stage in a custom field rule_original_lifecycle__c on both Lead and Contact for audit. Channel preferences (email, SMS, RCS, social opt-in) migrate to HasOptedOutOfEmail and equivalent custom fields per channel.

Rule Company records map directly to Salesforce Account. The Rule company domain becomes the Account Website field and is used as the dedupe key during import. Account is created before any Contact import so that the Lookup relationship is satisfied at the moment of Contact insert. If Rule companies have no name, we use the domain as a fallback Account Name.

Rule contacts can carry multiple tags. Tags migrate to Salesforce Contact Tags (native tag feature) for lightweight classification. Tags used for behavioral segmentation (e.g., product interest, engagement tier) migrate to a custom multi-select picklist field rule_contact_tags__c so that filtering is possible in Salesforce reports without relying on tag-only filtering.

Rule segments are dynamic filter-based lists that evaluate continuously. We export segment definitions as filter logic rather than static snapshots. If the destination Salesforce org has a moderate segment count, we create Salesforce Campaigns with static Campaign Members from the snapshot at migration time, noting that dynamic behavior requires rebuild as a Salesforce Report or List View. For organizations heavily dependent on segment logic, we document the filter criteria for admin recreation as Salesforce Report filters.

Rule automation workflows contain trigger conditions, time delays, and multi-channel actions. We do not migrate workflows as code. We deliver a written inventory of every Rule workflow with its trigger type (event-based, date-based, tag-based), conditions, action sequences, and channel assignments. The trigger logic maps to a recommended Salesforce Flow variant (record-triggered, scheduled, or screen flow) with explicit notation that complex multi-branch workflows require redesign rather than 1:1 translation. The customer's admin or a Salesforce partner rebuilds the actual automation post-migration.

Rule campaigns group related automations and track aggregate performance metrics. We export campaign metadata (name, status, start and end dates, linked contact counts) to Salesforce Campaign records. Engagement analytics (opens, clicks, conversions) are time-bound event logs that may not replay in Salesforce's campaign reporting model; we migrate the raw metrics as custom fields on the Campaign record and note that campaign attribution requires rebuild in Salesforce's campaign influence model.

Rule email open, click, bounce, and unsubscribe events are logged per contact. We export the event log as a historical record set. Open and click events migrate to Salesforce Task records with custom event-type fields; bounces migrate as bounced-email records linked to the Contact; unsubscribes migrate to HasOptedOutOfEmail and to the suppression list mapping. Whether Salesforce surfaces this history in its native UI depends on the org's activity timeline configuration.

Rule SMS and RCS engagement events are tracked separately from email events in channel-specific logs. We export these as Salesforce Task records with TaskSubtype = SMS and custom fields for delivery status, reply events, and opt-out actions. If the destination Salesforce org has a native SMS integration (Salesforce High Velocity Sales, Dialer, or an AppExchange SMS app), we document the SMS engagement data for activation post-integration.

Rule social engagement events (clicks, shares, comments on social channels) are channel-siloed logs. We export these as Salesforce Task records with a custom channel field identifying the social platform (Twitter/X, LinkedIn, Facebook, Instagram). The activity timeline annotation identifies the source channel for auditability. Social listening data does not migrate as native Salesforce Social Studio records; it becomes a historical reference dataset for the customer to activate in Social Studio post-migration if desired.

Rule suppression lists (unsubscribed, bounced, blocked contacts) are exported as a distinct dataset. We flag suppressed records in Salesforce by setting HasOptedOutOfEmail = true on the migrated Contact or Lead. For organizations with high suppression list volume or complex suppression logic, we create a Salesforce Data Protection suppression list or a custom suppression object so that re-imports can be deduplicated against suppressed records. Rule suppression lists do not auto-apply during import; we handle this explicitly as a post-migration flag application.

Custom fields on Rule Contacts and Companies may include dropdown, date, numeric, text, or multi-select types. We map field types to equivalent Salesforce field types (Text, Number, Date, Datetime, Picklist, Multi-select Picklist, Checkbox, Currency). Multi-select fields in Rule require explicit mapping to Salesforce multi-select picklist fields with value list alignment. Dropdown fields with option lists migrate to Salesforce picklists with the same option values.

Rule email and SMS templates exist as reusable content assets. We export template body text, subject lines, and dynamic variable placeholders. Dynamic variable syntax requires reformatting for Salesforce merge field conventions (e.g., Rule {{contact.first_name}} becomes Salesforce {{!Contact.FirstName}}). HTML email templates migrate to Salesforce Visualforce or Lightning Email Templates; plain-text templates migrate to Salesforce text templates. Images embedded in Rule templates require re-upload to Salesforce Documents or Experience Cloud Assets.

Where Rule includes a sales pipeline view with stage names and ordering, we export the pipeline configuration as metadata. In Salesforce, this becomes a Sales Process with stage values (Probability, StageName) configured per Record Type. If Rule pipeline stages map to deal stages rather than opportunity stages, we map accordingly to the customer's Salesforce Opportunity model.

Rule user accounts include name, email, and role. We extract every distinct Rule user referenced on Contact, Company, Deal, and Engagement records and match by email against the Salesforce destination org's User table. Owners without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before record import resumes. Active/inactive status is preserved from Rule's user state.

File attachments linked to Rule contacts or campaigns are exported via Rule's file API. We download and re-upload to Salesforce as ContentVersion records, then link to the corresponding Contact, Account, Campaign, or Opportunity via ContentDocumentLink. Original filenames and MIME types are preserved. Attachments exceeding Salesforce file size limits are flagged for the customer to host externally and link via URL field.

If Rule includes deal or opportunity records, these map to Salesforce Opportunity. The Rule deal stage maps to Salesforce StageName via the pipeline configuration mapping. Closed-Won and Closed-Lost reasons from Rule custom properties become Salesforce Opportunity fields. Amount, close date, and owner assignment migrate directly with OwnerId resolved via the User mapping.