Migrate from Lead Liaison to Salesforce Sales Cloud

Lead Liaison Prospects map to Salesforce Lead or Contact based on the customer's lifecycle stage configuration. Prospects with a lifecycle stage indicating an unqualified or early-stage contact map to Salesforce Lead; Prospects at sales qualified or later stages map to Salesforce Contact attached to an Account. We extract the lifecycle_stage property and all standard contact fields (firstname, lastname, email, phone, company) from the Prospects API endpoint, then apply the split rule at migration time. The original Lead Liaison lifecycle stage is preserved in a custom field ll_original_lifecycle__c on both Lead and Contact for audit and future segmentation.

Lead Liaison Company records map directly to Salesforce Account. The Company name becomes the Account Name; industry, website, org_type, and employee_count migrate to typed Salesforce Account fields. Company records are imported before Prospects so that AccountId is resolved at the moment of Contact/Lead insert, satisfying the lookup relationship required by Salesforce's Contact model. The domain field from Lead Liaison Company is stored as a custom field ll_source_domain__c on Account for deduplication and future ProspectVision-style visitor matching if Data Cloud is licensed.

Lead Liaison list membership assignments (which Prospects belong to which Lists) are exported as Campaign records in Salesforce with Campaign Type = Directory or a custom List type. Static lists migrate as Campaign Member records linking the resolved Lead or Contact ID to the Campaign. Dynamic segments that rely on Lead Liaison's behavioral criteria do not have a direct equivalent in Salesforce without Audience building; we document the criteria for manual rebuild in Salesforce Reports or Marketing Cloud Audience Builder and flag this as a configuration task.

If the customer uses Lead Liaison's bundled OneFocus CRM for deal management, Deal records map to Salesforce Opportunity. Deal name maps to Opportunity Name; dealstage maps to StageName; amount maps to Amount; closedate maps to CloseDate. We create Salesforce Record Types and Sales Processes to match the source pipeline stages before migration. Closed-Won and Closed-Lost reasons from Lead Liaison custom fields become Salesforce Loss Reason and custom win reason fields.

Lead Liaison Form definitions and all submission records are extracted via the API including field responses, submission timestamps, and referring page URLs. Form submissions at the unqualified prospect stage migrate as Salesforce Lead records with form field data mapped to Lead standard and custom fields. Submissions from known contacts migrate as Salesforce Contact records with a linked Activity record documenting the submission. Form schema (field names, field types) is preserved in a custom Form_Submission__c object if the form has more than 10 fields or includes file attachments that cannot map to standard Lead fields.

Lead Liaison email campaign metadata (name, status, associated list, send date, subject line) migrates to Salesforce Campaign records with Campaign Type = Email. Campaign Member status for recipients maps from Lead Liaison's campaign recipient list. Email HTML content, templates, and assets are extracted and delivered as a structured attachment package rather than inserted into Salesforce as records, because Salesforce stores email content in ContentDocument or as separate EmailTemplate objects with a different data model. The customer rebuilds email send logic in Salesforce Email Action or Marketing Cloud.

Lead Liaison's numeric lead scoring values are stored as Prospect properties and exported as plain numeric fields. The scoring value itself migrates to a custom field ll_lead_score__c (type: Number) on both Lead and Contact. The underlying scoring model (point allocations per behavior, weighted criteria) is not exposed in the API and cannot be migrated; we document the source scoring weights during discovery so the customer's admin can rebuild a comparable Salesforce Flow or Einstein Lead Scoring logic post-migration.

Automated buy signals in Lead Liaison are behavioral triggers attached to Prospects (type: page_visit, demo_request, pricing_page, competitor_mentioned). We export signal type, trigger date, and associated Prospect. The signal type is mapped to a custom field signal_type__c on a Buyer_Signal__c custom object if the customer has more than 10 signal types, or to a Task record with Subject prefixed by the signal type if the volume is lower. The rule configuration that generated the signal is not exposed in the API and is documented separately for admin rebuild in Salesforce Flow.

Lead Liaison's custom activity tracking allows arbitrary event types (button clicks, link clicks, phone calls, orders, PDF downloads). These user-defined schemas have no standardized field names across customers. We request a full list of active custom activity types during discovery, map each to either the Salesforce Task object (for short-duration events like clicks) or a pre-created custom object (for transactional events like orders or subscriptions). The destination schema is deployed to a Salesforce Sandbox for validation before any production insert, because custom objects require __c API name creation and field type decisions that affect downstream reporting.

Visitor tracking produces a chronological log of page views, company identification timestamps, and engagement depth per Prospect. We export visit records as flattened engagement history entries and attach them as Task records to the migrated Lead or Contact, with Subject set to 'Website Visit' and Description containing the page URL and engagement depth indicator. High-volume visit histories (more than 50 visit records per Prospect) are condensed into a summary custom field ll_last_engagement_date__c and a custom Engagement_Summary__c object capturing total visit count, most-visited page, and last visit date to avoid creating thousands of individual Task records that degrade Salesforce list view performance.

Lead Liaison tags are a flat labeling system applied to Prospects and other objects. We export all tag definitions and Prospect-to-tag assignments. Tags migrate to a multi-select picklist field ll_tags__c on Lead and Contact if the total unique tag count is under 100 and fits within Salesforce's 255-character multi-select limit. Tags exceeding that threshold are exported as a Tag_Assignment__c custom object with a Lookup to Contact/Lead and a Tag_Name__c text field.

Lead Liaison User records (name, email, role, ownership assignments) are extracted and matched by email to Salesforce User records in the destination org. Users without a matching Salesforce User are placed in a reconciliation queue for the customer's admin to provision before record import resumes. OwnerId references on Leads, Contacts, Accounts, and Opportunities require a valid Salesforce User; migration cannot proceed past record insert without resolved OwnerIds for all distinct owners present in the source data.

Lead Liaison automation membership (which Prospects are enrolled in which automations) is exported as a list of automation_id and prospect_id pairs. This data migrates as a Workflow_Assignment__c custom object that documents the automation name, trigger type, and enrolled date for each Prospect, but does not recreate the automation logic in Salesforce. The automation step sequence, conditional branches, time delays, and A/B split configurations are not exposed via API and are delivered as a written rebuild guide mapping each Lead Liaison automation to a Salesforce Flow equivalent.