Migrate from Slaask to Freshdesk

Slaask Conversations are the primary migratable objects, representing a single visitor chat session routed into a Slack channel. We extract conversation metadata (visitor name, page URL, timestamp, conversation status) and map it to Freshdesk Ticket. The Slaask conversation ID is preserved in a custom field slaask_conversation_id__c for audit traceability. Since Slaask had no native status or priority model, we assign defaults based on whether the conversation was open or archived at export time. If the conversation was routed to Slack, we cross-reference with the Slack channel export to pull the full message thread.

Messages within each Slaask Conversation migrate as Freshdesk conversation events attached to the parent Ticket. We preserve chronological ordering using the original Slaask timestamp, author attribution (agent name or visitor name), and message body. Message attachments migrate as Freshdesk ticket attachments. For conversations that existed only in Slaask's own storage and were not mirrored to Slack, the message history is at risk of being unrecoverable; we flag this gap in the pre-migration data audit.

Slaask Visitor records contain name, email, and metadata captured via Custom Attributes. We map these to Freshdesk Customers (Contacts), preserving the visitor's email as the primary identifier and name as the Customer display name. Visitors without an email address are assigned a slaask-generated placeholder email and flagged in the reconciliation report for customer review. Each Visitor is deduplicated by email address before import to prevent duplicate Freshdesk Contact records.

Slaask Custom Attributes were per-workspace key-value fields attached to Visitor profiles. We treat each Slaask custom attribute as a Freshdesk Contact custom field. Field types are mapped: text attributes become Freshdesk text fields, boolean attributes become checkboxes, date attributes become Freshdesk date fields. The Freshdesk Contact custom field schema is pre-created before Contact migration begins. We document any attributes that cannot be typed-equivalently mapped as a change-management item.

Slaask routing rules directed conversations to specific Slack channels or team members based on page URL, team assignment, or visitor attribute conditions. Freshdesk has no direct equivalent routing model that reads from Slaask's rule syntax. We do not migrate routing rules as executable configuration. Instead, we document each active Slaask routing rule as a written specification (trigger condition, target channel, team assignment) and deliver it as a configuration handoff document for the customer's Freshdesk admin to implement using Freshdesk's Team, Group, and Routing escalation rules.

Slaask widget appearance settings (color, position, greeting message, trigger rules, online/offline behavior) are stored in Slaask's own platform and have no Freshdesk equivalent in the contact or ticket model. We document the current widget settings during the discovery call, including greeting text, trigger conditions, and routing preferences, and deliver them as a configuration specification so the customer's Freshdesk team can configure equivalent behavior using Freshdesk's chat widget settings, portal customization, and canned responses.

Slaask conversations that were posted to Slack channels are recoverable via standard Slack export on Business+ plans or higher. We extract messages from the corresponding Slack channel, match them to their parent Slaask Conversation by timestamp and participant, and land them as Freshdesk conversation events. The Slack channel name and original message timestamp are preserved as metadata on each imported event. This recovery path is the primary mechanism for recovering chat history that Slaask did not export natively.

Slaask integrations with third-party tools beyond Slack (for example, analytics tools or CRM connectors that Slaask supported during its active period) are not recoverable in migration because Slaask did not expose an integration log or configuration export. We flag any identified connected tools during discovery and produce a written integration requirements document for the customer to reconfigure manually in Freshdesk or via Freshdesk's available integrations directory.