Migrate from Force24 to Salesforce Sales Cloud

Force24 Contacts with lifecycle stage indicating a prospect (subscriber, lead, marketing qualified) map to Salesforce Lead. Force24 Contacts with lifecycle stage indicating a qualified buyer (customer, evangelist) map to Salesforce Contact attached to an Account. We compute the split during migration scoping using the lifecycle stage property on each Force24 Contact and write a custom field force24_lifecycle_stage__c on both the destination Lead and Contact to preserve the original classification for reporting and audit. The split rule is agreed with the customer before the first record is written.

Force24 Companies map directly to Salesforce Account. The Force24 company domain and URL become the Account Website field, used as the dedupe key during import. We create Account records before Contact import so that the AccountId Lookup is satisfied at the moment of Contact insert. Force24 company associations on Contacts are preserved by resolving the AccountId on the linked Contact.

Force24 engagement events (email open, click, SMS reply, form submission) are stored per Contact and map to Salesforce Task records for the activity timeline and EmailMessage records for email-specific events. We preserve the engagement timestamp as ActivityDate, the engagement type as a custom Task field (engagement_type__c), and any behavioral metadata (page URL, link clicked, form field values) as custom Task fields. For large engagement histories, we use Salesforce Bulk API 2.0 with batch chunking and exponential backoff to avoid rate-limit rejections.

Force24 Custom Objects (linked-data tables for Bookings, Event Registrations, or other business-specific records) map to Salesforce custom objects with a __c API name derived from the Force24 object name. We pre-create the destination schema in Salesforce — all custom fields, field types, picklist values, and lookup relationships — before importing data. The lookup from Custom Object to Force24 Contact is preserved as a Lookup field to the Salesforce Contact. Custom Objects must be confirmed as active on the Force24 account (account manager activation required) before export; we flag this during discovery.

Force24 tags applied to Contacts migrate as a Salesforce custom field of type Multi-Select Picklist on the Contact object. Each distinct Force24 tag becomes a picklist value. If the tag count exceeds the Salesforce multi-select picklist limit (500 values per field), we create a second custom field or recommend Salesforce Topics with TopicAssignment records as the alternative. The customer chooses the strategy during scoping.

Force24 lead scoring assigns numeric values to Contacts based on engagement and property rules. We export the score value stored on each Contact record and write it to a custom Number field (force24_lead_score__c) on both the Salesforce Lead and Contact. The scoring rules themselves (property thresholds, engagement multipliers) are Force24-configured and documented separately as they require manual rebuild in Salesforce Sales Intelligence, Flow, or a third-party scoring tool.

Force24 Automated Journeys define multi-step, multi-channel workflow logic with conditional branching, wait steps, and behavioural triggers. Journey definitions are stored in Force24's workflow engine and cannot be exported as portable code. We extract each journey's structure — entry trigger, step sequence, branch conditions, wait durations, and exit actions — and deliver a written journey specification document. The customer's admin or a Salesforce implementation partner uses the specification to rebuild the logic in Salesforce Flow or Marketing Cloud Engagement Studio. We do not migrate journey logic as automation code.

Force24 Smart Lists save complex filter combinations against Contacts — property-based, behavioural, and AND/OR conditions — that update in real time. We export the segment criteria (filter logic) and the full contact ID set included in each segment. At the destination, we recreate the segment membership as a Salesforce Campaign with static CampaignMember records, or as a custom List View. Real-time segment behaviour requires manual recreation in Salesforce as a Report or Flow-triggered dynamic list.

Force24 email templates and dynamic content blocks export as HTML. Since Force24 templates reference platform-specific merge fields, we recommend reviewing and adapting templates in Salesforce's Lightning Email Template builder or via Apex email services. We preserve the HTML structure and inline styles; dynamic content blocks require manual reconstruction using Salesforce Merge fields or AMPscript if the destination includes Marketing Cloud.

Force24 forms capture lead data and feed it into Contacts and Journeys. We export form field configurations and all submission records as Contact fields in Salesforce. The form builder itself (the form UI, embed code, styling) cannot migrate; we document the form fields and mapping for reconstruction using Salesforce Web-to-Lead, Experience Cloud forms, or a third-party form tool like Formstack or Typeform integrated via AppExchange.

Force24 distinguishes between Marketing users and Sales users, each with different seat pricing and access levels. We extract all Force24 users by email and map them to Salesforce User records by email match. The Force24 user type (marketing vs sales) is preserved as a custom field (force24_user_type__c) on the Salesforce User for admin reference. Users without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before production migration.

Force24 tracks SMS and WhatsApp message history and delivery records as engagement events against Contacts. These migrate to Salesforce Task records with a custom channel field (message_direction__c: inbound/outbound, message_type__c: SMS/WhatsApp) and custom fields for delivery status, message body, and timestamp. We use Bulk API 2.0 for high-volume SMS histories to avoid batch timeouts.