Migrate from Gorgias to Salesforce Service Cloud

Gorgias Tickets map to Salesforce Cases as the primary support record. The Ticket ID becomes a custom external ID field (gorgias_ticket_id__c) for deduplication on re-migration. Ticket status (open, pending, resolved, closed) maps to Case Status values that we configure in the destination org. Priority maps to Case Priority. Channel (email, chat, phone) maps to Case Origin. We resolve the assignee by matching the Gorgias agent email to a Salesforce User record.

Gorgias Customer records map to Salesforce Contacts, with the customer's email as the dedupe key. Each Customer may have multiple Tickets; we resolve the Contact record once, then link all related Cases to that ContactId. If the destination org uses Account records, we use the Customer's domain or company name to resolve an AccountId and link the Contact to it. Any orphaned Contacts without an Account are flagged in the reconciliation report.

Individual messages within a Gorgias Ticket (public replies and internal notes) map to Salesforce CaseComment records. We preserve the comment body, author (mapped to a Salesforce User by email), timestamp, and the is-public flag. Public comments become CaseComment.isPublished = true; internal notes become isPublished = false. Attachments on conversations download and re-upload as ContentDocument records linked via ContentDocumentLink.

Gorgias Agents map to Salesforce Users. We match by email address to the destination User record. Agents without a matching Salesforce User go into a reconciliation queue for the customer's admin to provision before migration. Group memberships map to Salesforce Queues (for case assignment) and Public Groups (for org access), which we configure before the case import phase.

Gorgias Groups (also called Teams) organize agents for routing and assignment. We map Groups to Salesforce Queues for case routing and to Salesforce Public Groups for agent access scoping. Each Queue is created in the destination org during schema setup, and Agent-to-Group memberships are resolved as QueueMembership records.

Gorgias Macros (saved reply templates with variable substitution and dynamic actions) are documented for admin rebuild rather than migrated as code. We export the full macro body, conditions, and action sequence into a written inventory that maps each macro to a Salesforce Email Template with merge fields, or a Salesforce Flow equivalent for macros with routing or tag-assignment actions. Macros in draft status are flagged separately.

Gorgias Rules define ticket routing, assignment conditions, and auto-responses. Rules are documented as a written inventory with trigger conditions, filters, and action sequences mapped to Salesforce Flow equivalents (record-triggered Flow for assignment conditions, scheduled Flow for SLA escalation). We do not migrate Rules as code. Active rules, trippable rules (rules that fired in error and were disabled), and draft rules are documented separately.

Gorgias Views are saved filter configurations organizing the ticket queue. We export the filter logic (field conditions, operators, sort order) and recreate them as Salesforce List Views on the Case object. Complex Views with nested conditions are documented in the handoff report with the equivalent Salesforce filter syntax.

Gorgias custom fields on Tickets and Customers (string, boolean, date, number, select, multi-select types) map to Salesforce Custom Fields on Case and Contact respectively. Select and multi-select fields map to Salesforce picklist and multi-select picklist with the source picklist values imported as allowed values. Date fields map to Date fields. Boolean maps to Checkbox. Number fields map to Number with precision preserved.

CSAT ratings submitted via Gorgias's built-in satisfaction survey are associated with Tickets. We migrate the rating score (1-5 scale) and free-text response as custom fields on the Case (csat_rating__c and csat_response__c). The survey submission timestamp migrates as a custom field csat_submitted_at__c. We flag any CSAT records that reference deleted Tickets during the migration as orphaned and report them separately.

Gorgias Knowledge Base categories with name, position, and locale translations map to Salesforce Knowledge data categories or article folder structure. Category hierarchy (parent-child relationships) is preserved as a Salesforce Knowledge category tree. Multi-locale category names are captured by enumerating enabled locales from the Gorgias account settings and issuing a separate API fetch per locale.

Gorgias KB articles (title, HTML body, author, folder assignment, status, and locale translations) map to Salesforce Knowledge Article records. Article body content migrates as HTML; author attribution is stored in a custom field. Articles in draft status are flagged for separate import with the ArticleType set to Draft. Multi-locale translations are enumerated per locale via separate API calls and inserted as Salesforce Knowledge article versions per locale.

Tags applied to Gorgias Tickets and Customers migrate to a Salesforce multi-select picklist field on Case (ticket_tags__c). We preserve the tag names as-is and flag any tag names that conflict with reserved Salesforce field names or special characters. Tags with high cardinality (over 50 distinct values) are documented for review; the customer chooses whether to use a multi-select picklist or a custom tagging object during scoping.