Migrate from CommBox to Intercom

CommBox Conversations map directly to Intercom Conversations. Each conversation receives its channel source (WhatsApp, email, voice, social) as the Source field value. Message body, timestamps, and agent attribution migrate directly. A single customer journey spanning multiple channels in CommBox becomes a threaded conversation in Intercom with channel attribution preserved on individual message parts rather than siloed per channel.

CommBox Customer records map to Intercom Users (contacts). Name, email, phone, and any custom properties stored on the customer profile card migrate to the Intercom contact profile. External identifiers used for CRM sync (e.g., CRM_ID, External_System_Reference) migrate as custom attributes so the destination admin can reconnect integrations post-migration.

CommBox Agent profiles (name, email, team assignment, role) map to Intercom Admins and Agents. Agent-to-conversation attribution is preserved through the conversation owner field in Intercom. We resolve by email match against the Intercom workspace user list; any CommBox agent without a matching Intercom user goes to a reconciliation queue for manual provisioning before the migration runs.

CommBox Team structure maps to Intercom Teams. Teams are created in Intercom before agent migration so that the team assignment on each agent record can reference an existing Intercom team. SLA configurations tied to specific teams migrate as inbox-level SLA policies in Intercom.

CommBox Custom Fields (tenant-defined key-value pairs on customer profiles) map to Intercom Custom Attributes. We extract every custom field definition from the CommBox environment during discovery, then create matching custom attribute definitions in Intercom before loading data. Field type mapping is explicit: string to text, date to date, number to number, and multi-value fields to list attributes. Fields without a destination equivalent are flagged during scoping for the customer to resolve before migration runs.

CommBox Tags applied to conversations migrate as Intercom Tags. Tag labels and their association with conversation records transfer directly. Intercom Tags can be applied to contacts, conversations, and companies, so the tag namespace is preserved across all three object types in the destination.

CommBox Channel metadata (WhatsApp, email, voice, chat, social) does not have a standalone Intercom object. Instead, we map channel origin as the Source field on each Conversation record, with the specific channel value (e.g., whatsapp, email, voice) set per message. This preserves the omnichannel attribution that CommBox tracks per message without requiring a separate channel object.

CommBox SLA configurations defining response and resolution timers per channel or team migrate as Intercom SLA policies attached to inboxes. We export SLA definitions as structured metadata during discovery and present them as an SLA Configuration Inventory document. The customer configures equivalent policies in Intercom Inbox Settings using this document as a rebuild guide.

CommBox Knowledge Base articles (title, body content, categories, publish status) map to Intercom Articles within Collections and Sections. Intercom supports a three-level hierarchy (Collection > Section > Article), and articles can exist directly under a Collection without a Section. We map CommBox categories to Intercom Collections and map article content preserving publish status. Media embeds within articles may require post-migration formatting adjustments depending on how media is hosted in CommBox.

File attachments embedded in CommBox conversations are extracted via the media API and re-associated with their parent conversation in Intercom. Both inline images and file attachments transfer as Intercom attachments linked to the conversation. We handle encoding normalization so that files opened in CommBox display correctly in Intercom.

CommBox AssignX routing rules (conditions that assign conversations to agents or teams) have no documented export endpoint. We capture routing configuration details during discovery as a Routing Rules Inventory document with screenshots and configuration values. The customer rebuilds equivalent rules in Intercom using the Inbox Rules engine. Routing rules are documented, not migrated, and should be planned as a post-migration configuration task.

CommBox automation scripts (AutoX, IntentX, AssignX, TransformX) are platform-native constructs that cannot export to standard data formats. We document the automation logic during scoping—every trigger, condition, and action—as a Process Inventory document. This becomes the blueprint for rebuilding equivalent automation in Intercom's Fin AI Agent (using Procedures) and the Rules engine. This is a process-migration task requiring the destination admin to rebuild, not a data-migration task.