Migrate from Kaseya Vorex Service Desk to Salesforce Service Cloud

Vorex Tickets map to Salesforce Cases as the primary work object. Standard fields migrate including ticket number (preserved as an external reference field), status, priority, type, requester, assignee, and all timestamp fields. Conversation threads from Vorex Notes and Email exchanges map to Salesforce EmailMessage records linked to the Case via the parent CaseId field. Vortex ticket source channels (email, portal, phone) map to Case Origin. Closed ticket resolution data migrates as Case Resolution fields.

Vorex Organizations represent the companies or internal departments submitting tickets. We map these to Salesforce Accounts with Organization name populating Account Name. If the Organization has a domain field, it becomes the Account Website. For multi-tenant MSP scenarios, the Vorex Organization maps to a Salesforce Account and all related Contacts and Cases reference this Account, achieving the same client-scoped isolation that Vorex provides via its Organization filter.

Vorex Contact records (requesters and submitters on tickets) map to Salesforce Contact. The Contact's Organization reference resolves to the Account Id established during the Account migration phase. Email, phone, and address fields migrate directly. We use the Contact email as the deduplication key during import to prevent duplicate Contact records.

Vorex Service Desks are top-level organizational containers potentially scoped by department or region. Salesforce does not have a direct Service Desk object. We map each Vorex Service Desk to a Salesforce Queue (using the Queue API name and label from Setup) and route imported Cases to the appropriate Queue based on the Vorex Service Desk assignment. Queue routing is configured before Case migration begins.

Vorex exposes a structured custom fields API returning CustomFieldRef, CustomFieldCaption, CustomFieldType (text, number, date, dropdown, checkbox), CustomFieldDefaultValue, and CustomFieldOrder. We map these to Salesforce custom fields on the Case object using the Vorex Caption as the field label and a sanitized version of the Vorex Ref as the API field name. Picklist and multi-select custom fields from Vorex become Salesforce picklist or multi-select picklist fields. We preserve the Vorex custom field schema in a written field map so the customer's admin can verify all fields are correctly typed before production migration.

Vorex SLA Policies define response and resolution time targets tied to ticket priority. We map these to Salesforce Entitlement Processes (with response and resolution milestones) and associate the Entitlement to the Account. The Vorex priority field maps to Case Priority, which triggers the appropriate Entitlement Process based on the SLA mapping configuration. Escalation rules do not migrate; we document each Vorex SLA escalation trigger for the customer's admin to rebuild as Salesforce Omni-Channel or Flow-based escalations.

Vorex Agents (IT staff who own and resolve tickets) map to Salesforce Users. We resolve agents by email match against the destination Salesforce org's User table. Agent role permissions (admin, technician, viewer) map to Salesforce Permission Sets and a Profile assignment. Any Vorex Agent linked to a VSA user account that does not have a corresponding Salesforce User goes into a reconciliation queue for the customer's admin to provision. We do not migrate VSA user account credentials; these are Kaseya-authentication-specific and cannot transfer to Salesforce Identity.

Vorex has a bidirectional integration with IT Glue storing linked configuration items (servers, workstations, software licenses) against tickets. These CI references are external IDs pointing into IT Glue that do not exist in Salesforce. We extract the full CI link data and the linked asset metadata, and surface it as Salesforce Asset records linked to the Account plus a custom text field on the Case (it_glue_ci_reference__c) carrying the original IT Glue CI identifier so teams can manually re-link assets post-migration. Native auto-population of asset context from IT Glue will not function in Salesforce.

Ticket attachments (documents, screenshots, logs) associated with individual Vorex tickets migrate to Salesforce ContentDocument records linked to the Case via ContentDocumentLink. Large attachments over 25 MB may require chunked handling. We extract the file name, mime type, and binary content, then upload via the Salesforce ContentVersion API before creating the ContentDocumentLink to the Case.

Vorex tracks billable and non-billable time logged against tickets for professional services automation scenarios. We migrate time entry records (duration, date, agent, description) as line items linked to the Case. In Salesforce editions without Service Resources and Time Sheet objects, we create a custom Case_Time_Entry__c object with fields for Duration, Date, Agent (User lookup), Description, and Billable (checkbox). The Case_Time_Entry__c records reference the parent Case Id. If the customer licenses Salesforce Field Service or Salesforce Scheduler, we map time entries to the native Time Sheet Entry object.

Vorex tickets frequently contain embedded VSA Live Connect references enabling agents to launch remote endpoint management sessions directly from a ticket. These are Kaseya VSA-specific session launch URLs that have no functional equivalent in Salesforce. We extract and preserve the VSA device identifiers and session URLs in a custom text field on the Case (vsa_live_connect_reference__c) as a reference record for IT teams to re-establish remote session workflows post-migration using a Salesforce-integrated RMM tool.

Vorex SLA escalation rules trigger notifications, priority escalations, or ticket reassignments when SLA deadlines approach. We do not migrate these as code. We extract the full escalation rule configuration (trigger conditions, actions, timing) and deliver it as a written document with a mapping to Salesforce Omni-Channel presence configuration, Flow-based escalation triggers, and Salesforce In-App Notifications. The customer's Salesforce admin or implementation partner rebuilds these post-migration.