Migrate from Ticksy to Salesforce Service Cloud

Ticksy Tickets map to Salesforce Case records. Each Ticksy ticket's status (open, closed), priority (low, medium, high), assignee, and created/updated timestamps transfer directly to Case.Status, Case.Priority, Case.OwnerId, and Case.CreatedDate. The Ticksy subject line maps to Case.Subject; the ticket body and thread (all replies) concatenate into Case.Description. We handle the parent Contact or Account resolution by matching the ticket submitter's email address against the Salesforce Contact table, creating a Contact if no match exists.

Ticksy distinguishes Public (community-visible) from Private (agent-customer only) Tickets. Salesforce has no native community-visibility field on Case. We preserve this flag as a custom checkbox field on Case called Is_Community_Visible__c. Public Tickets set this to true; Private Tickets set it to false. During Salesforce Community portal setup, Case visibility rules can reference this field so that community members see only threads that were public in Ticksy.

Each Ticksy ticket reply (agent and customer messages) migrates as a Salesforce CaseComment record attached to the parent Case. The comment body, author name, author email, and timestamp transfer directly. We preserve thread ordering by setting CaseComment.CreatedDate to the original Ticksy timestamp. If the comment author has a matching Salesforce Contact, we link CaseComment.CreatedById to the corresponding User record.

Ticksy KB articles (title, body, category, and publish state) map to Salesforce Knowledge ArticleVersion records. The article body migrates as the Salesforce Article body; categories map to Salesforce Data Category Group selections. Publish state from Ticksy maps to Salesforce Article's validation status. We flag articles exceeding 32,000 characters for Salesforce's rich text field split into multiple article versions.

Ticksy KB category strings normalize to Salesforce Knowledge data category group selections. We extract the full Ticksy category hierarchy, map each node to a Salesforce Data Category, and attach data category selections to each migrated KnowledgeArticleVersion. Customers with flat Ticksy categories receive a flat Salesforce category structure unless a hierarchical mapping is specified during scoping.

Ticksy Custom Fields (text, multiline, dropdown) are extracted from their separate schema definition, then created as Salesforce Custom Fields on the Case object using the same API name with a __c suffix. Dropdown options in Ticksy become Salesforce Picklist values on the corresponding custom field. Field-level security is set to read/edit for the System Administrator profile during migration and handed off to the customer's admin for org-wide configuration.

Ticket attachments are extracted as binary assets from Ticksy and re-loaded into Salesforce as ContentVersion records linked to the parent Case via ContentDocumentLink. We preserve the original filename and MIME type. Attachments exceeding 25 MB are flagged for Salesforce file size handling. Any unusual file types (executable, compressed archives) are flagged for the customer's admin to review for security policy compliance.

Ticksy agent accounts (name, email, role) map to Salesforce User records. We resolve agents by email match against the destination Salesforce org's User table. Admin-role agents from Ticksy receive a custom role attribute in Salesforce; agents without a matching User go to a reconciliation queue for the customer's admin to provision before the ticket migration runs.

Ticksy ticket labels and tags migrate to a Salesforce custom multi-select picklist field on Case called Tags__c. Tags exceeding Salesforce's 40-character picklist value limit are truncated with a note in the migration reconciliation report. If the customer prefers a taxonomy model, tags migrate to Salesforce Topics with TopicAssignment records linked to each Case.

Ticksy's email piping routing rules and inbound email addresses are configuration data, not ticket records. We extract and document the routing rules as a written migration artifact noting the inbound email addresses, any domain-based routing logic, and the default assignee or queue for unassigned inbound messages. We do not configure Salesforce Email-to-Case during migration; the customer's admin uses our documentation to configure Email-to-Case routing rules in Salesforce Setup post-migration.