Migrate from Helpy to Salesforce Service Cloud

Helpy Customers map to Salesforce Contacts. The Helpy CSV import uses name, email, company, and locale fields; we map these to Contact.FirstName, Contact.LastName, Contact.Email, Contact.AccountId (lookup resolved via Account mapping), and Contact.Locale__c (custom field). We resolve the AccountId by matching Helpy's company field to a pre-imported Salesforce Account, creating the Account if no match exists. Any Helpy customer without an email address is flagged for manual review because Salesforce requires an email for Contact records.

Helpy's company field on Customer records maps to Salesforce Account.Name. We import Accounts first, before Contacts, to satisfy the AccountId lookup requirement. Account is created from Helpy's company field; the Account's industry, website, and address fields come from any secondary data enrichment step the customer approves during scoping.

Helpy Tickets map to Salesforce Cases. We map Helpy ticket subject to Case.Subject, ticket body to Case.Description, priority to Case.Priority, and channel (email/web/chat) to a custom Case.Origin__c field or Salesforce's standard Origin picklist. Helpy assignee maps to Case.OwnerId via the User reconciliation pass (see Agent/Staff mapping). We pre-create a Case Record Type in Salesforce to represent Helpy's ticket type structure before migration.

Helpy Ticket Replies are a standalone import type linked to parent tickets by ticket number. We migrate replies as Salesforce EmailMessage records (for agent and customer-facing thread entries) and as Task records for internal notes flagged as private in Helpy. We sort all replies chronologically by timestamp before formatting and verify the parent Case exists in Salesforce using the ticket-number-to-Case-ID mapping before the reply pass begins. Out-of-order replies are held and re-sequenced before insert.

Helpy KB articles migrate to Salesforce Lightning Knowledge. Each doc's title maps to KnowledgeArticleVersion.Title, body maps to KnowledgeArticleVersion.Body (converted to Salesforce's rich-text article format), and category assignment maps to DataCategoryGroupSelection on the article. We run a two-pass approach: categories are published in Salesforce first, then articles are imported and assigned to their data categories. Any Helpy doc without a matching Salesforce category is placed in an unassigned state for the customer's admin to resolve post-migration.

Helpy categories map to Salesforce Knowledge data category groups and individual data categories. We create the category hierarchy in Salesforce Knowledge before KB article import begins, as Helpy requires that categories exist before articles can reference them. The Salesforce DataCategory model supports hierarchical categories (parent-child) matching Helpy's flat category structure, and we preserve the category ordering via the SortOrder field.

Helpy agents are referenced on tickets via assignee but are not a standalone importable entity. We extract all distinct assignee values from the Helpy ticket CSV and resolve each by email against the Salesforce destination org's User table. Agents without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before ticket import begins. We do not create Salesforce Users programmatically — User provisioning requires admin action per Salesforce's security model.

Helpy ticket tags migrate to Salesforce Topics (via TopicAssignment) for cross-object tagging, or to a custom multi-select picklist field on Case if the customer prefers tags scoped to support tickets. The customer's admin chooses the strategy during scoping. Tags without a matching Salesforce value are logged for manual review.

Helpy's CSV import does not support inline file attachments. We extract attachment file references during scoping, stage them in a managed CDN bucket, and provide a post-migration reference table mapping each ticket ID to its attachment URLs. The customer's admin attaches files to Cases in Salesforce manually or via a configured file-upload workflow post-migration. We do not embed binary files in Salesforce during the migration load because Helpy's export layer does not expose file content in a structured format.

Helpy supports limited custom metadata on tickets, and the CSV schema for custom fields varies by installation. We audit the target Helpy instance's custom field configuration during discovery, map each to a Salesforce custom field on Case (created via metadata API before migration), and validate that the field type is compatible. Any Helpy custom field that has no Salesforce equivalent (e.g., a field type Helpy supports but Salesforce does not natively model) is flagged with a recommended workaround in the migration scope document.