Migrate from Gladly to Salesforce Service Cloud

Gladly Customer Profiles map directly to Salesforce Contacts, with the Contact's account reference linked to a Salesforce Account derived from the customer's company name or domain. We preserve both the current Gladly Customer ID and any historical IDs from profile merges (the absorbed ID 301-redirects to the surviving ID but the Work Sessions Report retains the old ID) in custom fields gladly_customer_id__c and gladly_historical_id__c on Contact so that merged customer history is fully traceable.

Gladly enforces one open Conversation per Customer Profile, which is a hard architectural constraint with no Salesforce equivalent (Salesforce allows multiple simultaneous Cases per Contact). We split each Gladly Conversation into individual Salesforce Cases by Topic label or by channel type when Topics are absent, creating one Case per distinct issue. The customer's conversation history is preserved as EmailMessage records linked to the first Case, with subsequent Cases referencing the parent Conversation ID in a custom gladly_conversation_id__c field for traceability.

Conversation Items represent individual messages across all Gladly channels (email, SMS, voice call log, chat) within a Conversation. Email items map to Salesforce EmailMessage records; SMS items map to Task records with a custom channel__c field set to SMS; chat messages map to Task records with TaskSubtype = Chat. All items retain the original timestamp, agent attribution (mapped via Gladly User email to Salesforce User), and channel metadata. Voice call dispositions and durations migrate as Task records with TaskSubtype = Call and custom call duration fields.

Gladly Topics are taggable labels applied to Conversations for routing and analytics. Topics migrate to Salesforce Case Topics (Topic object with TopicAssignment records) and optionally to a multi-select picklist case_tag__c field if the destination org uses an older tag model. The customer selects the preferred tag strategy during scoping.

Gladly User records (name, email, role, permissions) map to Salesforce User records by email match. Inactive agents from Gladly map to Salesforce Users with IsActive = false to preserve historical attribution. Any Gladly User without a matching Salesforce User email goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Gladly Work Sessions Report retains old Customer IDs after profile merges, which must be reconciled against the current Customer ID mapping. We export raw CSV reports from Gladly (CSV and UI versions display data differently, so we always use the CSV export), map them to Salesforce Reports built on the migrated Case and Contact objects, and flag any records where the old Customer ID does not match a surviving ID in the mapping table.

Gladly Workflows encode routing logic, spam filtering, required disclosures, and agent handoff rules as configuration rather than data records. There is no API endpoint to export Workflow definitions in bulk. We document the customer's active Workflow configurations during discovery and provide a written specification with trigger conditions, routing rules, disclosure text, and recommended Salesforce Omni-Channel or Flow equivalent. Rebuild is performed by the customer's admin or a Salesforce consultant post-migration.

Gladly Answers articles, categories, and metadata export via Gladly's API or CSV. We map them to Salesforce Knowledge articles (DataCategoryGroup and article types configured per data category structure). AI-generated responses in Gladly Answers do not have a direct Salesforce equivalent; we map the underlying article content and recommend Einstein Copilot or a third-party knowledge-base AI layer as the replacement.

Gladly's custom object configurations (used for brand-specific data mapping like loyalty tiers, order references, or subscription metadata) map to Salesforce custom objects with __c API names. We pre-create the destination schema including all custom fields, lookup relationships, and validation rules before data import. Any custom objects referencing Gladly Customer or Conversation IDs are remapped to Salesforce Contact or Case IDs during the transform phase.

Gladly webhooks with configurable events, retry policies, and endpoints export as a JSON manifest during discovery. We document each active webhook's event type, target URL, payload structure, and authentication method so the customer's admin or integration developer can re-establish event-driven integrations in Salesforce using Platform Events, Outbound Messages, or Flow webhook actions.