Migrate from Checkbox to Salesforce Sales Cloud

Checkbox contact records (name, email, phone, job title, company) map directly to Salesforce Contact. The AccountId must be resolved first — contacts without a matching Salesforce Account land on a default 'Intake Unassigned' Account record or as a Salesforce Lead if the account does not yet exist.

Checkbox contacts without a resolved Salesforce Account are routed to Lead. Email, name, phone, title, and company name map to standard Lead fields. The Lead Source field is set to 'Checkbox Intake' for lineage tracking on all split records. If a Contact has an existing Salesforce Account later, it can be converted to a Contact via the standard Lead conversion process.

Each Checkbox intake submission becomes a Salesforce Case. The Case Subject maps from the survey name or a designated title field. Description maps the full submission body. ContactId links to the resolved Contact or Lead. Status defaults to 'New' with a custom Checkbox_Status__c field preserving the original intake stage.

Every Checkbox custom survey question requires a corresponding Salesforce custom field (__c) on the target object. Text questions become Text fields, numbers become Number fields, dates become Date fields, and pick-list questions become Picklist fields with value-by-value mapping. Boolean (checkbox) questions translate to Checkbox fields, while multi-select questions can be stored as pipe-delimited text or split into individual checkbox fields depending on reporting needs.

Checkbox file attachments are downloaded and re-uploaded as Salesforce Files, then linked to the target record via ContentDocumentLink. Files larger than Salesforce's 25MB default limit require chunked upload or external storage reference. Inline images in long-text submission fields are downloaded and rehosted.

Checkbox intake assignments by email are resolved against Salesforce Users. Unmatched emails are flagged before migration — the team either creates Salesforce users for them or assigns their submissions to a fallback owner. No Salesforce record lands without an OwnerId.

Checkbox submission dates and last-modified dates are preserved as custom datetime fields (Original_Submission_Date__c, Original_Modified_Date__c) because Salesforce's native CreatedDate and LastModifiedDate reflect migration time, not the original business event. These custom fields enable reporting on intake volume trends over time, ensure compliance with audit trails, and support calculations of time-to-resolution from the original submission timestamp.

The original Checkbox record ID is stored on every Salesforce record as Source_System_ID__c for traceability, delta-run de-duplication, and cross-referencing if the migration needs to be reconciled against the source system post-cutover. This field also facilitates data quality checks, allows for automated reconciliation reports, and provides a reliable anchor for future integrations or API queries that require the original identifier.

Checkbox conditional routing, approval chains, and intake assignment logic do not export as data — they are platform configuration. FlitStack exports the workflow definition as a PDF/map for your Salesforce admin to rebuild in Flow. Data migration runs independently of workflow rebuild.

The structure of each Checkbox form (question order, section headers, conditional visibility) does not map directly to Salesforce. The form schema is documented as a migration reference so your admin can create matching Salesforce page layouts, sections, or a custom intake object that mirrors the original form flow.