Migrate from Rule to Pipedrive

Rule contact profiles map to Pipedrive Person records. Standard fields (name, email, phone) map directly; behavioral attributes and channel preferences migrate as custom Person fields. Lifecycle stage from Rule preserves in a custom field rule_lifecycle_stage__c for segmentation audit. Rule contacts without an email are flagged during extraction for manual review before insert because Pipedrive Persons require an email value at most plan tiers.

Rule account-level data maps to Pipedrive Organization. The account name becomes the Organization name field; domain data maps to the website field. Where Rule accounts reference a parent relationship, we map it to Organization's parent_id if the destination org uses hierarchical account structures. Organizations are created before Person import so that the Organization ID lookup resolves at Person insert time.

Rule deal records map to Pipedrive Deals with the deal title, value, currency, and stage preserved. Rule's pipeline stage assignment maps to a Pipedrive Pipeline and Stage. Closed-won and closed-lost reasons from Rule custom fields map to Pipedrive Deal custom fields if the destination plan supports them.

Rule pipeline stages become Pipedrive Pipelines with Stages configured per Pipeline. Probability percentages from Rule migrate to Stage order and probability values in Pipedrive. We create Pipelines and Stages via the Pipedrive API before Deals are imported so that the stage_id foreign key is valid at insert time.

Rule dynamic segments with behavioral filter conditions are exported as filter logic definitions. Where Pipedrive supports saved filters on Persons, we recreate the segment criteria as a Pipedrive filter definition in the Person list view. Segments based on static contact lists migrate as Person tags for quick segmentation in Pipedrive's list view. The customer chooses filter or tag strategy during scoping.

All Rule tags per contact migrate directly to Pipedrive Person tags. Tags are preserved as a multi-value property on Person so that sales reps can filter by tag in Pipedrive's list view without reconstructing the tag logic manually.

Rule email open, click, bounce, and unsubscribe events export as activity records. We map them to Pipedrive Activities with type=email, setting the subject to include the event type (e.g., 'Rule: Email Opened') and the note body to include the campaign name and timestamp. Pipedrive's email sync captures new email activity natively post-migration; historical events are treated as audit records.

Channel-specific SMS and RCS engagement events from Rule export separately from email events. We map them to Pipedrive Activities with type=task, annotating the subject with the channel source (e.g., 'Rule SMS: Delivered') and preserving the full event metadata in the activity note. The activity is linked to the Person record via the person_id reference.

Social channel engagement events (follows, clicks, shares) tracked in Rule export as Pipedrive Activity records with type=task and the channel annotated in the subject. Social media post content and engagement metadata migrate as activity notes for audit completeness.

Rule user accounts (name, email, role) map to Pipedrive Users by email match. Owner assignments on Rule Contacts, Companies, and Deals resolve to Pipedrive OwnerId via the User email lookup. Any Rule owner without a matching Pipedrive User is flagged in a reconciliation report for the customer's admin to provision before Deal import resumes.

Rule suppressed contacts (unsubscribed, bounced, blocked) export as a distinct dataset. We apply a custom field rule_suppression_status__c on each affected Person record with the suppression reason value, and set the Person's email_hard_bounced flag where Pipedrive supports it. Pipedrive does not have a native suppression list equivalent; the per-contact flag provides the same enforcement at the contact level.

Rule custom fields on Contacts and Companies map to Pipedrive custom fields on Person and Organization. Dropdown fields map to Pipedrive options fields; multi-select fields require explicit mapping to Pipedrive's options structure. We create the destination custom fields via Pipedrive API before data import so that the field key exists at insert time. Field type mapping is validated during the sandbox migration phase.