Migrate from Infraon Desk to Salesforce Service Cloud

Infraon Desk Incidents map directly to Salesforce Service Cloud Case records. The Incident priority, status, category, assignee, and requester fields map to standard Case fields. We preserve the Infraon Desk incident ID as a custom external ID field case_external_id__c to prevent duplicate records on any re-import. Conversation threads (public and internal notes) migrate as EmailMessage records linked to the Case. Any custom fields on Incidents are enumerated during discovery and mapped to custom Case fields of equivalent type before migration begins.

Infraon Desk Problems track root-cause analysis linked to one or more Incidents. Salesforce Service Cloud has no native Problem object in its standard schema. We create a custom object Problem__c with fields for problem title, description, status, priority, and root_cause__c, then link it to the related Cases via a lookup relationship. The customer configures the Problem__c object during destination schema setup. Problems without linked Incidents migrate as standalone Problem__c records.

Infraon Desk Changes include type (Normal, Standard, Emergency), risk level, approvals, and scheduled dates. We create a Change_Request__c custom object in Salesforce with fields for change_type__c, risk_level__c, scheduled_start__c, scheduled_end__c, approval_status__c, and cab_association__c. Standard Change workflows in Infraon Desk are documented for rebuild in Salesforce Flow; they do not migrate as automation code.

Infraon Desk CIs live in the CMDB and link to Incidents, Problems, and Changes. Custom CI types beyond the standard defaults require enumeration during discovery. We map hardware-related CIs to Salesforce Asset and software or licence-related CIs to Product2. CI relationships are preserved as lookup fields on the Asset or Product2 record. The custom CI type definitions are read from Infraon Desk field metadata during scoping and translated into the destination schema.

Infraon Desk Assets (hardware and software inventory) map to Salesforce Asset. Custom fields on Assets are enumerated during discovery, mapped to custom Asset fields in Salesforce, and included in the migration manifest. Bulk asset imports are chunked into batches to stay within Salesforce API limits. Assets linked to CIs carry the CI lookup reference to maintain the Infraon Desk relationship hierarchy in the destination.

Infraon Desk KB Articles with full HTML content migrate to Salesforce Knowledge Article records. Article-to-category hierarchies map to Salesforce data categories configured during destination schema setup. Article visibility rules are translated into Knowledge Article visibility settings per article type. Attachment references are preserved as ContentDocument records linked to the article. We flag any orphaned attachment URLs during extraction so the customer can address them before import.

Infraon Desk Service Catalogue items define requestable services and their associated workflow triggers. We export the item definition, associated form structure, and linked workflow trigger conditions as a written catalogue specification document. The workflow trigger logic requires rebuild in Salesforce Flow by the customer's admin; we document the trigger conditions, form field mappings, and escalation actions in the inventory deliverable. The catalogue item form fields are translated into a custom Service_Request__c object if the customer wants to replicate the intake mechanism.

Infraon Desk SLA policies define response and resolution time targets per priority level and are linked to catalogue items. We recreate SLA definitions in Salesforce as Entitlements and EntitlementProcesses tied to the Case object. The SLA elapsed time and breach state from Infraon Desk tickets are preserved in custom fields ssa_original_response_due__c and ssa_original_resolution_due__c so the customer can decide whether to honour original breach deadlines or renegotiate SLA targets post-migration.

Infraon Desk Technicians (billable seats) map to Salesforce Users. End-users (requesters) map to Salesforce Contacts or, if the destination org uses Experience Cloud, to Contact records linked to the relevant Account. We resolve Technicians by email match against the Salesforce destination org's User table. Any Technician without a matching User is placed in a reconciliation queue for the customer's admin to provision before record import begins. Infraon Desk end-users who are not paid technicians are migrated as free Contacts.

Infraon Desk Releases track deployment packages linked to Changes. If the destination org uses a custom Release management approach, we create a Release__c custom object; otherwise, Releases migrate as Case records with a release_category__c picklist value. Release-to-Change links are preserved as lookup relationships. Release records with planned rollout schedules carry their dates as custom fields in the destination.

Standalone Tasks in Infraon Desk migrate to Salesforce Task records with Status, Priority, Subject, ActivityDate, and OwnerId preserved. Tasks linked inside Infraon Desk Project Management carry a reference to the parent project identifier for the customer to re-associate post-migration if Project Management scope is included.

Tags applied to Tickets, Assets, and KB Articles in Infraon Desk migrate to Salesforce Topics with TopicAssignment records, or to multi-select picklist fields on the respective object if the customer prefers tag storage within the record. The customer chooses the tag strategy during scoping. Tag co-occurrence patterns are preserved as a written reference for the customer's admin to use when rebuilding reporting filters.