Migrate from Issuetrak to Salesforce Service Cloud

Issuetrak Issues map directly to Salesforce Cases. Subject maps to Subject, Description to Description, Priority maps to Priority, and Assigned To maps to OwnerId resolved via User lookup by email. We create a combined Status_Substatus field (e.g., 'Open - Pending Customer') from Issuetrak's two-level status hierarchy, and optionally map the primary Status to Case Status with Substatus preserved in a custom Substatus__c picklist field if the customer requests Salesforce-native status splitting.

Issue Classes provide categorical structure for ticket filtering in Issuetrak. We map them to Salesforce Case Record Types (one per major Issuetrak Class) with corresponding Page Layouts so that agents see only the fields relevant to each category. Subtype maps to a custom Subcategory__c picklist.

Issuetrak's two-level status hierarchy (Status plus Substatus, e.g., Open and Pending) maps to a combined display value and a split Salesforce model: Case.Status carries the top-level status and a custom Substatus__c picklist carries the substatus. We build the Substatus__c picklist with all active substatus values from Issuetrak during schema setup.

Issuetrak UDFs of type text, large text, number, date, and single-select list map directly to Salesforce Custom Fields on Case. Field type mapping is determined during UDF schema discovery: Issuetrak list UDFs become Salesforce picklists, numbers become Number fields, dates become Date fields. We query the Issuetrak UDF metadata endpoint and values endpoint separately and join them in the migration workspace before field creation.

Issuetrak multi-list UDFs store values as comma-delimited strings (e.g., 'Hardware, Network, Urgent') which we parse and normalize. For fewer than 50 distinct values we create a Salesforce multi-select picklist. For larger sets or when the multi-list represents a many-to-many relationship (e.g., a ticket tagged with multiple products), we create a junction object with lookups to Case and a Product or Category object.

Task Groups in Issuetrak are collections of predefined tasks associated with specific UDF selections. We export each Task Group as a set of Salesforce Task records related to the parent Case. The Task-Associated UDF trigger that originally appended the Task Group does not transfer; we document the trigger logic in the automation handoff for the customer's Salesforce admin to rebuild in Flow.

Issuetrak Solutions are text templates used to respond to or close issues. We export them with their full content and category assignments and map them to Salesforce Knowledge articles using the destination org's configured article types. Category assignment maps to Knowledge Article Data Category Groups. If the destination org does not have Knowledge enabled, Solutions migrate as Case email templates.

Issuetrak Knowledge Base articles with embedded images and rich text migrate to Salesforce Knowledge with full HTML content preserved. Article categories map to Salesforce Knowledge Data Category Groups, and attachments migrate as ContentDocument records linked via ContentDocumentLink. We preserve the article publish date, author, and view count where available from Issuetrak's export.

Issuetrak Global Issues link multiple related Issues for collective management. We export the linkage table and parent-child relationships and reconstruct the grouping in Salesforce using either a custom GlobalIssueLink__c lookup field on Case (for a flat grouping) or a custom Global_Issue__c object with a lookup from each member Case (for hierarchical grouping). The customer chooses the model during scoping.

Attachments on Issuetrak Issues and Knowledge Base articles are exported as binary files and imported into Salesforce as ContentVersion records, then linked to the parent Case or Knowledge Article via ContentDocumentLink. We preserve original filenames, file types, and upload timestamps. Large binary attachments (over 25 MB) require chunked upload handling.

Issuetrak survey responses exported via the reporting CSV interface migrate to Salesforce as Case records (one per response) with custom fields for each survey question. Any active filter applied to the report is bypassed during export to ensure no response rows are silently dropped; we request unfiltered exports during scoping. Survey metadata (survey name, date sent, response rate) migrates as custom fields on each Case.