Migrate from TeamDynamix IT Service Management to Intercom

TeamDynamix Tickets map to Intercom Conversations with conversation_parts preserving the full reply thread. We map Ticket status (Active, Resolved, Closed) to Intercom's open, closed, and snoozed states. Priority maps from TeamDynamix Priority (Low, Medium, High, Critical) to Intercom conversation priority levels. The Ticket subject and most recent reply become the conversation title and initial message. TeamDynamix's ticket assignee maps to the Intercom conversation assignee via the Teammate lookup.

TeamDynamix portal Users who submit or own Tickets map to Intercom Contacts. We use email as the primary dedupe key. The Contact's name, email, phone, and custom attribute fields migrate to Intercom's standard Contact fields plus any matching Data Attributes created during schema design. Users without email addresses (system accounts) are held in a reconciliation queue.

TeamDynamix does not have a native Company object equivalent to Intercom's Companies, but organizations often store organizational context on Tickets via custom attributes or linked records. We extract any Company-related custom attribute data from Tickets and Contacts and create Intercom Company records, mapping to Intercom's Company name, website, and industry fields. If no organizational data exists in TeamDynamix, we skip this object and note the absence.

TeamDynamix KB articles (HTML content with metadata) map to Intercom Help Center articles. We extract article body as structured HTML, article title, author, creation and modification timestamps, and any KB category assignments. Articles are bulk-imported into Intercom's Help Center via the Articles API after Collections and Sections are created. Article-to-category hierarchy maps to Intercom's Collection > Section > Article structure, though deep nesting (more than two levels) may need flattening per Intercom's model.

TeamDynamix KB categories are hierarchical trees that organize articles. We map the top-level category to an Intercom Collection and any nested subcategories to Sections within that Collection. Intercom supports only two levels of hierarchy (Collection and Section), so TeamDynamix trees deeper than two levels require flattening during migration. We flag deep hierarchies during discovery and present the customer with a flattening option before migration begins.

TeamDynamix Services represent published self-service offerings that link to a Ticket Form, request workflow, and associated KB articles. Intercom does not have a Service Catalog concept. We map each Service to either a Help Center Collection (for catalog-style browsing) or a standalone Help Center Article (for single-request items), preserving the Service name and description. Linked Ticket Forms and request workflows do not migrate; these are documented in the workflow handoff inventory.

TeamDynamix Custom Attributes (typed fields: text, number, choice, date, user reference) attach to Tickets, Contacts, and Services. We map each Custom Attribute to an equivalent Intercom Data Attribute with matching type. Choice fields with defined option lists require explicit re-creation in Intercom's Data Attributes configuration before import. User reference fields that link to TeamDynamix Agents map to Intercom Teammates or are stored as text if the Teammate does not yet exist in Intercom.

TeamDynamix Tags are flat label fields attachable to Tickets and other objects. Tags migrate as Intercom Tags using the Tags API. Tag vocabulary is preserved as-is and recreated in the Intercom workspace. Tags used for ticket classification become conversation tags in Intercom. No tag hierarchy exists in either platform, so no transformation is required.

TeamDynamix Users and Agents with role assignments map to Intercom Teammates. We extract agent records (name, email, role) and provision the corresponding Teammates in Intercom via the Admin API. Agent permissions and group memberships do not have a direct Intercom equivalent; we document the TeamDynamix role structure in the configuration handoff and the customer's admin recreates Inbox permissions in Intercom. Passwords and SSO tokens cannot migrate and require re-authentication on first login.

TeamDynamix Ticket Workflows define the state machine for ticket lifecycle stages with routing rules and escalation triggers. Intercom's Workflows are conversation-level automations with different trigger models (new conversation, status change, tag applied). These are fundamentally different automation paradigms. We document every TeamDynamix Ticket Workflow in a written inventory covering stages, routing logic, escalation triggers, and SLA thresholds, and recommend equivalent Intercom Workflow Builder actions. Workflows are not migrated as executable code. This is a high-severity scope limitation.

TeamDynamix Ticket Forms control which fields appear to users during ticket creation and reference both standard and custom attributes. Intercom has no form builder for ticket intake beyond the Messenger's default conversation start fields. We map form field labels to Intercom article content (if the form serves as a request guide) or document the form structure in the configuration handoff. No equivalent configuration exists in Intercom for multi-field intake forms.

TeamDynamix Assets (hardware and software inventory) and Configuration Items with relationship mappings have no Intercom equivalent. These do not migrate. We extract a full asset inventory as a structured CSV report during discovery for the customer's records, noting that Intercom is not designed for IT asset management and a separate ITAM tool would be required for ongoing asset tracking post-migration.