Migrate from LeadTrac to Salesforce Sales Cloud

LeadTrac unqualified leads migrate to Salesforce Lead. Fields including name, email, phone, company, status, and source map directly. Custom fields on the lead record become Lead custom fields (Lead_Source_Detail__c, Original_Create_Date__c). All mapped fields retain their original values, and any missing required fields are flagged for pre‑migration configuration.

LeadTrac contacts that represent qualified people with a known company relationship migrate to Salesforce Contact. Requires a parent Account record to exist first; LeadTrac contacts without a company link create a placeholder Account. If no matching Account exists, FlitStack creates a temporary placeholder to preserve the contact relationship.

LeadTrac company records map directly to Salesforce Account. Account Name, Website, Industry, Type, Phone, and Address fields migrate. Parent‑child company hierarchies in LeadTrac map to Account.ParentId. All standard address components are migrated as separate billing and shipping fields, and any missing parent Account is created as a root node.

LeadTrac logged calls, emails, and SMS text activities migrate to Salesforce Task records. Subject, Status (Open / Completed), Activity Date, and Description carry over. WhoId links to the Contact or Lead; WhatId links to the Account or Opportunity. The original owner email is resolved to a Salesforce UserId for accurate assignment.

LeadTrac scheduled appointments map to Salesforce Event with original StartDateTime, EndDateTime, Location, and Subject preserved. WhoId and WhatId maintain the person‑and‑record links. Recurring appointments are not natively supported in either platform; single instances migrate individually. All event details, including description and reminder settings, are transferred as custom fields if present.

LeadTrac PDF agreements and uploaded files are downloaded and re‑uploaded as Salesforce Files (ContentVersion). Files are linked to the parent record (Contact, Lead, or Account) via ContentDocumentLink. Docusign envelope metadata does not migrate. File version history and sharing settings are preserved where possible, and any missing parent record is created as a placeholder.

LeadTrac lead status pick‑list values (e.g., New, Contacted, Qualified, Converted) map value‑by‑value to Salesforce Lead Status pick‑list. Any custom status values not present in Salesforce require pick‑list value creation before the migration run. Each unmapped status is logged and can be added to Salesforce via Setup before the migration or handled as a custom field.

LeadTrac owner IDs resolve to Salesforce User records by email match. Unmatched owners are flagged before migration; records are assigned to a designated fallback owner or held for Salesforce user provisioning first. Your admin receives a pre‑migration report listing all unmatched owners and the suggested fallback user for each.

Any LeadTrac custom property not represented in Salesforce's standard field set requires a custom field to be created in Salesforce before data loads. FlitStack delivers a custom field creation plan with API names, data types, and pick‑list value sets for your review.

LeadTrac's client portal access records do not map to a Salesforce native equivalent. Portal reference data is preserved in a custom field (LeadTrac_Portal_Ref__c) for administrative review; Salesforce Community or Experience Cloud setup is handled separately. The custom field stores the original portal username and access level for future reference.

LeadTrac's debt‑settlement Case records map to a Salesforce custom object (e.g., Settlement_Case__c) or the standard Case object if service‑cloud features are in scope. Fields including case status, creditor, balance, and settlement amount require custom field creation. All related activities and attachments are also migrated to maintain a complete case history.

LeadTrac lead source codes and UTM campaign attribution map to Lead.LeadSource (standard pick‑list) plus a custom field (UTM_Source__c, UTM_Medium__c, UTM_Campaign__c) to preserve granular attribution beyond Salesforce's built‑in pick‑list values. Any missing source values are logged and can be added to the pick‑list in Salesforce Setup prior to loading.