Migrate from REDA to Pipedrive

REDA custom fields require pre-creation in Pipedrive before any data lands

REDA runs on Salesforce, which means any custom properties configured in REDA are stored as Salesforce custom fields (__c objects). Pipedrive does not import custom field definitions — each field must be manually created in Pipedrive first via the UI or API using POST /personFields, /organizationFields, or /dealFields. Pick-list fields need their options created before values can map. Formula field results must be extracted from Salesforce before migration and written as static values into Pipedrive custom fields, since Pipedrive has no formula engine at write time. This pre-creation step adds planning time and must be completed before the test migration runs.

Salesforce task-event split becomes one Pipedrive Activity record per engagement

REDA separates Tasks (to-dos) from Events (calendar items) into two Salesforce objects. Pipedrive uses a single Activity object where the type is encoded in the activity_type field and completion state is tracked via the 'done' flag (0 = open task, 1 = completed). Every REDA Task and Event becomes one Pipedrive Activity with original timestamps and owners preserved. The mapping is lossless for data but loses the Salesforce-native task/event object distinction — Pipedrive admins should configure activity type filters in list views to recreate the Tasks vs. Meetings separation that REDA users relied on.

Account hierarchy collapses in Pipedrive's flat Organization model

REDA supports Salesforce Account hierarchies via the Parent Account field — a parent Account can have child Accounts with full hierarchy traversal. Pipedrive Organizations are flat; there is no native parent-child relationship. Multi-level Account structures in REDA (common in real estate and construction) need a design decision before migration: either collapse all children to top-level Organizations with a custom Parent_Org__c text field, or link them via a custom junction object. Circular references (Account A is parent of B, B is parent of A) are flagged and resolved to the topmost ancestor before migration.

Pipedrive file size cap of 25MB applies to REDA ContentDocument re-uploads

REDA stores files as Salesforce ContentDocuments with version history. Pipedrive's file upload endpoint and UI both cap individual files at 25MB. Files from REDA exceeding this limit — common for construction drawings, large PDFs, or media attachments — are skipped during migration and listed in a separate file manifest. These files must be re-uploaded manually to Pipedrive post-migration or stored in an external system (Google Drive, SharePoint) with links preserved in a Pipedrive custom field. This is a known gap in Pipedrive's file handling that teams with heavy document workflows encounter regularly.

Pipedrive Leads use a separate flow — REDA Leads are better migrated as Persons

Pipedrive's native Lead feature operates as a separate import queue with different field visibility and lifecycle than REDA's Salesforce Lead object. Migrating REDA Leads into Pipedrive's Lead feature is technically possible but limited — Pipedrive Leads have fewer customization options and cannot be mixed freely with Persons in the same pipeline view. The recommended approach maps REDA Leads to Pipedrive Persons with a custom Lead_Status__c field set to the original Lead Status value. This preserves all contact data and status history without the constraints of Pipedrive's separate Lead import flow.