Migrate from ITSM 365 to Intercom

ITSM 365 Incidents map to Intercom Conversations. The incident number becomes a custom conversation attribute itsm_incident_id for traceability. Priority (Critical, High, Medium, Low) migrates as a custom attribute itsm_priority and as an Intercom conversation tag. Assignment group and assigned technician map to Intercom teammate or team assignment via Inbox Settings. Resolution status and resolved timestamp migrate as custom attributes since Intercom has no native resolution-state field.

Service Requests map to Intercom Conversations similarly to Incidents. The request category and subcategory (ITIL classification) migrate as custom attributes itsm_category and itsm_subcategory. SLA assignment migrates as itsm_sla_name and itsm_sla_deadline custom attributes on the conversation record. Approval status (Pending, Approved, Rejected) has no Intercom equivalent and migrates as itsm_approval_status custom text.

ITSM 365 Changes do not map cleanly to Intercom's native schema. If the customer uses Changes primarily for audit and record-keeping, we migrate them as a Custom Object (e.g., Change Request) with fields for Change ID, type (Normal, Standard, Emergency), risk level, implementation date, and status. If Changes are linked to specific Incidents or Service Requests, we create the Custom Object first, then attach the related conversation via Intercom's Custom Object record linking feature (available from Intercom's Custom Objects API). The customer selects the strategy during scoping.

ITSM 365 Problems (root-cause tracking records) have no direct Intercom equivalent. We recommend migrating Problem records as an Intercom Custom Object (e.g., Problem Record) linked to the related Incident conversations via Custom Object associations. Problem status, root cause description, and known error description migrate as custom fields on the Problem Custom Object. If the customer prefers a lighter approach, we tag related Incident conversations with a problem tag and store the problem description in a linked Note on the primary conversation.

ITSM 365 requester contacts map to Intercom Contacts. The requester email is the primary deduplication key. First name, last name, phone number, and department migrate as standard Intercom Contact attributes. Any custom contact properties from ITSM 365 (e.g., cost center, employee ID) migrate as custom attributes on the Intercom Contact. Intercom requires contacts to exist before conversations referencing them are created, so contact migration is sequenced first in all phases.

ITSM 365 Configuration Items linked to Incidents or Service Requests as affected companies map to Intercom Companies. The CI name becomes the Company name; CI type (Server, Application, Network Device) migrates as a custom attribute ci_type. Company data migrates after contacts since some Intercom contacts are associated with companies via the contact's company_id field.

ITSM 365 SLA objects carry response time, resolution time, business hours calendar, and breached/okay status. Intercom has no native SLA object. We migrate SLA data as conversation-level custom attributes: itsm_sla_name (text), itsm_sla_response_due (datetime), itsm_sla_resolution_due (datetime), and itsm_sla_status (text: Met, Breached, In Progress). Fin AI Agent can be configured to read these attributes and trigger reminder rules based on SLA deadline proximity.

ITSM 365 priority (1-Critical through 5-Low) and urgency (High, Medium, Low) are separate fields in the incident and request schema. Both map to Intercom conversation tags (itsm_priority, itsm_urgency) for filtering in the inbox. Urgency also maps to a custom attribute itsm_urgency for use in Rules-based routing to specific teams. The customer decides during scoping whether to use a combined priority-urgency tag schema or separate tags.

ITSM 365 Standard tier approval chains are workflow objects that route tickets to named approvers with conditional logic. Intercom has no approval workflow engine. We do not migrate approval chains as code or data. We audit every active approval chain, document its trigger conditions, approver sequence, and escalation path, and deliver a written inventory recommending how to recreate the equivalent logic in Intercom using Teammate assignment, Tags, and Fin AI Agent rules. The customer's admin rebuilds the approval logic post-migration.

ITSM 365 workflows ( Lite limited, Standard full) handle auto-assignment, field updates, and escalation triggers. Intercom's Rules engine replaces some routing logic but is not a direct equivalent. We do not migrate workflows as code. We audit every active ITSM 365 workflow, document its trigger, conditions, and actions, and deliver a written inventory recommending which Rules to create in Intercom. The admin configures Rules post-migration. Lite-tier customers with no active workflows receive an empty inventory.