Migrate from Trouble Ticket Express to Salesforce Service Cloud

TTX Tickets map to Salesforce Cases. The TTX ticket status (new, open, solved) maps to Salesforce Case Status with TTX 'solved' becoming 'Closed' in Salesforce. Priority and Owner migrate as custom fields or Case Priority and Case Owner respectively. We resolve the Owner-to-User mapping by email match before Case insert to satisfy the OwnerId lookup requirement.

TTX Messages are the chronological thread on a Ticket between customer and operator. Each Message maps to a Salesforce EmailMessage record linked to the parent Case via the ParentId field. The author type (Customer vs Operator) is preserved using IsIncoming boolean on EmailMessage. Plain-text body content migrates as EmailMessage.TextBody with HTML bodies preserved in HtmlBody if the original message contained markup.

TTX Customers are email-addressed submitters captured on ticket submission forms. We extract the TTX user database alongside tickets and map it to Salesforce Contact. The Contact's Email field is used as the dedupe key during import. We also create a Contact for each TTX Customer that does not yet exist in the destination org so that Case.ContactId can be set at migration time.

TTX Operators are service desk staff with ticket ownership and assignment capabilities. We extract operator records and map them to Salesforce User by email match. Department assignments from TTX map to Salesforce User.Department. Owners without a matching Salesforce User are held in a reconciliation queue for the customer's admin to provision before record import resumes.

TTX Departments map to Salesforce Queues for case routing. Each Queue is created with the TTX department name, and Cases inherit the queue via Case.OwnerId at migration time. If the customer's Service Cloud org already uses Queues for a different routing model, we coordinate with the admin during scoping to determine whether TTX departments become new Queues or map to an existing Salesforce Group structure.

TTX custom fields declared with the x- prefix require a two-pass extraction. If Layout Designer is installed, they exist as structured database columns and migrate as typed Salesforce custom fields (Text, Number, Checkbox, or Picklist based on content analysis). If Layout Designer is not installed, they appear only in message bodies as unstructured text, and we use regex extraction to parse x-fieldname: value patterns from the message body and populate the corresponding Salesforce custom field. The customer's admin approves the field type mapping during scoping.

File attachments in TTX are stored on the filesystem and referenced in the backup archive. We extract each file from the archive, upload it as a Salesforce ContentVersion record, and link it to the parent Case via ContentDocumentLink. File type, original filename, and file size are preserved as ContentVersion metadata. We batch large attachment sets using chunked upload to respect Salesforce storage limits and API batch sizes.

The TTX Answer Library (a paid add-on) contains pre-written responses. We extract each entry and map it to a Salesforce Knowledge Article. The TTX question becomes the Article Title, and the TTX answer becomes the Article Body (rich text). Article UrlName is generated from the TTX entry title. Article visibility (internal vs customer-facing) is set based on the TTX access level flag. We note that Salesforce Knowledge requires the Knowledge Base feature to be enabled in the destination org, which is available from Professional tier.

The TTX backup exports configuration variables including workflow rules, email settings, field labels, and status names. We parse these and deliver a written configuration inventory to the customer's Salesforce admin. Status name mappings from TTX to Salesforce Case Status are documented in the inventory so the admin can configure the Case Status picklist values to match TTX's naming convention. We do not import configuration as code; it requires manual rebuild in Salesforce Setup.

The TTX Inventory Database add-on tracks inventory items associated with tickets. If present, we extract it as a supplementary Salesforce custom object. We create the custom object schema in the destination org during scoping, including any lookup relationships to Case or Contact, and load the inventory records after standard case migration completes.