CRM migration
Field-level mapping, validation, and rollback between Serviceform and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
Serviceform
Source
Salesforce Sales Cloud
Destination
Compatibility
9 of 12
objects map 1:1 between Serviceform and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Serviceform is an AI chatbot and lead-generation platform organized around Conversations, Leads, Forms, and Chatbots. It has no publicly documented REST API, which makes programmatic bulk export the primary migration constraint. We coordinate directly with Serviceform support to extract conversation logs, lead records, and form submission data in a usable format, then re-map them into Salesforce's structured object model. Salesforce's Lead-versus-Contact split, validation rules, and field-level security require explicit migration-context handling. Engagement history (bot conversations, live chat sessions) migrates as Salesforce Task and Event records with the original timestamps preserved. Chatbot flow structures and conditional form logic do not transfer as automation code; we deliver a written specification of the original logic for your admin to reconstruct in Salesforce Flow or Web-to-Lead form builder. ATS module records from Serviceform's separate recruitment module map to Salesforce Contact records or a custom Applicant object depending on your destination schema.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Serviceform object lands in Salesforce Sales Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Serviceform
Lead
Salesforce Sales Cloud
Lead
1:1Serviceform Leads map directly to Salesforce Lead. Core fields (name, email, phone, source, qualification status) migrate to Salesforce standard fields. Serviceform's lead score and qualification properties transfer to custom fields (sf_lead_score__c, sf_qualification_status__c) for scoring and routing. Any Serviceform Lead with a resolved Account in Salesforce becomes a Contact via the standard Convert workflow post-migration.
Serviceform
Conversation
Salesforce Sales Cloud
Task
1:1Serviceform conversation logs (visitor messages, bot responses, timestamps, channel) map to Salesforce Task records. Each message in a conversation thread becomes a Task with Status=Completed, Subject set to the conversation summary, and Description containing the full transcript text. The original Serviceform timestamp migrates as ActivityDate for timeline ordering. Channel metadata (website chat, email, SMS) stores in a custom field sf_conversation_channel__c.
Serviceform
Conversation
Salesforce Sales Cloud
EmailMessage
1:1Conversations initiated via email in Serviceform map to Salesforce EmailMessage records. The message body and attachments migrate to EmailMessage.Body and ContentDocument records respectively. The WhoId points to the linked Lead or Contact; the WhatId points to the related Account or Opportunity if one was resolved during import.
Serviceform
Live Chat Session
Salesforce Sales Cloud
Task (TaskSubtype = Chat)
1:1Serviceform live chat session logs (visitor info, agent assignment, resolution status) map to Salesforce Task records with TaskSubtype = Chat. Agent assignment resolves via email match to a Salesforce User. Resolution status and session duration migrate to custom fields sf_chat_resolution__c and sf_session_duration__c.
Serviceform
Form
Salesforce Sales Cloud
Web-to-Lead or Custom Object
lossyServiceform form definitions (field configurations, field types, conditional logic) are exported as a schema specification document rather than a transferable form. Each form's submission data maps to Salesforce standard fields where the field name and type match, and to custom fields (sf_form_field__c) where it does not. Conditional visibility rules are documented in the form specification for rebuild in Salesforce Flow or Web-to-Lead form settings.
Serviceform
Form Submission
Salesforce Sales Cloud
Lead or Custom Object
1:1Form submission data (field values, submission timestamp, source form name) migrates to Salesforce Lead records or a custom FormSubmission__c object depending on whether the destination org uses a custom object for web form captures. Submission metadata (form name, UTM parameters, referrer URL) stores in custom fields on the target record.
Serviceform
Chatbot Flow
Salesforce Sales Cloud
Documentation Specification
lossyServiceform chatbot flows (nodes, intents, response rules, conversation trees) are exported as a structured JSON schema and a visual flow diagram. This is a documentation artifact, not deployable automation. We deliver the full chatbot architecture as a written specification with intent mappings and recommended Salesforce Flow equivalents for the customer's admin to rebuild.
Serviceform
Team Member
Salesforce Sales Cloud
User
1:1Serviceform user accounts with roles and seat assignments map to Salesforce User records. We resolve by email match. Active Serviceform users without a matching Salesforce User enter a reconciliation queue for admin provisioning before record import proceeds.
Serviceform
Integration Connection
Salesforce Sales Cloud
Integration Configuration List
lossyServiceform integration connections (CRM links, email provider references, analytics tool references) are exported as a configuration list identifying each active integration and its connection parameters. We do not re-establish integrations during migration; we deliver the list so the customer's admin can reconnect each tool in Salesforce manually using the documented endpoints.
Serviceform
ATS Applicant
Salesforce Sales Cloud
Contact or Custom Applicant Object
1:1Serviceform ATS module applicant records (resume, candidate profile, ranking data) are exported as a separate dataset. These map to Salesforce Contact records if the destination org uses the Contact object for recruitment tracking, or to a custom Applicant__c object if the org has a pre-existing applicant schema. Resume files migrate as ContentDocument records linked via ContentDocumentLink.
Serviceform
Conversation Statistics
Salesforce Sales Cloud
None
1:1Serviceform aggregates conversation metrics (conversion rates, bot performance, engagement rates) at read time from the underlying conversation data. These are not independently stored records and cannot be migrated. We preserve the raw conversation logs so that Salesforce reporting can recalculate equivalent metrics post-migration.
Serviceform
Custom Property (Chatbot Node)
Salesforce Sales Cloud
Custom Field
1:1Custom properties on Serviceform chatbot nodes (custom attributes, metadata fields) are exported with the chatbot flow JSON. These map to custom fields on the Salesforce record type or object that represents the chatbot's destination context. If no matching Salesforce object exists, we recommend creating a custom ConversationMetadata__c object to hold these attributes.
| Serviceform | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Lead | Lead1:1 | Fully supported | |
| Conversation | Task1:1 | Fully supported | |
| Conversation | EmailMessage1:1 | Fully supported | |
| Live Chat Session | Task (TaskSubtype = Chat)1:1 | Fully supported | |
| Form | Web-to-Lead or Custom Objectlossy | Fully supported | |
| Form Submission | Lead or Custom Object1:1 | Fully supported | |
| Chatbot Flow | Documentation Specificationlossy | Fully supported | |
| Team Member | User1:1 | Fully supported | |
| Integration Connection | Integration Configuration Listlossy | Fully supported | |
| ATS Applicant | Contact or Custom Applicant Object1:1 | Fully supported | |
| Conversation Statistics | None1:1 | Fully supported | |
| Custom Property (Chatbot Node) | Custom Field1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Serviceform gotchas
Usage-based billing means migration scope directly affects costs
No publicly documented public API
ATS module data is separate from core chatbot data
Conditional logic on forms may not transfer 1:1
Salesforce Sales Cloud gotchas
Workflow Rules and Process Builder are retired
Bulk API batch quota exhaustion during large imports
Storage overage billing is non-obvious
Account-Contact many-to-many relationship mapping
Territory and team member import ordering dependencies
Pair-specific challenges
Migration approach
Discovery and export coordination
We audit the Serviceform account for Leads, conversation volume, form definitions, chatbot flows, team members, integrations, and ATS data. We open a data export request with Serviceform support to obtain the data in CSV or JSON format. We assess data quality (duplicate rate, completeness of required fields, formatting consistency) and present the conversation scope options to the customer before proceeding.
Salesforce schema design
We design the destination Salesforce schema including custom fields for Serviceform metadata (lead scores, conversation channels, form source identifiers), custom objects if the destination org requires them (e.g., ConversationMetadata__c, Applicant__c), Record Types for form-submission segmentation, and validation rule handling strategy. Schema is deployed into a Salesforce Sandbox first for validation.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox using the exported Serviceform data. The customer's Salesforce admin reconciles record counts (Leads in, Contacts in, Tasks in, form submissions in), spot-checks 25-50 records against the Serviceform source, and reviews the mapping of custom properties. The admin signs off the mapping and schema before production migration begins.
Owner reconciliation and User provisioning
We extract every distinct Serviceform team member referenced in conversation logs and chat sessions and match by email against the Salesforce destination org's User table. Any unmatched owners enter a reconciliation queue. The customer's Salesforce admin provisions missing Users (active or inactive depending on whether the original Serviceform user is still active) before production migration proceeds.
Production migration in dependency order
We run production migration in record-dependency order: Users (manual provisioning, validated), Leads (with custom fields mapped), form submissions (to Lead or custom object), ATS applicant records, chatbot flow documentation (as a separate file deliverable), then conversation history (Tasks and EmailMessages via Salesforce Bulk API with batch chunking). Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, conditional logic specification, and chatbot rebuild handoff
We freeze Serviceform data entry during cutover, run a final delta migration of any records created or modified during the migration window, then enable Salesforce as the system of record. We deliver the conditional form logic specification document and the chatbot flow JSON schema to the customer's admin team with recommended Salesforce Flow equivalents. We provide a one-week hypercare window for reconciliation issues. Workflow rebuilds, form rebuilds, and bot rebuilds are outside the migration scope.
Platform deep dives
Serviceform
Source
Strengths
Weaknesses
Salesforce Sales Cloud
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Serviceform and Salesforce Sales Cloud.
Object compatibility
1 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Serviceform: Not publicly documented.
Data volume sensitivity
Serviceform doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Serviceform to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Serviceform to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Serviceform
Other ways to arrive at Salesforce Sales Cloud
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.