Migrate from Foqal to Intercom

Foqal Tickets are the primary support work item and map to either Intercom Conversation (conversation-based model, best for real-time chat and email support) or Intercom Ticket (structured work-item model, best for tracked requests with custom fields and states). The customer chooses the model during scoping based on whether their support use case is conversational or transactional. If choosing Conversation, the Foqal Ticket ID is stored as a custom attribute on the Intercom conversation for lineage tracing. If choosing Ticket, Foqal ticket status (open, pending, resolved, closed) maps to Intercom Ticket state values.

Foqal Conversation threads attached to Tickets map into Intercom Conversation as individual message records. Each message carries the author (agent or end-user), body content, timestamp, and attachment references. We preserve the chronological thread order by setting the Intercom message created_at to the original Foqal timestamp. Any Foqal internal notes (messages visible only to agents) migrate as Intercom internal notes attached to the conversation.

Foqal Agents map to Intercom Admins (full workspace access) or Teammates (limited access by Inbox). We resolve Foqal agent email addresses against the Intercom workspace user list. Any Foqal agent without a matching Intercom user is flagged in the reconciliation report for the customer to provision before the migration phase begins.

Foqal Teams own specific routing rules and SLA targets and map to Intercom Inboxes. Team membership (which agents belong to which team) translates to Inbox assignment in Intercom. We create the Inbox structure in Intercom first, then assign Teammates to each Inbox during migration. Foqal team-level SLA configurations are documented separately for recreation as Intercom SLA Policies linked to the corresponding Inboxes.

Foqal SLA configurations (TTFR targets, wait times, tier definitions for Customer Support and IT) are stored as settings and exported as structured JSON. Intercom SLA Policies are defined per Inbox with first-reply and next-reply targets and business hours. We document each Foqal SLA configuration in the migration inventory and map it to the equivalent Intercom SLA Policy configuration. SLA tier differences between Foqal's Customer Support and IT tiers are preserved as separate SLA Policies in Intercom linked to the corresponding Inboxes.

Foqal automation rules (routing, approval chains, SLA triggers) are configuration-level settings that are not returned as queryable data objects via the API. We flag active workflows during discovery, capture their structure from the Foqal UI where accessible, and document them in the migration inventory as items for manual recreation in Intercom's Workflow builder. We do not migrate workflows as code because the structural difference between Foqal's config model and Intercom's trigger-action model makes automated translation unreliable.

Foqal ApprovalRequest objects use a URN identifier format (ApprovalRequestUrn) and are referenced by workflow approval chains. Intercom has no native approval request object. We document approval chains in the migration inventory and recommend recreating approval logic in Intercom as either Workflow steps with manual assignment or as a Custom Object (created under Settings > Data > Custom Objects) with a lookup to the relevant Conversation. The customer chooses the approach during scoping.

Foqal's native HubSpot sync creates linked relationship pointers between Foqal records and HubSpot Companies, Deals, Contacts, and Notes. We capture these relationship pointers during export and store them as custom attributes on the corresponding Intercom Contact or Company record (e.g., hubspot_company_id__c, hubspot_deal_id__c). The customer rebuilds the HubSpot integration natively in Intercom using the Intercom-HubSpot integration available in Intercom's App Store, pointing to the same HubSpot portal.

Every Foqal conversation thread has an associated end-user contact (requester). We extract unique contact records (email, name, any custom attributes) from the conversation history and pre-import them into Intercom as Contacts before any conversation migration begins. Intercom requires a Contact to exist before a Conversation can be created referencing that Contact, so contact pre-import is a mandatory first phase.

Files attached to Foqal conversation messages migrate as Intercom Content Attachments linked to the corresponding conversation message. We download the file from Foqal (if accessible via URL), upload it to Intercom's content storage, and link it to the message record. File size limits and supported formats follow Intercom's attachment specifications (up to 10 MB per file).

Foqal ticket tags (e.g., billing, bug, feature-request) migrate to Intercom conversation tags. Tags are created automatically in Intercom if they do not already exist at the time of conversation import. We preserve the original tag names for clarity and recommend a tag cleanup pass post-migration to consolidate duplicates.

Foqal's productivity and CSAT reports are computed at query time and are not exportable as standalone data objects. We do not migrate report snapshots. Intercom's native reporting dashboard provides conversation volume, response time, CSAT, and team performance metrics from the date of go-live. Historical Foqal metrics are preserved in any exported PDF or data files the customer holds and can be referenced alongside Intercom's forward-looking reporting.