Migrate from Ivinex to Salesforce Service Cloud

Ivinex Contact records map directly to Salesforce Contact. Standard fields (name, email, phone, address) migrate cleanly. Custom fields on the Contact Tab are captured by calling GetFields for that Tab first, then mapped to Salesforce custom fields that we pre-create with matching field types. OwnerId resolves by matching Ivinex created_by or assigned_user to Salesforce User by email. If the Ivinex Contact has a LinkRecord relationship to an Organization, we resolve the AccountId on Contact at migration time.

Ivinex Organization records map to Salesforce Account. Standard fields (company name, domain, address) migrate directly. We resolve Ivinex Organization-to-Contact LinkRecords as Account-to-Contact relationships by inserting Accounts first, then resolving AccountId on each related Contact during the Contact import phase. Custom fields on the Organization Tab are discovered via GetFields and mapped to pre-created Salesforce custom fields on Account.

Ivinex Ticket records map to Salesforce Case. The Ivinex ticket status, priority, and assignee fields map to Salesforce Case Status, Priority, and OwnerId respectively. We remap Ivinex status values to Salesforce Status picklist values configured in the destination org. Ivinex's custom fields on the Ticket Tab migrate to Case custom fields. If Ivinex Tickets are linked to Contacts via relationship records, we resolve the ContactId on Case at migration time using the same lookup resolution pass.

Ivinex Task records (standalone tasks not tied to a Ticket) map to Salesforce Task. Due dates, assignees, and completion status migrate directly. Ivinex Task custom fields migrate to Salesforce Task custom fields. Owner resolution uses the same email-match strategy as Contacts. Tasks that are related to Ivinex Tickets resolve their WhatId to the migrated Case ID during the parent-record resolution pass.

Ivinex Activity records (call logs, emails, notes attached to Contacts or Organizations) migrate to Salesforce Task or Event depending on activity type. Call engagements map to Task with TaskSubtype=Call; meeting-type activities map to Event; general notes map to Salesforce Note or ContentNote. We export via Ivinex GetAllRelatedItems to capture the full activity timeline per record, then resolve WhoId (Contact or Lead) and WhatId (Case, Account) at migration time before Bulk API insert.

Ivinex User accounts (name, email, role, active/inactive) export so that OwnerId references on all migrating records can be remapped. We match Ivinex users to Salesforce Users by email. Any Ivinex user without a matching Salesforce User is placed in a reconciliation queue for the customer's admin to provision before record import. Active/inactive status maps to Salesforce User.IsActive.

Ivinex Groups control API permissions and record access and have no direct Salesforce equivalent. We export group membership and access scope as structured data. The customer's Salesforce admin rebuilds access controls using Profiles (base permissions) and Permission Sets (granular feature grants) based on the exported group structure. Ivinex field-level visibility within a Group maps to Salesforce field-level security settings on the Profile.

Ivinex attachment metadata is extracted during the data pull including download URLs. Binary file content requires a separate download pass. We upload files via Salesforce ContentVersion API and link to the parent record (Contact, Account, Case) via ContentDocumentLink. Files exceeding Salesforce's 25MB per ContentVersion limit are flagged for manual post-migration transfer. Attachment URL validity may expire; we log any failed downloads for retrieval during the post-ETL file transfer phase.

Every Ivinex Tab has a unique set of custom fields that must be discovered per-account via GetFields before data extraction begins. We capture field label, field type (text, number, date, dropdown, checkbox, user-link), and any dropdown options. Custom fields are pre-created in Salesforce on the corresponding standard object (Account, Contact, Case, Task) before migration, with type mapping from Ivinex field type to Salesforce field type. Multi-select picklists in Ivinex map to Salesforce multi-select picklists; user-link fields map to Salesforce Lookup(User) or custom fields as appropriate.

Ivinex Workflows are automation rules defined in the process automation module. They are exported as structured JSON capturing trigger conditions, actions, delays, and branching logic. Salesforce Flow is a different automation model with different action types, trigger modes, and limits, and there is no automated conversion path. We deliver a written inventory of every active Ivinex Workflow with its trigger, conditions, and actions and a recommended Salesforce Flow equivalent. The customer's admin or a Salesforce partner rebuilds them post-migration.

Ivinex Saved Views define which fields and filters are shown per Tab. These are user interface preferences rather than data. We preserve view names, field lists, and filter criteria as structured documentation. The customer's admin rebuilds Lightning Record Page filters and List Views in Salesforce using the exported view definitions as a reference.