Migrate from ChannelReply to Salesforce Service Cloud

Each ChannelReply ticket becomes a Salesforce Case. The ticket ID is preserved in a custom field cr_ticket_id__c for cross-reference. Subject line is constructed from the marketplace channel prefix (Amazon, eBay, Walmart) plus the order ID or message subject. Case Origin maps from the ChannelReply marketplace tag (Amazon_MWS, Amazon_SPAPI, eBay, Walmart, Etsy, Shopify, BackMarket, Newegg, WooCommerce) to a corresponding Salesforce Case Origin value we configure before migration. Status is set to the ChannelReply ticket status (Open, Pending, Solved, Closed) mapped to Salesforce Case Status values.

Each ChannelReply message becomes a Salesforce EmailMessage record attached to the parent Case. The first inbound message from the marketplace creates an EmailMessage with Incoming=true; agent replies from the helpdesk create EmailMessage with Incoming=false. Threading is preserved by setting the EmailMessage.parentId to the Case ID and maintaining the email MessageDate as the original timestamp. HTML body and plain-text body are both preserved. Attachments migrate as ContentDocument records linked via ContentDocumentLink.

ChannelReply pushes order-level data into helpdesk custom fields: Order ID, Order Status, Order Total, Customer Name, Shipping Address, Buyer Location, SKU, Shipping Fee, Payment Method, and Item Title. We pre-create equivalent custom fields on the Salesforce Case object (cr_order_id__c, cr_order_status__c, cr_order_total__c, cr_customer_name__c, cr_shipping_address__c, cr_buyer_location__c, cr_sku__c, cr_shipping_fee__c, cr_payment_method__c, cr_item_title__c). Field types are mapped: text fields for IDs and names, currency for totals and fees, picklist for order status, and address compound field for shipping address. Schema is deployed into Sandbox first for validation before production.

ChannelReply applies marketplace-specific tags to tickets to identify channel source. These tags migrate to a custom multi-select picklist field cr_marketplace_source__c on Case. Each unique tag value (amazon, ebay, walmart, etsy, shopify, backmarket, newegg, woocommerce) becomes a picklist value. We also create a Case Origin mapping so that the Salesforce native Origin field reflects the channel and the tag field carries the full ChannelReply tag string for audit.

ChannelReply buyer data (customer name, email, shipping address) is stored as custom field values on tickets rather than as standalone contact records. During migration we extract buyer email addresses, check for matching Salesforce Contacts, and link each Case to the resolved Contact via the Case.ContactId lookup. Unresolved emails are flagged in a reconciliation report for the customer admin to manually merge or create Contact records. Buyer shipping address migrates to the Contact's MailingAddress and to the cr_shipping_address__c custom field on Case.

ChannelReply records in-ticket actions (Amazon Mark as No Response, eBay Resolution Center cases, Etsy shipping uploads, cancellations, refunds) as ticket history events. We capture these as Case History entries (populated via the Salesforce API rather than the standard Case History object which has limited API access) and as Task records with TaskSubtype=Task and a custom field cr_action_type__c indicating the action taken. The original timestamp and actor are preserved. This is a non-standard migration path requiring Apex or Bulk API with the soft-validate bypass approach.

ChannelReply distinguishes customer messages (required, counted) from system notifications (optional, some counted). We audit the customer's active notification settings during scoping and separate system notifications into a distinct data class. Automated system notifications migrate as internal Case comments (IsPublished=false) so agents can see them in the timeline without surfacing them as customer-facing messages. Notification settings themselves are not migratable as configuration data.

ChannelReply stores per-marketplace and per-account agent signatures. We export these as text configuration data during migration. Salesforce does not have per-marketplace account signatures natively, so we deliver a written handoff document mapping each ChannelReply signature to the corresponding Salesforce Email Template or Case Auto-Response Rule the customer's admin should configure post-migration. This is a manual rebuild step outside migration scope.

ChannelReply stores each marketplace's API credentials (Amazon MWS/SP-API keys, eBay OAuth tokens, Walmart tokens, Etsy API keys) and cannot export them. During migration we deliver a marketplace reconnection checklist specifying the required permission scopes for each platform (e.g., SP-API sellingPartnerApiRoles for Amazon, eBay OAuth with Resolution Center scope) and the Salesforce Connected App configuration needed to use those credentials inside Service Cloud. The customer's admin manually re-authenticates each marketplace account post-migration. We do not handle the reconnection itself.

ChannelReply delivers Shopify messages via standard email routed to the connected helpdesk, not through a marketplace API. This means Shopify messages thread through the helpdesk's native email handler rather than ChannelReply's threaded conversation view. We flag Shopify as a separate message channel during scoping and handle its data as standard email-to-ticket records. In Salesforce Service Cloud, this maps to Email-to-Case routing, which requires the customer's admin to configure the Salesforce Email-to-Case address with the Shopify mailbox. Full message content transfers but ChannelReply's marketplace metadata enrichment (Order ID, SKU, Buyer Location) does not apply to Shopify messages because ChannelReply does not attach that metadata via email.