Migrate from Dynamics 365 Customer Service to Intercom

Dynamics 365 Customer Service Cases map to Intercom Conversations. The Case title becomes the Conversation subject, casepriority maps to a Conversation priority attribute, incident state (active/resolved/cancelled) maps to Conversation state (open/closed/snoozed). Created-on and modified-on timestamps are preserved. Cases are the root record; we resolve the parent Contact and Account references first so that each Conversation is created against the correct User and Company in Intercom before the Case details are written.

Dynamics CE Contact records map to Intercom Users. We use the contact's email address as the dedupe key. Full name splits to first_name and last_name, and communication preferences map to has_email_opened, has_unsubscribed, and email_verified custom attributes. Contacts without an email address map to Leads in Intercom until an email is available for promotion to User.

Dynamics 365 Account records map to Intercom Companies. The Account name becomes the Company name, address fields map to city, region, country, and postal_code, and the Account website URL maps to the Company website field. Company is created before the linked Contact so that the User can be attached to the Company at migration time.

Dynamics Email activities linked to a Case via regardingobjectid map to Intercom Conversation Message parts. The email body migrates as an inbound or outbound Message part based on the activity directioncode (incoming = user message, outgoing = admin message). We preserve the original timestamp and sender address. Attachments on the Email activity migrate as Conversation file attachments.

Dynamics Phone Call activities migrate as Notes attached to the relevant User record (and optionally linked to the Conversation if a Case is associated). Call duration, disposition, direction, and subject map to custom note attributes in Intercom. Voice recordings stored as external SharePoint or blob URLs are listed in the channel-asset report for the customer's admin to re-upload or re-link post-migration.

Dynamics Task activities migrate as Conversation Notes or admin-part type messages depending on whether the task is a customer-facing action. Task subject, due date, priority, and status migrate. Completed tasks set the Conversation to closed if no open items remain; open tasks are logged as internal notes with a due date attribute.

Dynamics Appointment activities migrate as Conversation Notes with the meeting subject, start and end time, location, and required attendees listed as plain text in the note body. No native calendar integration is created in Intercom; the admin configures any calendar sync separately via the Intercom app store or a Zapier or Make workflow.

Dynamics Knowledge Articles map to Intercom Articles. Article title and body (HTML content) migrate directly; we strip HTML formatting that Intercom's renderer does not support. The Knowledge Article status (draft, published, archived) maps to Article visibility (draft = internal only, published = live, archived = archived). Article category and section hierarchy in Dynamics maps to Intercom Collections and Sections, which we flatten to match Intercom's two-level taxonomy. Language versioning is preserved where Intercom supports it; multi-language articles are split into separate Intercom articles with locale attributes.

Dynamics Queues (holding Cases and Activities awaiting assignment) map to Intercom Teams. Each Queue becomes a Team, and queue members map to Team members. Unified Routing decision tables, skill-based assignment, and capacity-based distribution do not migrate because Intercom's routing is rule-based (assignment rules by conversation attribute) rather than capacity-aware. We document the active Queue-to-Routing logic as part of the automation inventory so that the admin can configure equivalent assignment rules in Intercom.

Dynamics Entitlements represent support contracts with allocated hours, case count limits, channel restrictions, and SLA linkage. Intercom has no native Entitlement equivalent at lower plans. We write Entitlements as a structured custom attribute block on each migrated Conversation (contract_name, remaining_hours, channel_restrictions, start_date, expiry_date) so that the customer can reference contract terms during support and configure SLA enforcement manually or via an Intercom SLA policy (Advanced plan). We deliver a separate Entitlements inventory document listing every active contract for admin review.

Dynamics SLA definitions (first response time, resolution time, business hours, pause conditions, warning thresholds) cannot migrate as operational SLA configurations in Intercom because SLA Policies are only available on Intercom's Advanced plan. We export every SLA definition and active SLA instance on open Cases, then write them as structured custom attributes on each Conversation. If the destination is on Intercom Advanced, we configure the SLA Policy using the migrated SLA terms and document the mapping. If on Growth or lower, the admin sets up manual KPI tracking.

Dynamics customers extending the data model with custom Dataverse tables and columns are inventoried during scoping. Single-value custom columns on Contact map to Intercom custom User attributes. Single-value custom columns on Account map to Intercom custom Company attributes. Custom tables (standalone objects) have no direct Intercom equivalent; we assess whether the custom table data belongs on a User attribute (serialised as JSON), a Company attribute, or a Note, and document the chosen approach during schema design. Option-set values require a value-map to ensure picklist consistency in Intercom.

Dynamics attachments on the annotation table linked to Cases, Contacts, or Accounts migrate as Intercom Conversation attachments (for inline attachments on active conversations) or Notes on the relevant User or Company. Files are downloaded from the source (SharePoint or Dataverse file columns), chunked if over Intercom's 10 MB per-file limit, and uploaded via the Intercom attachments API. We preserve the original filename and MIME type.

Cloud flows in Power Automate that trigger on Case create, update, or status change are first-class business logic but live in Power Automate, not in Dataverse rows. They cannot be exported as part of a normal record migration. We inventory every active flow, identify which trigger Case state changes, and deliver a written Flow inventory with trigger, conditions, actions, and a recommended Intercom workflow equivalent (or a Zapier/Make scenario). The customer's admin rebuilds the equivalent automation in Intercom's Workflow builder post-migration.