Migrate from InvGate Service Management to Salesforce Service Cloud

InvGate Requests map to Salesforce Case as the primary service record. The Case.Subject field receives the Request title, Case.Description receives the Request description, Case.Priority maps from InvGate priority, and Case.Status maps from InvGate status. Category from InvGate becomes a custom picklist field or Case Type value depending on the customer's categorization strategy. The InvGate Requester (submitter) resolves to a Salesforce Contact lookup via email match. We set Case.Origin to match the InvGate channel field (email, portal, API) and preserve the Request ID as a custom Case field invgate_request_id__c for audit traceability.

InvGate Incidents share the same underlying record as Requests but are tagged with incident type. We map Incident records to Salesforce Case with a custom field incident_type__c set to 'Incident' to preserve the ITIL record class. Impact and urgency levels migrate to custom Case fields impact_level__c and urgency_level__c. Related Problem linkages from InvGate migrate as Case-to-Case lookups or as entries in a custom related_incidents__c field on the linked Problem Case.

InvGate Problems are PinkVERIFY-certified records with root-cause analysis and workaround descriptions. We map Problems to Salesforce Case with a custom field record_type__c set to 'Problem' and store the root cause, workaround, and known-error rationale in custom long-text fields on the Case. Problem-to-Incident linkages migrate as Salesforce Case-to-Case relationships (using a custom lookup field linked_cases__c pointing to the related Incident Cases). The Problem closure notes and RCA body migrate as a custom rich-text field on the Problem Case.

InvGate Change records include type (normal, standard, emergency), risk assessment, approval chain, and scheduled dates. We map these to Salesforce Case with a custom field change_type__c, a risk_assessment__c picklist, and scheduled date fields (requested_start__c, requested_end__c). Approval chain status migrates to a custom change_approval_status__c field. Standard Changes map with pre-approved status; emergency Changes flag the case priority as high. We document all Change workflows as a written handoff for the customer's admin to rebuild in Salesforce Flow.

InvGate Agent accounts (display name, email, role, groups, help desk assignments) map to Salesforce User records. We match by email as the dedupe key. Agent role (Agent, Admin, Manager) maps to Salesforce Profile and Permission Set assignments. Help desk group memberships map to Salesforce Public Groups or Queues. Agents without a matching Salesforce User are held in a reconciliation queue for the customer's admin to provision. LDAP and AD-synced agents require the customer to configure Salesforce identity federation (SAML or OAuth) before we can resolve their User records.

InvGate Help Desks are the top-level organizational unit, often structured by location or department. We map each Help Desk to a Salesforce Queue (for case routing) and a Public Group (for reporting access). Multi-site help desk hierarchy migrates as nested Queues or as a custom help_desk__c picklist field on Case. Business-hours calendar definitions from InvGate help desks migrate as Salesforce Business Hours records and are linked to Entitlement Processes for SLA tracking.

InvGate Company records represent organizations linked to requesters, used for external user management. We map Company to Salesforce Account with name, domain, and address fields preserved. The InvGate company-to-contact relationship becomes the Account-to-Contact relationship in Salesforce. If the customer uses Salesforce for sales alongside this migration, we coordinate to avoid duplicate Account creation during the migration window.

InvGate SLA definitions with response and resolution times tied to priority and business-hours calendars map to Salesforce Entitlement Processes and Business Hours. We export SLA configurations and calendar definitions, create Salesforce Business Hours records matching the InvGate help desk calendar structure, and configure Entitlement Processes with milestone triggers matching the original response and resolution SLAs. SLA breach notification triggers require rebuild in Salesforce Flow or an AppExchange entitlement app; we document the required triggers as part of the workflow inventory.

InvGate Service Catalog items define requestable services with form fields, associated workflows, and approval requirements. We extract catalog item content, form schemas, and approval routing rules. Form fields map to Salesforce custom objects or to a custom Case field structure. Approval routing logic cannot migrate as code; we deliver a catalog item audit documenting every approval step and recommending Salesforce Flow approval processes or a custom approval custom object. The customer or a Salesforce partner rebuilds the catalog UI.

InvGate Knowledge Base articles (title, body HTML/text, category, status) export with full content and category structure. We map articles to Salesforce Knowledge with the equivalent article type, title, and rich-text body. InvGate's article-to-ticket linkage and auto-suggestion rules are metadata-driven and not included in standard KB exports; these require manual reconfiguration in Salesforce Knowledge data category rules post-migration. We preserve the article categorization hierarchy as Salesforce Knowledge data categories.

InvGate Custom Properties extend Requests, Agents, Companies, and other objects with user-defined field types (dropdowns, dates, numbers, text). We extract the property schema and values from the InvGate API and map field types to equivalent Salesforce field types (picklists for dropdowns, date fields for date types, number fields for numeric types). Salesforce Custom Fields are pre-created in the destination org before record migration begins. Field-level security and page layout assignments are documented for the admin to configure post-migration.

InvGate time entries (hours logged, description, billable flag, associated request) migrate as entries in a custom time_entry__c child object of Case or as custom fields on Case for simple time tracking. We associate time entries with the migrated Case via the invgate_request_id__c lookup. Billable flags migrate to a billable__c boolean field. If the customer uses Salesforce Field Service or a time-tracking app, we coordinate the time entry structure with the installed app schema.