Migrate from Fluent Support to Salesforce Service Cloud

Fluent Support Tickets map directly to Salesforce Case records. We extract ticket_id, customer_id, agent_id, mailbox_id, product_id, priority, status, title, content, source, and created_at from fs_tickets and map them to CaseNumber (source ticket ID stored as external reference), ContactId (via Customer mapping), OwnerId (via Agent mapping), Origin, Priority, Status, Subject, Description, and CreatedDate. The source platform's 'normal/high/low' priority values translate to Salesforce Low/Medium/High or a custom priority picklist that we configure before migration.

Fluent Support Customer records are WordPress users with profile data including email, name, and privacy settings. We map WordPress user IDs to Salesforce Contact records using email as the primary matching key. The Contact's account is resolved via the Account lookup from the destination side; if no matching Account exists, we create one using the customer's email domain as the Account name. Customer-specific custom fields from Fluent Support migrate to custom Contact fields on the same object.

Each Fluent Support Ticket has one or more conversation entries in fs_conversations. We migrate the full back-and-forth as Salesforce EmailMessage records linked to the Case (for email-style thread entries) or CaseComment records (for internal note-style entries). Author type (customer vs agent) determines the MessageDirection (Inbound/Outbound) on EmailMessage. Timestamps from fs_conversations.created_at preserve the original sequence. If the source ticket uses a portal-style conversation format rather than email-style, we flatten it to EmailMessage body text with author attribution preserved.

Fluent Support Agents are WordPress users with assigned support roles. We map source WordPress user IDs to Salesforce User records by email address. We flag any Agent without a matching Salesforce User for manual provisioning before migration begins. Agent role-level permissions (admin vs agent) map to Salesforce Profile assignments; we document the mapping during scoping and the customer's Salesforce admin applies the correct profiles during user provisioning. Open Tickets assigned to a source agent reassign to the corresponding Salesforce User during migration.

Fluent Support Tickets carry priority fields (priority and client_priority) with values normal, high, or low. We map these directly to Salesforce Case Priority field values (Low, Medium, High) with configurable value translation if the destination org uses a custom priority picklist. We extract the raw priority value and a priority_changed_at timestamp if available in the source to preserve any priority escalation history.

Files attached to Fluent Support Tickets and Conversations are stored in the WordPress media library or plugin-specific upload directories. We extract attachment URLs, file names, MIME types, and file sizes, download each file, and upload as Salesforce ContentVersion records. ContentDocumentLink records attach each file to the migrated Case. We preserve the original file name and any source URL reference as a ContentVersion custom field for audit traceability. Files over 25 MB require chunked upload handling via the Salesforce Bulk API for ContentVersion.

Fluent Support Tags on Tickets and Customers are flat key-value arrays. We migrate tags to a Salesforce custom field on Case (for ticket tags) and a custom field on Contact (for customer tags) as a multi-select picklist if the total unique tag count stays under 150 values. For tag counts exceeding 150 unique values, we recommend a custom Tag__c junction object with a lookup to Case and a text-based Tag Name field to avoid picklist governance limits.

Fluent Support conditional custom fields have field-level visibility rules stored as UI preferences rather than structured configuration. We extract all custom field definitions (name, type, options) and their per-ticket values from fs_tickets and fs_ticket_custom_values. We pre-create equivalent custom fields on the Case object in the destination org before migration, with field types matched (text, number, date, picklist). The conditional visibility logic (field X shown only if field A = value B) does not migrate; we document every conditional rule in a Custom Field Inventory worksheet for manual rebuild in Salesforce Lightning Record Page conditional visibility.

Fluent Support Mailboxes define incoming channel sources (email, portal) tied to the WordPress site's domain and email routing configuration. These references are WordPress-site-specific and not portable. We flag every Mailbox association during discovery, document what each source mailbox_id maps to in Salesforce (which Email-to-Case address, which Case Origin value, which Queue or Record Type), and provide a routing reconfiguration worksheet. Email routing rules (reply-to addresses, POP/IMAP inbox mappings) require manual reconfiguration in Salesforce Setup after migration.

Fluent Support Tickets can be tagged to a Product with a product_id and product_source referencing a specific WordPress plugin or integration. We map product associations to Salesforce Product2 records if the destination org uses products for service ticketing. Product names migrate as Product2.Name, product_source as a custom Product2 field for source system reference, and product_id as an external ID field. If the destination org does not use Product2 for service tickets, we store the product reference as a custom Case field instead.

Fluent Support Workflows define sequences of tasks triggered manually or automatically by conditions (ticket created, status changed, agent assigned). The underlying rule logic is not exposed as structured JSON or YAML in the database schema. We catalog every active workflow by name, trigger type, action sequence, and conditions, and deliver a Workflow Inventory document with recommended Salesforce Flow equivalents (record-triggered Flow for ticket-created triggers, scheduled Flow for SLA reminders). Workflows do not migrate as code; the customer's Salesforce admin rebuilds them in Flow Builder post-migration.

Fluent Support generates personal and team performance reports (Resolve Stats, Response Stats, Ticket Stats) computed dynamically from ticket data. These reports are not persisted as database rows and cannot be migrated. We recommend exporting key report screenshots and data snapshots before migration cutoff. In Salesforce, we configure standard Service Cloud reports (Cases by Status, Cases by Priority, Agent Workload, First Response Time) post-migration using the Report Builder.