Migrate from Alloy Navigator to Salesforce Service Cloud

Alloy Navigator Tickets map directly to Salesforce Service Cloud Cases. The ticket priority and status values migrate to Case Priority and Case Status, with a custom field an_original_status__c preserving the exact Alloy Navigator status value for audit. SLA timers from Alloy Navigator's ticket lifecycle map to Salesforce Entitlements and Business Hours, with Milestone records created for each SLA breach event in the ticket history. Linked Incidents, Problems, and Changes from Alloy Navigator are stored as custom Case fields or related custom objects because Salesforce Case does not have native Incident/Problem sub-record types.

Alloy Navigator Assets (hardware devices, software licenses, consumables) map to Salesforce Asset. The asset serial number, purchase date, install date, status, and assigned Contact migrate directly. Assets linked to Configuration Items in Alloy Navigator maintain their relationship via a custom field linking to the CI custom object in Salesforce. Lifecycle status transitions (procurement to retirement) map to Salesforce Asset Status values.

Configuration Items from Alloy Navigator map to a Salesforce custom object Configuration_Item__c with fields matching the Alloy Navigator CI schema (CI type, manufacturer, model, serial number, location, owner). CI-to-CI relationships (dependencies, impacts, connections) migrate as junction records on a custom CI_Relationship__c junction object with relationship type and direction fields. Custom CI types introduced via Alloy Navigator classification are detected during discovery and pre-created as Salesforce Record Types on the custom object.

KB articles from Alloy Navigator (rich text body, attachments, category assignments) migrate to Salesforce Lightning Knowledge Article records. We export article body, metadata, summary, and attachments. Alloy Navigator's category hierarchy may not map 1:1 to Salesforce Data Category Groups, so we flag mismatches during discovery and propose either flattening category paths into article summary fields or creating new Salesforce Data Categories to match the destination structure. Article publish status migrates to Knowledge Article Status (Draft, Archived, Published).

Alloy Navigator Organizations (customer or partner entities) map to Salesforce Account. Organization details including name, type, industry, annual revenue, and phone migrate directly. Hierarchical Organization relationships in Alloy Navigator may map to Salesforce Account Hierarchy if the destination org has that feature enabled, or we store the top-level parent as a custom field for reporting purposes.

Alloy Navigator Contacts (people linked to Organizations, Tickets, and Assets) map to Salesforce Contact. Email address, phone, title, and organizational associations migrate directly. Duplicate contact handling requires a pre-migration dedup strategy using email as the primary dedupe key. Active versus inactive status is preserved via a custom field an_active__c because Salesforce does not have a native soft-delete or inactive flag equivalent on Contact.

Alloy Navigator User records (technicians with login credentials, team assignments, workload balancing groups, and role-based permissions) map to Salesforce User. We resolve by email match against the destination Salesforce org's User table. Owners without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before record import resumes. Role mappings from Alloy Navigator become Salesforce Profile and Permission Set assignments, which the admin configures post-migration.

Alloy Navigator Locations form a deep hierarchical tree with parent-child relationships. Salesforce's Location object supports a flat structure, and many implementations use address fields on Account rather than a dedicated Location object. We flag tree depth during scoping and propose either flattening (root-path as a formatted string field, e.g., HQ > Building A > Floor 3 > Room 301) or parent-reference preservation via a custom parent_location__c lookup field. Locations exceeding Salesforce's schema depth limits require explicit flattening strategy before migration begins.

Alloy Navigator Work Orders (scheduled tasks, assignments, and completion tracking) map to Salesforce Task by default, with the subject, due date, status, assigned technician, and description preserved. If the Alloy Navigator Work Order schema includes custom fields not present on standard Task, we recommend a custom Work_Order__c object with a Task lookup rather than overloading Task fields. Custom work-order-specific fields are detected during discovery and pre-created in the destination schema.

Contracts linked to Assets and Contacts (renewal dates, terms, costs) map to Salesforce Contract with contract metadata and linked asset references preserved. Multi-document contracts with binary file attachments require file-level migration of the contract documents as Salesforce ContentDocument records linked to the Contract via ContentDocumentLink. Contract terms and line items that do not map to standard Salesforce Contract fields migrate to a custom contract line item object.

Alloy Navigator Software Licenses (compliance metrics, seat counts, purchase records attached to Assets) map to Salesforce Asset with a supplemental custom License__c object capturing license-specific fields (entitlement type, seat count, used seats, expiry, vendor). License entitlement calculations are source-system-specific and are exported as raw values for the customer's admin to validate against the license vendor's current entitlements post-migration.

Alloy Navigator Workflows (approval chains, escalations, Create Actions) are exported as a written inventory documenting the workflow trigger, conditions, actions, and conditional branching logic. Salesforce Flow and Alloy Navigator Workflows are architecturally different, so we do not migrate workflows as code. The customer receives a per-workflow recommendation for the equivalent Salesforce Flow type (record-triggered, scheduled, or screen flow) and the admin or a Salesforce partner rebuilds them post-migration.