Migrate from Front to Salesforce Service Cloud

Front Conversations map directly to Salesforce Cases. The conversation subject becomes Case Subject, the most recent message body becomes Case Description, and all message segments are flattened into a single thread body with author, timestamp, and content preserved in chronological order. Front conversation status (archived, open, spam) maps to Salesforce Case Status with a custom Status_Mapping__c field tracking the original Front state for audit.

Front Contacts export with name, email, phone, company, and custom properties. We map Front contact handles to standard Salesforce Contact Email and preserve any linked company record as AccountName. Custom properties on Front Contacts migrate to Salesforce custom fields on Contact, with data type mapping applied (text, number, date, boolean, dropdown) and truncation noted where destination field length is shorter.

Each message within a Front conversation is a distinct segment. When migrating to Salesforce, we flatten segments into a single Case thread body, but we also create individual EmailMessage records linked to the Case for each inbound and outbound message so the full per-message timestamp, author, and content are preserved in the Case feed. Front channel attribution (email, chat, SMS, social) migrates as a custom EmailMessage field channel_source__c.

Front Teammates export with name, email, role, and assignment preferences. We match teammates by email address to the Salesforce User directory. Any Teammate without a matching Salesforce User enters a reconciliation queue for the customer's admin to provision before record import. Custom role names from Front map to Salesforce Profiles or Permission Sets.

Front Inboxes define which channels land where and which teammates have access. We map each Inbox to a Salesforce Omni-Channel Queue and associate it with a corresponding Service Channel. Complex permission inheritance across multiple Inboxes requires manual post-migration configuration in Salesforce Setup. The customer's admin rebuilds the Inbox-to-Queue routing during the transition window.

Front Channels represent communication sources (email, chat, SMS, Facebook, Twitter, Instagram, WhatsApp). We map Channel type to Salesforce Case Origin picklist. Channels on Starter-plan accounts that were limited to a single channel are flagged during scoping if their historical data reflects this restriction.

Front Tags applied at conversation level export as flat labels. We map tags to Salesforce Case Tags (if Lightning Flow tagging is enabled) or to a custom multi-select picklist field tag__c on Case. Tag hierarchy and tag-group organization do not carry over as structured metadata; the customer chooses the tagging strategy during scoping.

Front supports custom fields on Conversations (text, number, date, dropdown, boolean). We pre-create matching custom fields on the Salesforce Case object via the metadata API before migration. Data type coercion (Front text to Salesforce text, Front number to Salesforce number) is applied, and character limit truncation is surfaced in a pre-migration field comparison document.

Front Contact custom properties migrate to Salesforce Contact custom fields. We match by property name and map to the closest Salesforce field type. Multi-select and complex structured data types require manual review before migration commits.

Notes attached to Front conversations or contacts export with text content and attribution. We map them to Salesforce Case Feed notes or as ContentDocument records attached via ContentDocumentLink to the Case. The author and timestamp are preserved in the migration.

Front Analytics exports in CSV format with timestamps in the requesting user's timezone. We export available analytics data (Messages export, Full events export) as a structured CSV and deliver it as a reference dataset. Report configurations do not migrate; the customer's admin rebuilds dashboards in Salesforce Reports & Dashboards or Einstein Analytics using the imported data as the source.

Front Automation Rules contain event-condition-action logic, delays, and multi-step actions that are not exposed in the API as reusable templates. We document every active Rule during discovery with its trigger, conditions, actions, and recommended Salesforce Flow equivalent, but we do not migrate the automation logic as code. The customer's admin rebuilds Rules in Salesforce Flow post-migration.