Migrate from Re:amaze to Salesforce Service Cloud

Re:amaze Conversations map to Salesforce Cases. Each conversation's subject, category, message thread, assignee email, status, and timestamps (created_at, updated_at) migrate as Case fields (Subject, Description, OwnerId, Status, CreatedDate, LastModifiedDate). The message thread becomes the Case thread using EmailMessage records linked to the Case. Conversation status (open, resolved, snoozed) maps to Salesforce Case Status values that we configure in the destination org during schema setup.

Re:amaze Contacts map directly to Salesforce Contacts. The contact's name, email, phone, and computed attributes (browser, location, last seen) migrate to the equivalent Salesforce Contact fields. We resolve the Account lookup by matching the contact's domain against existing Salesforce Accounts or creating a new Account during the pass. Custom field values from Re:amaze attach as Salesforce custom fields on the Contact record.

Re:amaze does not expose a Custom Field definition endpoint, so we discover custom fields by sampling 50-100 contact records and extracting non-standard keys. Each discovered field maps to a Salesforce custom field of equivalent type (text, number, date, checkbox, picklist). We create the Salesforce custom fields before the Contact import pass and validate the field types against the sampled data to avoid type-mismatch rejections at import time.

Re:amaze tags on conversations are a flat string list per record with no hierarchy. We migrate tags as a multi-select picklist on Case (CaseTag__c) or as Salesforce Topics with TopicAssignment records depending on the customer's reporting needs identified during scoping. Admin-created tags and agent-applied tags carry no distinction at migration time; both become tag values in Salesforce.

Quick Answers are canned response templates grouped by category with title, content body, and optional shortcode. We export the full Quick Answer library including HTML formatting and deliver it as a documented template library with Salesforce Email Template equivalent mapping. We do not migrate Quick Answers as Salesforce Email Templates because the content requires formatting review and the shortcode model has no direct Salesforce equivalent. The customer's admin rebuilds them as Salesforce Email Templates or Flow actions post-migration.

Re:amaze FAQ articles are searchable, category-grouped, and embeddable. We map them to Salesforce Knowledge Articles by creating an Article Type matching the Re:amaze category structure, configuring Data Category Groups to match the category hierarchy, and migrating article content, publish status, and category assignment. Articles with embedded images require URL rewriting to Salesforce's document storage. Publish status (draft, published, archived) maps to Salesforce Knowledge Article Version Status.

Re:amaze multibrand hosts multiple customer-facing brands under separate subdomains within a single account. Each brand's conversations, contacts, and KB articles scope to one migration pass using the brand's subdomain. We either create a separate Salesforce org for each brand (if isolation is required) or use an Account hierarchy where each brand is a child Account under a parent organization Account. The customer decides during scoping.

Re:amaze Agents (name, email, role: admin or agent, avatar, availability status) map to Salesforce Users. We resolve agents by email match against the destination org's User table. Agents without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before Case import begins because OwnerId is required on Case records.

Conversation message attachments and contact profile attachments export as files with metadata. We download files from Re:amaze's CDN or signed URLs, upload them to Salesforce Files (ContentDocument), and link them to the parent Case or Contact via ContentDocumentLink. Files over 25 MB are chunked per Salesforce's document storage limits.

Re:amaze integrations with Shopify, BigCommerce, Magento, and other e-commerce platforms store connection state server-side with OAuth credentials and webhook URLs that cannot be extracted in transferable form. We document the integration list during scoping and flag each one for manual reconfiguration post-migration. The e-commerce order and customer context that appeared inside Re:amaze conversations does not migrate as structured data unless the customer has exported that data separately.