Migrate from folk to Pipedrive

folk Contacts of subtype 'person' migrate directly to Pipedrive People. The standard properties — name, email, phone, social handles — map to Pipedrive's typed Person fields. Any per-group custom field values are mapped to Pipedrive global custom fields (see Custom Field mapping entry). If a contact spans multiple Groups with conflicting field values, we apply a merge strategy defined during scoping: take the most recently updated value, concatenate with a delimiter, or flag for manual resolution. Subtype is preserved in a custom field folk_subtype__c for audit.

folk Contacts of subtype 'company' migrate to Pipedrive Organization. Company properties (name, domain, industry, size) map to the corresponding Organization fields. Where a company-type contact also has linked person-type contacts in folk, we create the Organization first and then link each related Person record via Pipedrive's person-organization relationship. The domain field on the Organization is used as the dedupe key during import to prevent duplicate Organizations for the same company.

folk Groups serve multiple organizational purposes: contact lists, pipeline views, and team-segmentation containers. We enumerate every Group during discovery and classify each by intended use. Groups functioning as contact lists map to Pipedrive Organizations (if company-centric) or to a tag-based filter (if person-centric). Groups functioning as pipeline views map to Pipedrive Deals with stage data reconstructed from the Group's pipeline metadata. This split requires explicit customer sign-off during scoping because the mapping choice affects downstream reporting in Pipedrive.

folk's per-Group pipeline views contain stage names and ordering. We map each distinct pipeline view to a Pipedrive Pipeline with its corresponding Stages. Stage probabilities migrate as StageProbability values rounded to Pipedrive's integer constraint. Any custom stage logic (e.g., conditional stage advancement) is documented as a manual rebuild item in Pipedrive's automation builder because it cannot be inferred from the CSV export. Pipedrive's visual drag-and-drop stage editor is used post-migration to finalize the pipeline layout.

folk has no native Deal object. We reconstruct deal-like records from Group pipeline-view data where contacts are associated with a stage. Each reconstructed Deal receives the contact as a linked Person, the associated Organization (or a placeholder if no company link exists), a monetary value if present, a close date if present, and the stage mapped from the source pipeline view. Deals that cannot be reconstructed (contacts in Groups with no pipeline metadata) are documented as contacts lacking deal association and migrated as People only.

folk Notes attached to Contacts migrate to Pipedrive Notes linked to the corresponding Person or Organization record. Note body, author attribution, and timestamp migrate directly. If the note contains mentions of other contacts or deals that also migrate, we resolve those cross-references to Pipedrive's note linking model. Notes without an associated Person or Organization are attached to the nearest related Organization.

folk tags migrate to Pipedrive Labels applied to the corresponding Person record. If tags were used to represent deal status or campaign membership rather than contact classification, we map them to Pipedrive Activities with a note field recording the original tag value. The customer chooses tag strategy during scoping because Pipedrive Labels are a flat taxonomy whereas folk tags can be hierarchical or multi-dimensional. We do not attempt to infer tag hierarchy from the CSV export.

folk Reminders carry text, due date, and assignee. We migrate Reminders as Pipedrive Activities (type Task) with the reminder text in the activity subject, the due date as the ActivityDate, and the assignee resolved via email match against Pipedrive Users. If a folk Reminder references a contact that migrated successfully, we link the Activity to the corresponding Person record. Reminders without an assignee are created as unassigned Activities for the account owner to redistribute post-migration.

Custom fields in folk are defined per-Group, not globally. During discovery we enumerate every Group's field schema and generate a consolidated field map. Fields that exist in one Group but not others create null values for contacts outside that Group — we flag these gaps and either create Pipedrive custom fields with null-capable defaults or exclude the field from migration where it is not broadly applicable. Field type mapping: folk text, number, date, and dropdown fields map to Pipedrive custom field types of equivalent name. Folk multi-select fields map to Pipedrive multi-select with value reconciliation across source Groups.

folk email campaign contact lists migrate as Pipedrive People associated with a Pipedrive Campaign record. The Campaign record is created to document which contacts were part of the original campaign, but campaign performance metrics (sent count, open rate, click rate) are not migratable from folk because this data is stored in folk's campaign engine and excluded from the CSV export. We document the campaign name, contact count, and date range so the customer can reference the campaign history separately.

folk activity history present in the CSV export migrates to Pipedrive Activities. Email logs migrate as Activity records with type Email. Calls migrate as Activity records with type Call and duration preserved. Meetings migrate as Activity records with type Meeting and location preserved. Activity timestamps are used to set the ActivityDate for timeline ordering. The full richness of folk's native activity timeline (social interactions, LinkedIn engagement, enrichment events) is not captured in the CSV export, so we note activity gaps in the migration report.