Migrate from folk to Salesforce Sales Cloud

folk person-type Contacts map to Salesforce Contact. We extract every distinct email address and use it as the ExternalId for upsert. Standard fields (Name, Email, Phone, Title, LinkedIn URL) migrate directly. Custom fields per contact migrate as Salesforce custom fields on Contact, but only the union of all per-group field definitions becomes the Salesforce schema — contacts from groups with no custom fields receive the standard set only. Any contacts spanning multiple Groups inherit all custom field values from every Group membership, with a migration flag on records where field values conflict across Groups.

folk company-type Contacts map to Salesforce Account. The company name becomes the Account Name; domain/social handles become Website and LinkedIn fields. Person-type contacts at the same company require a manual AccountId link in folk; we use company name matching as a heuristic to link person-type Contacts to the newly created Account during migration. Any manually established folk relationship links are preserved in a custom field folk_relationship__c for the customer's admin to resolve post-migration. Teams with an account-based motion should set up Salesforce Account-Contact rules post-migration rather than relying on name-matching.

folk Groups are organizational containers analogous to Lists or Segments. We map each Group to a Salesforce Campaign (for marketing-oriented Groups with email sequence membership) or to a Public List View query (for operational Groups such as Leads or Clients). The mapping choice is made during scoping based on Group naming conventions and whether the group feeds email campaigns. Group membership (the list of contacts in each Group) migrates as CampaignMember records for Campaign targets, or as a custom List_Member__c junction object for List View targets. We document the complete Group-to-destination mapping in the written inventory.

Custom fields in folk are defined per-group, not globally. A Contact in the Leads Group may carry a field that does not exist in the Clients Group. We enumerate every Group's field schema during discovery, compute the union across all Groups, and create Salesforce custom fields on the appropriate object (Contact for person-level fields, Account for company-level fields). The migration applies only the fields that exist per-contact per-Group membership. Contacts spanning multiple Groups with conflicting field values are flagged in the reconciliation report with the original Group and field value preserved for the admin to resolve.

folk Pipeline Views are defined per-Group with custom stage names and ordering. Each folk Pipeline View maps to a Salesforce Opportunity Record Type with a corresponding Sales Process that whitelists the stage values. Stage probability percentages transfer from folk to Salesforce StageProbability. We configure Record Types, Sales Processes, and stage values in a Salesforce Sandbox before migration so that the customer can validate the stage mapping before production cutover. Custom stage logic (e.g., auto-advance rules, stage-gated fields) is documented in the written automation inventory for rebuild in Salesforce Flow.

folk Notes attached to Contacts migrate as Salesforce Note records. We preserve the note body text, creation timestamp, and author attribution. Notes are linked to the parent Contact or Account via ContentDocumentLink. If the note contains an attachment reference (URL), we attempt to download and re-upload as a ContentDocument; file size limits are constrained by the destination Salesforce edition's storage quota.

folk Reminders carry a due date, assignee email, and text body. We migrate Reminders as Salesforce Task records with the subject as Task Subject, ActivityDate as the due date, and Status set to Not Started. Assignee resolution requires matching the folk Reminder assignee email to a Salesforce User record; any unmatched assignees are held in the reconciliation queue for the customer's admin to provision. Past-due Reminders migrate with their original timestamp preserved.

folk allows free-form tagging on Contacts. Tags migrate as a Salesforce multi-select picklist field on Contact (if fewer than 150 distinct tags) or to Salesforce Campaigns with CampaignMember records (if the tagging taxonomy is behavioral or segment-based, e.g., Tags = industry segments or event attendees). The customer chooses the tag strategy during scoping. We validate tag cardinality against Salesforce multi-select picklist limits (max 500 values per picklist) and adjust the strategy accordingly.

folk file attachments can be exported as URLs or files via CSV. We attempt to download each attachment and re-upload via Salesforce ContentVersion/ContentDocument. File size limits are governed by the destination Salesforce edition (typically 25 MB per file on Standard/Professional). Attachments exceeding the size limit or unreachable via URL are flagged in the gap inventory. We do not guarantee attachment integrity for files stored in folk's internal attachment system that are not accessible via CSV export URL.

folk's contact timeline captures email events, meeting logs, and call records. We extract what is present in the CSV export (subject, timestamp, type) and map to Salesforce Task (for calls and general activities), Event (for meetings), or EmailMessage (for sent emails). Activity ordering is preserved by setting ActivityDate to the original folk timestamp. The full email body content is only available in folk's timeline if included in the CSV export; we flag any timeline gaps in the written export-gap inventory. folk's email tracking data (opens, clicks) is stored in folk's engine and not exported.

If the source folk workspace includes Tickets (available on Premium), they migrate to Salesforce Case. Ticket pipeline stages map to Case Status values; the ticket pipeline becomes a Case Record Type. Conversation threads migrate as EmailMessage records linked to the Case. This mapping applies only if the destination Salesforce org includes Service Cloud or the customer adds the Service Cloud license during migration scoping.

folk Owners referenced on Contacts, Companies, Deals, and Pipeline views map to Salesforce User records by email match. We extract every distinct Owner email and query the destination Salesforce org's User table. Any Owner without a matching User is held in a reconciliation queue; the customer's Salesforce admin provisions the missing Users (active or inactive) before record import resumes. Ownerless records are assigned to a migration system user and flagged for reassignment post-migration.

Magic Fields in folk are AI-generated values computed at query time from source data and the AI model. They are not stored as persistent records and therefore have no export representation. We do not attempt to migrate Magic Field values. Customers who rely on Magic Field outputs should re-run Magic Fields against the source data after migration in the destination CRM or via a separate enrichment tool. The customer should also assess whether their post-migration AI strategy requires a Salesforce Einstein AI seat upgrade.

folk's enrichment data is live-fetched from external providers (LinkedIn, company databases) and not persistently stored in a way accessible for export. We do not migrate enrichment data. Customers relying on folk's enrichment credits for firmographic or contact data should plan for a replacement enrichment strategy in Salesforce using tools such as Apollo.io, Clearbit, or Salesforce Data Cloud.