Migrate from Factoreal to Salesforce Sales Cloud

Factoreal Contacts with a defined Account relationship (company name, domain, or business role) map to Salesforce Contact tied to an Account. Contacts without a business company association map to Salesforce Lead. We apply the split rule during the transform phase using Factoreal's company_name field and any role-based property. The original Factoreal contact record ID is preserved in a custom field factoreal_id__c on both Lead and Contact for audit and cross-reference. All custom properties on Factoreal contacts migrate as typed custom fields on the destination object.

Factoreal contacts carrying a company name or domain are used to pre-populate Salesforce Account records before Contact import. The Factoreal company name becomes Account Name; domain becomes Website. Account is inserted before Contact import so that AccountId lookup is satisfied at the moment of Contact insert. Accounts without a Factoreal source contact are created as placeholders and held for reconciliation.

Factoreal Segments are defined by filter rules on contact attributes and behavioral events. We reconstruct segment membership logic as a Salesforce Campaign with Campaign Member Status values, and document the original filter criteria as a structured filter-logic appendix. Because Salesforce does not have dynamic segment membership, we flag to the customer whether the segment should become a static Campaign Member list (full rebuild on demand) or a Salesforce List View for ongoing manual maintenance.

Factoreal Campaigns hold subject lines, content, send history, and engagement metrics (opens, clicks, bounces, unsubscribes). We map these to Salesforce Campaign with Campaign Type set to Email or Digital Advertising depending on channel. Open and click engagement rates migrate to custom numeric fields because Salesforce Campaign stores member-level responses but not aggregate rate percentages natively.

Factoreal automation workflows define trigger conditions and multi-step action sequences across email, SMS, and WhatsApp channels. We capture the full workflow graph — triggers, conditions, delays, branch logic, and action steps — as a written inventory document with a recommended Salesforce Flow equivalent for each workflow. The actual Flow build is outside the migration scope and is a separate engagement or internal admin task.

Factoreal email templates include HTML content and dynamic merge field placeholders. We extract template HTML and convert merge field syntax to Salesforce merge field format. Visual rendering differences between Factoreal's template editor and Salesforce ContentBuilder are expected; we flag formatting anomalies in the template inventory. Email templates migrate as Salesforce Classic Email Templates or ContentBuilder assets depending on the destination org's configuration.

Factoreal captures order records with line items, totals, and transaction timestamps through its built-in e-commerce integration. We map these to Salesforce Order if the destination org includes the Order Management feature; otherwise, we map to a custom Order object (Order__c) with line items as a related custom object (Order_Line_Item__c). Order status, total amount, currency, and the related Contact/Account are preserved.

Factoreal products with SKUs, pricing, and descriptions map to Salesforce Product2. Standard Price Book entries are created during import so that products are available for Opportunities and Orders without requiring a separate pricing configuration step.

Channel-level message logs from SMS and WhatsApp campaigns export as part of Factoreal's contact and campaign data. We map these to Salesforce Task records with TaskSubtype=Call (outbound message variant) and custom fields capturing direction (inbound/outbound), channel type, and message content. No Salesforce standard object natively supports SMS/WhatsApp thread semantics, so the Task-based structure is the closest fit for activity timeline visibility.

Factoreal contacts can carry multiple tags. We export the full tag list per contact and create equivalent values in Salesforce as either a multi-select picklist field (for contact-level tagging) or Salesforce Topics with TopicAssignment records (for content or account-level classification). The customer selects the tagging strategy during scoping.

Factoreal allows custom fields on contact and company records. We identify all custom field definitions during discovery, export their values per record, and map them to Salesforce custom fields with equivalent API-named types (text, number, date, picklist, checkbox, etc.). Custom field metadata is deployed to the Salesforce Sandbox before data migration begins.

Factoreal Owner records map to Salesforce User by email match. Any Factoreal Owner without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before record import proceeds. OwnerId is required on most standard Salesforce objects, so this step gates the Contact and Lead import phases.