Migrate from Vision Satellite Help Desk to Salesforce Service Cloud

Vision Tickets map directly to Salesforce Cases. The Vision ticket_id becomes a custom external ID field (vision_ticket_id__c) on Case for deduplication. Ticket subject becomes Case Subject, ticket description becomes Case Description, ticket status maps to Case Status, priority maps to Case Priority, and Origin maps to Case Origin. Private staff notes export as a separate column and become Internal Case Comments (IsPublished = false). Client-visible replies become EmailMessage records linked to the Case.

Vision Clients export with name, email, phone, and organization linkage. We map Clients to Salesforce Contacts, using the Vision client_id as a custom external ID field (vision_client_id__c). The organization linkage resolves to a Salesforce Account Lookup once Account import is complete. If the destination org uses Person Accounts, we configure the mapping accordingly during scoping.

Vision Organizations map to Salesforce Accounts. The export includes org name, domain, and any custom fields. Account Name maps from the organization name field. If the customer uses Salesforce Person Accounts for B2C contacts without organizations, we configure a mapping that creates Person Accounts for orgless clients and Business Accounts for org-linked clients.

Vision Staff Agent records (name, email, role, department) map to Salesforce User records. We resolve by email match against the destination Salesforce org. Vision roles (Agent, Supervisor, Admin) map to Salesforce Profiles and Permission Sets during scoping. Any Vision agent without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import. Agents on Vision Starter tier (no calendar or approval access) are valid User records and migrate normally.

Vision custom fields on tickets export as additional columns in the CSV. We flag each custom field during scoping, determine whether it is active (carries data) or orphaned, and create matching Salesforce custom fields on the Case object before migration. Field types map from Vision (text, number, date, dropdown) to equivalent Salesforce field types. Read-only or formula fields in Salesforce are created as custom fields without data migration since they compute at runtime.

Vision Tickets carry Labels, Tags, and Flags as separate multi-select columns in the export. We migrate these to Salesforce multi-select picklist fields on Case (e.g., case_origin_tag__c, case_category__c) for direct filtering. Alternatively, if the customer uses Salesforce Topics for taxonomy, we create Topic records and TopicAssignment links per ticket. Vision Flags (a Vision-specific boolean-style flag) map to a Salesforce checkbox field. The customer selects the preferred taxonomy strategy during scoping.

Vision KB articles and folders export via the reporting module with HTML content. We migrate articles as Salesforce Knowledge articles (ArticleType = Troubleshooting_Article or a custom Article Type created in the destination org). HTML formatting is preserved or stripped depending on whether the destination org uses rich-text or plain-text article bodies. Article folder hierarchy maps to Salesforce DataCategoryGroup and DataCategory for navigational structure.

Vision ticket attachments export as file references. We extract the files from Vision's export, upload them to Salesforce as ContentVersion records, and link them to the corresponding Case via ContentDocumentLink. Attachment size limits in Salesforce (25 MB per file via API) are enforced; files exceeding this threshold are flagged for the customer's admin to host externally and link as URLs.

Vision approval workflow records (Pro tier and above) export with requester, approver, status, and timestamps. We map these to Salesforce ProcessInstance and ProcessInstanceHistory records. Approval workflows themselves (the rules, conditions, and routing logic) do not migrate as Salesforce Approval Processes; we deliver a written inventory of every active Vision approval workflow with its trigger, conditions, approvers, and a recommended Salesforce Flow or Approval Process equivalent for the customer's admin to rebuild.

Vision stores multi-agent ticket assignments as a comma-separated list in a single field. We split this list and create individual assignee records at the destination. Salesforce enforces a single Primary Contact on a Case (WhoId), but secondary assignees can be added via CaseTeamMember or a custom multi-select picklist field (case_secondary_assignees__c). We configure the chosen model during scoping based on the customer's workflow requirements. If the destination org uses Omni-Channel, routing rules may override manual assignments post-migration.