Migrate from Foqal to Salesforce Service Cloud

Foqal Tickets map directly to Salesforce Case records. We preserve ticket status (open, pending, resolved, closed), priority (low, medium, high, urgent), Foqal ticket ID as a custom external reference field (foqal_ticket_id__c), and all standard Foqal metadata. The Case Origin maps from Foqal's channel field (Slack, Teams, email, web). Historical timestamps on CreatedDate and ClosedDate are preserved from the Foqal response. Foqal ticket channels map to Case Origin values configured in the destination Salesforce org.

Foqal conversation threads attached to a Ticket migrate to Salesforce as EmailMessage records (for email-style messages) and CaseComment records (for internal notes). Each message preserves its timestamp, attributed user or agent, and message body. Attachment references migrate as ContentDocumentLink records pointing to the parent Case. Thread chronology is preserved by ordering messages against the original Foqal timestamp. If the Foqal export returns messages with a non-standard structure, we reconstruct the thread from the API response and flatten it into the appropriate Salesforce object.

Foqal Agent records (name, email, role, team assignment) map to Salesforce User records. We match agents by email against the destination org's User table. Any Foqal Agent without a matching User goes to a reconciliation queue for the customer's Salesforce admin to provision before record migration. Agent role (admin, agent) maps to Salesforce Profile and Role assignments that we configure in the destination org before migration.

Foqal Teams map to Salesforce Queues for case routing or Groups for team-level visibility. We determine the correct Salesforce object type during scoping based on whether the Foqal team owns SLA policies and routing rules. Team membership migrates as QueueGroupMember records (for Queues) or GroupMember records (for Groups). If the destination org uses Omnichannel, the Queue maps to an Omnichannel Configuration for skill-based routing.

Foqal SLA configurations (TTFR targets, wait times, tier definitions per Enterprise/Premium/Free) map to Salesforce Entitlement Processes and Milestones. Each Foqal SLA tier becomes a Salesforce Entitlement Process with Milestones representing First Response and Resolution targets. We export the Foqal SLA definitions during discovery and configure the equivalent Entitlement Process in the destination org before ticket migration begins, then link Entitlement records to Cases during the migration load.

Foqal automation rules (routing triggers, approval chains, SLA enforcement) are stored as configuration settings, not as queryable API objects. We export the workflow definitions from Foqal's UI-level settings where accessible and document them as a written inventory with trigger conditions, actions, and recommended Salesforce Flow equivalents. We do not migrate workflows as code because the underlying automation models are incompatible. The customer's admin rebuilds them in Salesforce Flow post-migration.

Foqal ApprovalRequest objects use a URN identifier format (ApprovalRequestUrn) and are referenced by workflow approvals. These URNs have no Salesforce equivalent and must be reconstructed. We document every active ApprovalRequest with its triggering rule, approver chain, and SLA dependency, then deliver this as a written handoff for the customer's admin to model as a Salesforce Approval Process. We do not migrate approval logic as executable code.

Foqal maintains a bidirectional sync with HubSpot for Companies, Deals, and Contacts. If the customer moves HubSpot data to Salesforce Sales Cloud as part of this migration, we migrate the HubSpot Company as Account, HubSpot Contact as Contact, and HubSpot Deal as Opportunity in the same migration scope. If the customer keeps HubSpot, we preserve the Foqal sync pointers as reference notes in the destination and recommend a HubSpot-Salesforce native sync post-migration.

Foqal's Jira sync creates ticket context links between Foqal Tickets and Jira issues. These integration pointers are connection-level configs with no exportable URN-to-URN mapping. We document which Jira projects were linked to which Foqal queues and deliver a written list of the connections for the customer to re-establish via the Jira-Salesforce connector (or a third-party integration tool) after migration.

Same as Jira: Foqal's ServiceNow sync creates bidirectional links between support tickets and ServiceNow records. These link pointers are not exportable as standalone data. We document which ServiceNow tables were linked to which Foqal queues and deliver the inventory for manual reconnection in the destination org using Salesforce's native integration or MuleSoft.

Foqal's productivity and CSAT reporting is computed from ticket data at query time, not stored as standalone objects. These reports cannot be exported and do not migrate. We do not migrate report snapshots. The customer's admin builds equivalent Salesforce Reports on the migrated Case object post-migration. We provide a metric mapping table listing Foqal report dimensions (ticket volume, CSAT score, first response time) and their Salesforce report equivalents (Case reports, Entitlement reports, Service Contract reports) to guide the rebuild.