Migrate from Helpshift to Salesforce Service Cloud

Helpshift Issues map directly to Salesforce Cases. The Issue Title maps to Case Subject, Issue Status maps to Case Status (with a custom Status mapping table if Helpshift statuses differ from Salesforce defaults), Priority maps to Case Priority, and created_at/updated_at timestamps map to Case.CreatedDate and Case.LastModifiedDate. The Issue's App association maps to a Case Record Type that we configure during schema setup to support multi-app routing. Assignee Agent identity resolves to Salesforce User via email match and becomes the Case OwnerId.

Custom Issue Fields (CIFs) defined per-app in Helpshift Settings > Workflows map to custom fields on the Case object in Salesforce. We validate dropdown-type CIFs against Helpshift's 1,000-option limit during the mapping phase. If any CIF exceeds that limit, we split it into multiple Salesforce fields or switch to a text-type field before import. The CIF schema is exported from Helpshift via the REST API and recreated in Salesforce with matching API names before Case migration begins.

Helpshift End-users (the consumers submitting Issues) map to Salesforce Contacts. We use the End-user email as the Contact Email field and deduplicate against existing Contacts by email during import. Note that Helpshift tracks user-level metadata (device platform, app version, language) as Issue-attached context rather than a standalone user object. We preserve this as custom fields on the Contact (hs_device_platform__c, hs_app_version__c, hs_user_language__c) at migration time. Any End-user appearing as anonymous due to a legacy SDK below 6.x cannot have identity restored; we flag these records in the audit report.

Helpshift Agents (assigned to Issues and managing the inbox) map to Salesforce Users. We match Agents to Users by email address. Any Agent without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before Case import resumes. Agent role (Admin, Supervisor, Agent) maps to a Salesforce Permission Set assignment rather than a native role field, since Salesforce separates role hierarchy from user profiles.

Helpshift Tags attach to Issues as a flat label list. Tags migrate to a Salesforce custom multi-select picklist field on Case (Issue_Tags__c) with values preserved as-is. Alternatively, if the customer uses Salesforce Topics for classification, we create Topic records and TopicAssignment links per Case. The customer chooses the tag strategy during scoping. Tags used for routing or SLA assignment in Helpshift map to a Salesforce custom picklist that may require manual reconfiguration in Flow.

Helpshift conversation messages (the thread inside an Issue) export via the REST API as nested message objects per Issue. We flatten these into Salesforce EmailMessage records linked to the parent Case via WhatId. Each message carries the sender type (End-user vs Agent), timestamp, and message body. The Helpshift-native Salesforce integration supports one-direction field sync from Issue to Case, but the full conversation thread requires the API fetch. We annotate message-level timestamps and participant IDs to preserve auditability in Salesforce.

Helpshift Apps define which SDK configurations apply to an issue stream, and multiple apps can feed a single inbox. We export the app list from Helpshift Settings and map each app to a Salesforce Case Record Type that gets its own Page Layout and Assignment Rule. If multiple Helpshift apps feed one inbox, we consolidate them into one Record Type with a custom App_Name__c field to preserve the source app reference. Apps that require separate routing become separate Record Types with corresponding Omni-Channel routing configurations.

Helpshift FAQs and FAQ Sections export via REST API as structured knowledge-base articles with section hierarchy and publication state. If the destination Salesforce org has Service Cloud Knowledge enabled (Enterprise tier and above), we migrate FAQ body text, section hierarchy, and publication status to Knowledge Article records and Article Types. If Knowledge is not enabled, we deliver FAQ content as a structured CSV inventory for manual Knowledge Article creation or a separate CMS migration.

Helpshift Smart Views are saved filter sets that organize Issues into queues. Queues define routing and priority for agent assignment. Both are workspace configuration rather than record-level data and cannot be exported via API. We document the full Smart View and Queue configuration during discovery — filter criteria, sort order, visible columns — and deliver a written specification for recreating them as Salesforce List Views or Omni-Channel Work Item Assignment Rules. This rebuild is manual and outside standard migration scope.

Helpshift Automations trigger on Issue events (create, time-elapsed, keyword match) such as auto-tagging, auto-assigning, or auto-replying. Automations are defined in Workflow Management and are not directly exportable. We audit each Automation during discovery, document the trigger event, conditions, and actions, and deliver a written rebuild plan for Salesforce Flow (record-triggered, scheduled, or platform event variants as appropriate). The customer or a Salesforce admin rebuilds automations post-migration. This manual rebuild effort adds 1-3 days per environment and must be planned upfront.

Helpshift attachments on Issues export as file references with metadata. We download attachments via the REST API, store them in a migration blob store, then upload to Salesforce as ContentDocument records linked via ContentDocumentLink to the parent Case. Large binary files may exceed API payload limits during fetch; we chunk downloads and use multipart upload for files over 25 MB. Attachment filenames and content types are preserved. If the customer uses Salesforce Files instead of Attachments, we use ContentDocument with the appropriate sharing settings.