Migrate from iService to Salesforce Service Cloud

iService Tickets map to Salesforce Case. We preserve Ticket status (Open, Pending, Resolved, Closed), Priority (Low, Medium, High, Urgent), and the ticket ID as a custom field original_ticket_id__c for cross-reference. Custom ticket fields from iService map to custom Case fields pre-created in Salesforce with matching data types (picklist, text, date, number). The Case origin maps from iService's channel field (Email, Chat, Portal, Web Form).

iService Customer records map to Salesforce Contact. Each Customer has name, email, phone, and custom properties that map to Contact fields. Email serves as the dedupe key. We resolve the Contact's AccountId by matching the iService Customer's associated Company to the Account lookup before Contact insert, so no Contact is orphaned during migration.

iService Company records map to Salesforce Account. Company name becomes Account Name, domain or website becomes Account Site or Website. We use Company as the parent of Contact so that AccountId is satisfied at Contact insert time. Company-level custom properties map to custom Account fields with equivalent data types.

iService Conversation threads map to Salesforce EmailMessage records attached to the Case. Each message (inbound or outbound) becomes a separate EmailMessage record with FromName, FromAddress, ToAddress, Subject, Body, and Incoming flag preserved. The EmailMessage is linked to the Case via ParentId. Thread ordering is preserved by setting EmailMessage.ActivityDate to the original message timestamp. If the iService conversation contains internal notes (agent-only visibility), those map to Task records with IsVisibleInSelfService=false.

iService chat transcripts are conversation records tied to a Customer. We flag chat sources during the data audit because transcript structure depends on whether the chat originated via the embedded portal widget or a third-party integrated channel. Chat sessions map to Salesforce Live Agent Transcript records linked to the Case, or to Case with a custom chat_transcript__c long-text field if Live Agent is not enabled in the destination org. The customer chooses the target structure during scoping.

iService KB Articles export as HTML or markdown and map to Salesforce Knowledge ArticleVersion records. We preserve article title, body content, and URL name. iService KB categories map to Salesforce Data Category Groups and categories, maintaining the hierarchical structure where possible. Attachments within articles migrate as ContentDocument records linked to the Article via ContentDocumentLink.

iService custom ticket fields vary by tenant configuration and may include picklists, text fields, date fields, and numeric fields. We audit every custom field during scoping, record its data type and current values, and pre-create equivalent custom fields on the Salesforce Case object with matching types. If a picklist has values not yet present in Salesforce, we add them to the picklist definition before migration. Picklist values that do not map cleanly to Salesforce options go to a reconciliation note for the customer's admin.

File attachments on iService Tickets and KB Articles migrate as Salesforce ContentVersion binary blobs. We preserve the original filename and content type, and link each ContentVersion to the parent Case or KnowledgeArticle via ContentDocumentLink. Attachments exceeding Salesforce's 25 MB per file limit are flagged for splitting or alternative delivery during scoping.

iService Tags used to label Tickets and KB Articles migrate to Salesforce Topics (for article classification) or to a custom multi-select picklist field on Case (for ticket labeling). The customer selects the target strategy during scoping. Tag naming conventions between source and destination may differ; we map tag names explicitly rather than relying on alphabetical alignment.

iService Agent accounts include email, name, role, and team assignment. We map agents to Salesforce User records by email match. Role structures differ between iService and Salesforce, so we default to a standard Agent profile in Salesforce and flag any role mapping requiring admin decisions during scoping. Agents without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before record import resumes.

iService Workflows define ticket routing, status triggers, and notification rules. These automations are tightly coupled to iService's internal engine and cannot be exported in portable form. We document every active iService Workflow during scoping (trigger conditions, actions, recipients) in a written handoff document for the customer's Salesforce admin to rebuild using Salesforce Flow, Omni-Channel routing rules, or Assignment Rules post-migration.