Migrate from LeadDesk to Salesforce Service Cloud

LeadDesk Contacts map to Salesforce Contact if the contact has an associated Company/Sponsor and to Salesforce Lead if the contact is a raw outbound prospect record. We use the Campaign and Project associations in LeadDesk to determine qualification status: contacts linked to closed Campaigns with successful Outcomes map as Leads; contacts linked to active customer Projects map as Contacts with an AccountId resolved from the Sponsor field. The original LeadDesk contact ID is preserved in a custom field ld_contact_id__c for audit and reconciliation.

LeadDesk Campaigns map directly to Salesforce Campaign. Campaign status (Active, Paused, Completed) maps to Salesforce CampaignStatus. The Sponsor field in LeadDesk maps to a custom Campaign field sponsor__c. Campaign hierarchy is preserved where LeadDesk Projects contain Campaigns; Salesforce sub-campaign structure mirrors this with ParentId resolution during import.

LeadDesk Projects function as customer initiative containers. If the Project name corresponds to an active customer account, we map it to Salesforce Account and link the child Campaigns accordingly. If the Project is an outbound initiative (lead generation, event) without a customer account, we map it to Salesforce Campaign with a project_type__c custom field set to outbound_initiative. We confirm the mapping strategy during scoping based on the customer's LeadDesk Project taxonomy.

LeadDesk call records include duration, disposition (Results/Outcomes), agent assignment, and campaign linkage. We map these to Salesforce Task with TaskSubtype = Call. The LeadDesk disposition code is preserved in a custom Task field ld_disposition__c, and the original Campaign reference maps to WhatId pointing to the Salesforce Campaign record. Activity timeline ordering is preserved by setting ActivityDate to the original call timestamp. Call recording URLs are not migrated as attachments but are documented in the ld_recording_url__c field for manual re-linkage.

LeadDesk chatbot analytics export as a time-bounded ZIP containing conversations, outcomes, timing, and agent CSV files. Each conversation becomes a Salesforce Case if it resulted in a support interaction, or an EmailMessage record if it was a self-service resolution. We validate the date range with the customer before export initiation and decompress all four CSV files to reconstruct the full conversation thread. Any conversation that falls outside the selected export date range is not included and is unrecoverable after migration.

LeadDesk Agents map to Salesforce User records. We resolve by email match against the destination org's User table. Agent properties including role (Agent, Teamleader, Manager), team assignment, and office are mapped to Salesforce Profile, Role, and custom fields. Any Agent without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before the User-dependent records (Call Records, Tasks) are imported.

LeadDesk Teams with Teamleader hierarchy map to Salesforce Public Groups if the team is used for internal organization, or to Salesforce Omni-Channel Presence Configuration Groups if the team manages inbound cases. We confirm the team's function during scoping: outbound campaign teams map to Public Groups; inbound service queues map to Case Queues for Omni-Channel routing.

LeadDesk Offices represent multi-site deployment nodes with timezone and VoIP routing. If the customer maintains physical office locations as a reporting dimension, we map them to a custom Location__c object or to the Salesforce State and Country/Territory picklist on User records. VoIP routing configurations have no direct Salesforce equivalent and are documented separately for the customer's IT team to reconfigure post-migration.

LeadDesk Results and Outcomes are the call disposition taxonomy. We extract the full disposition code list during discovery and map each to Salesforce Case Status values (New, Working, Escalated, Closed) or a custom picklist field ld_disposition_code__c depending on whether the destination org has Service Cloud Case management active. We preserve the full LeadDesk taxonomy in the custom field so no disposition category is lost during normalization.

LeadDesk custom fields on Contacts and Leads map field-by-field to Salesforce custom fields of equivalent type. We flag unsupported data types including complex nested objects, multi-reference fields, and LeadDesk-specific property formats for manual review. Custom fields are deployed to the destination Sandbox org via metadata API before any record migration begins. Any custom field with a picklist value set in LeadDesk is re-created as a Salesforce picklist or multi-select picklist with the same values.

LeadApps are add-on modules within LeadDesk. We export their configuration as JSON where the LeadDesk API exposes it, but we do not migrate runtime state. LeadDesk LeadApps with equivalents on Salesforce AppExchange (e.g., conversation intelligence, quality management) are documented with the recommended package for the customer's admin to evaluate. LeadApps without a Salesforce equivalent are included in the rebuild inventory delivered at cutover.

LeadDesk dialer modes (preview, power, predictive, AI) and round settings are stored per Campaign. These settings have no direct equivalent in Salesforce Service Cloud because Service Cloud is not a dialer platform. We document the full dialer configuration per Campaign in a structured handoff document that includes the dialer mode, agent-to-lead ratios, wrap-up time, and retry settings. The customer's admin uses this to evaluate whether to implement Salesforce Sales Engagement or a third-party dialer integration (Five9, Nice, Genesys) post-migration.