Migrate from Request Manager to Intercom

Request Manager Tickets map directly to Intercom Conversations. The ticket Subject maps to the Conversation title or first message subject, and the ticket Description becomes the initial user message in the conversation thread. Ticket status (Draft, Submitted, Under Review, Approved, Closed) maps to Intercom Conversation state values (open, resolved, snoozed) with a custom data field original_status__c preserving the Request Manager status for audit. Created_at and updated_at timestamps transfer to the conversation open_time and last_contact_at fields.

Request Manager Requester profiles map to Intercom Contacts. We preserve the requester's name, email address, department, and contact details. Email serves as the dedupe key during import. Where Request Manager stores the requester's role or title, we map it to the Intercom Contact's job_title or a custom attribute. Active versus inactive requester status maps to Contact unsubscribed or contact attributes in Intercom.

Request Manager's approval chain (approver identities, step order, approval status, and timestamp) has no native Intercom equivalent. Intercom does not include a multi-step approval workflow feature. We capture the full approval chain as Intercom Custom Data attributes on the Conversation: approver_1_name__s, approver_1_status__s, approver_1_timestamp__t, approver_2_name__s, and so on through all steps. The approval chain sequence is preserved but must be reimplemented in Intercom Workflows by the customer's admin post-migration as a separate engagement.

File attachments on Request Manager tickets are extracted with filename, MIME type, and binary content. We upload each file to the associated Intercom Conversation using the Conversations API attachment endpoint (POST /conversations/{id}/parts). Files larger than 10 MB are handled via the attachments upload flow with presigned URLs. Attachments that were private within Request Manager are noted; Intercom attachments on open conversations are visible to both the customer contact and the assigned team.

Request Manager ticket comments and internal notes migrate to Intercom Conversation Parts. The comment body, author identity, and timestamp transfer. We distinguish between public-facing comments (mapped to Intercom part_type = comment from user or admin) and internal notes (mapped to part_type = note, visible only to the team). Author resolution uses the Request Manager requester or approver identity mapped to the corresponding Intercom Contact or Admin record.

Request Manager custom fields added per organization (e.g., cost center, request category, business justification) require per-customer field mapping. We extract the full custom field schema during scoping, map each to an Intercom Custom Data attribute with the appropriate type (string, number, boolean, date), and apply the mapping during transformation. Custom fields that do not have a natural Intercom equivalent are stored as string attributes with the original field name preserved.

Request Manager Priority values (Low, Medium, High, Critical) transfer to an Intercom Custom Data attribute priority__s on the Conversation. The categorical values are preserved verbatim; we do not re-normalize the priority scale unless explicitly requested. If the customer uses Intercom's SLA features, we coordinate priority mapping to the SLA tier during scoping.

Request Manager ticket statuses (Draft, Submitted, Under Review, Approved, Closed) map to Intercom Conversation states. We configure the mapping during scoping: Submitted maps to open, Under Review maps to open with a custom state tag, Approved maps to resolved, and Closed maps to resolved or snoozed depending on the customer's workflow. The original Request Manager status is preserved in original_status__s for reconciliation.

Department assignments on Request Manager tickets map to Intercom Teams. Each unique Request Manager department becomes an Intercom Team, and the Team's Inbox receives conversations routed by department. If Request Manager uses department-based routing, we configure the corresponding Intercom Inbox assignment rules during the migration. Teams without a matching Intercom Team go to a reconciliation queue for the customer's admin to configure before production migration.

Request Manager users who are administrators or approvers map to Intercom Admins. We extract all distinct Request Manager users referenced on ticket records, resolve their email addresses, and match against the Intercom workspace's Admin list. Any Request Manager user without a matching Intercom Admin is held in the reconciliation queue for the customer's admin to provision before the migration phase begins.