Migrate from Siit to Salesforce Service Cloud

Siit Requests map to Salesforce Case as the core ticket object. title becomes Subject, description migrates as Description, status (open, pending, resolved, closed) maps to Case Status picklist values we pre-configure, priority maps to Case Priority, and submitted_from (employee_portal, slack, mail, ms_teams) becomes a custom Case field channel__c to preserve the intake source. We resolve assignee_admin_uid to a Salesforce User record via the People-to-User mapping before Case insert so that OwnerId is satisfied. SLA timestamps (first_replied_at, first_completed_at) migrate as custom Case fields since standard Salesforce Case timestamps are set by trigger logic, not direct assignment.

Siit People records store employee directory data including department, team, office location, legal entity, employment type, and lifecycle stage. For Service Cloud, the relevant People fields map to Contact: department, team, and location map to custom Contact fields; legal_entity and employment_type map to custom fields. Employees who only submit requests in Siit map to Contact without a Salesforce User license; Admins who resolve requests map to a Salesforce User with the appropriate Service Cloud Profile. We use email as the deduplication key during import.

Siit Services represent IT catalog items employees request, each with configuration metadata and category assignments. Salesforce Service Cloud does not have a native catalog object equivalent, so we create a custom object service_catalog__c with fields for Name, Category, Description, and Workflow_Reference__c (carrying the Siit workflow association). The customer can alternatively use Salesforce Knowledge articles as a self-service catalog; we scope the preferred approach during discovery based on whether the catalog needs entitlement linkage.

Siit Equipment records represent physical and virtual devices with lifecycle attributes, ownership details, and key configuration fields. Equipment maps directly to Salesforce Asset, which supports Name, Status (Planned, In Stock, In Use, In Maintenance, Retired), InstallDate, PurchaseDate, SerialNumber, and a Link to a Contact or Account as the asset owner. We resolve target_uid from the Siit Equipment record to the corresponding Contact or Account Salesforce record via the People mapping.

Siit Application inventory tracks software assets with ownership fields, lifecycle status, and category metadata. Application ownership linking to employee or equipment records maps to a custom object app_inventory__c with lookup relationships to Asset (for device linkage) and Contact (for user ownership). lifecycle_status becomes a picklist field with values matching the Siit source values, preserving the software asset taxonomy the team uses for ITAM reporting.

Siit Communication exports include outbound messages and satisfaction survey responses linked to Requests. Each thread maps to Salesforce EmailMessage records linked to the parent Case via the WhatId field. We set MessageDate to the original Siit timestamp and preserve the satisfaction survey score in a custom Case field csat_score__c. Outbound messages are inserted as EmailMessage with direction = Outgoing. If the customer used Slack or Teams threaded messages within Siit, we flatten the thread into a chronological sequence of EmailMessage records to preserve context in the Case timeline.

Siit Inboxes route requests to specific teams or queues. We map each Siit Inbox to a Salesforce Queue with the Queue Name matching the Inbox title and the Queue Type set to Cases. During Case migration, we assign cases to the appropriate Queue based on the Inbox assignment in Siit. If the customer used Inbox-level SLA configurations, those translate to Salesforce Entitlement Processes linked to the Queue via Assignment Rules.

Siit Request records include first_replied_at and first_completed_at timestamps, and SLA timers and escalation configurations export as part of workflow and request data. We rebuild these in Salesforce as Entitlement Processes with First Response Time and Next Response Time milestones, using Business Hours for working-hour calculations. The original Siit SLA status (met, breached, in_progress) migrates as a custom Case field original_sla_status__c to preserve the audit trail.

Siit Tags are associated with Requests via tag_uids arrays. We extract all unique tags during the migration scan and create a Salesforce multi-select picklist field tag__c on Case with each distinct Siit tag as a picklist value. Tags used for categorization and filtering preserve the taxonomy teams rely on for reporting. If there are more than 150 unique tags, we use a custom object tag__c with a junction object casetag__c to avoid Salesforce multi-select picklist limits.

Siit Requests support custom_form_inputs as key-value label/value pairs with no fixed schema per request type and organization. We extract all unique custom field labels during the migration scan and create Salesforce custom fields on Case (custom_<label>__c) with appropriate types: text fields for string values, number fields for numeric values, and date fields for date values. If a label contains special characters, we sanitize it to a Salesforce-valid API name. Where the destination Salesforce edition has a field limit, we serialize remaining custom inputs as a structured JSON blob in a custom long-text field custom_inputs_raw__c.

Siit Admins are the billable seat type in Siit and must be provisioned in Salesforce as User records with the appropriate Service Cloud license (Agent, Supervisor, or Lightning Experience depending on role). We use email as the matching key between Siit People records and Salesforce Users. Users without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before record import resumes, because Case.OwnerId requires a valid User or Queue reference at insert time.