Migrate from Sqanit to Salesforce Service Cloud

Sqanit Devices (Digital Twins) map to Salesforce Asset. Each Device carries metadata (model, serial number, installation date, owner reference) that maps to the corresponding Asset fields. The Device's status property maps to Asset Status (Shipped, Installed, In Maintenance, Retired). Custom fields added per Sqanit customer configuration are created as custom fields on the Asset object before import. Asset Name is populated from the Device display name or serial number for deduplication. Sqanit Device ID is preserved in a custom field sqanit_device_id__c for audit traceability.

Sqanit Organization records (the manufacturer or enterprise account) map directly to Salesforce Account. The Organization name becomes the Account Name; address, industry, and contact references map to standard Account fields. Sqanit Organization ID is preserved in a custom field sqanit_org_id__c. This mapping is straightforward because both platforms use a flat organizational hierarchy at this level. If the Sqanit Organization has a hierarchical structure (parent-subsidiary), we map it to the Salesforce Account.ParentId field.

Sqanit Service Tickets are the core transactional object and map to Salesforce Case. Sqanit ticket status (Open, In Progress, Resolved, Closed) maps to Salesforce Case Status with the value mapping defined during scoping. Priority maps to Case Priority. The linked Device reference becomes the AssetId lookup on Case. The linked Organization (manufacturer) reference becomes the AccountId lookup. The End User who reported the issue becomes the ContactId lookup. We preserve the original Sqanit ticket number in a custom field sqanit_ticket_id__c for reconciliation. SLA timers and response deadlines from Sqanit require manual configuration of Salesforce Entitlements and Milestones post-migration.

Sqanit End Users (consumers who scan a QR code on a physical product) map to Salesforce Contact. End Users may have minimal profile data: name, email, language preference, and linked Device ownership. Language preference from Sqanit maps to Contact.Languages__c or a custom field. Email maps to Contact.Email. If the End User has no email but has a phone number, we use Phone as an alternative contact method and note in the migration report that Salesforce's case email notifications will not reach these contacts without manual email entry. Sqanit End User ID is preserved in sqanit_end_user_id__c.

Sqanit Technicians (internal service staff assigned to tickets) map to Salesforce User records. We match by email address between Sqanit Technician records and the destination Salesforce org's User table. Role and team assignment from Sqanit map to Salesforce UserRole and a Queue membership respectively. Technicians without a matching User in the destination org enter a reconciliation queue for the customer's admin to provision before the migration phase resumes. If Sqanit distinguishes between internal technicians and external partners, we map external technicians to Salesforce Contact records with a custom technician_type__c flag set to External.

Sqanit Compliance Records (inspections, certifications, regulatory records attached to a Device) require schema design during scoping because the structure varies per industry. For medical device manufacturers, Compliance Records map to a custom Compliance_Event__c object with lookups to Asset, Contact (inspector), and Case. For EU Digital Product Passport compliance, we map to the Asset object with custom fields for certificate_type__c, issue_date__c, expiry_date__c, and regulatory_body__c. The appropriate schema pattern is agreed with the customer during discovery based on their active Sqanit modules and regulatory context.

Sqanit scan events, AI-assisted resolutions, and ticket updates create interaction records that map to Salesforce Task and Event. QR-code scans without a resulting ticket become Task records with a custom task_type__c of Scan_Interaction. AI-assisted resolutions that closed without a technician ticket map to Task with status Completed and a custom resolution_method__c of AI_Assisted. Technician interactions on tickets map to Event records linked to the Case via WhatId and the Contact via WhoId. ActivityDate is preserved from the original Sqanit timestamp to maintain chronological ordering in the Salesforce timeline.

Sqanit knowledge base articles (524+ language support) map to Salesforce Knowledge with the article body and locale preserved. Each Sqanit article-language pair (e.g., an article existing in German and French) becomes a separate Salesforce Knowledge Article version. Sqanit guided workflow text (step-by-step resolution instructions) migrates as Salesforce Knowledge Article body content rather than as a separate object, since Salesforce Knowledge does not have a native guided workflow artifact type. URL names and article IDs are preserved in custom fields sqanit_article_id__c and sqanit_url_name__c for reconciliation.

Sqanit's AI-assisted triage routes incoming scans to self-help, guided resolution, or a specific technician queue based on issue type and device context. This routing logic does not have a direct Salesforce equivalent because Salesforce uses Omni-Channel routing based on Skills-Based Routing, Case Assignment Rules, and Flow-based routing rather than AI issue classification. We document the Sqanit routing rules during discovery and deliver a written recommendation for implementing equivalent routing in Salesforce Omni-Channel and Flow. The customer's admin rebuilds this configuration post-migration.

Sqanit guided workflows (step-by-step resolution paths presented to the end user via the QR-scan web interface) map to a written inventory only. Salesforce Flow does not have a native equivalent to Sqanit's consumer-facing guided resolution paths. We document each active Sqanit guided workflow with its trigger condition (device type, issue category, language), step sequence, decision branches, and resolution outcomes, then recommend Salesforce Flow alternatives (Screen Flow published to Experience Cloud, or a custom Lightning web component) for the customer's development team to implement post-migration. This is not a data migration item; it is a configuration rebuild item delivered as documentation.

Sqanit Devices are linked to an Organization (the manufacturer or deployer) that maps to the Salesforce AccountId lookup on Asset. We resolve this relationship during the Asset migration phase by matching the Sqanit Device.organization_id to the Account.sqanit_org_id__c field. If a Device in Sqanit is linked to multiple Organizations (e.g., a device sold through a distributor and installed by a service partner), we create additional Asset records or use a custom junction object asset_organization__c to preserve the full relationship chain.

Sqanit's QR-code configuration (code structure, scan destination, and fallback behavior) has no Salesforce Service Cloud equivalent. We document the QR-code setup as part of the migration inventory: what QR-code prefix or pattern is used, which Sqanit module each code routes to, and what default language or device context is applied. The customer's technical team replaces Sqanit QR-code routing with Salesforce Experience Cloud URL routing or a custom mobile application post-migration. This is not a data migration item.