Migrate from HelpDeskEddy to Salesforce Service Cloud

HelpDeskEddy Tickets map directly to Salesforce Cases. The HelpDeskEddy status values (open, in-progress, resolved) map to Salesforce Case Status picklist values. Priority maps to Case Priority. The ticket body migrates as the Case Description. We set the ContactId by resolving the ticket requester email against the Salesforce Contact table; if no Contact exists, we create one under the nearest Account. Case Origin and Case Reason map from HelpDeskEddy's channel and resolution-type fields respectively.

HelpDeskEddy Customer profiles (name, email, phone, company) map to Salesforce Contact records, with the company name used to find or create an Account parent. If HelpDeskEddy stores multiple contacts per ticket, we deduplicate by email and attach all unique contacts to the Case via CaseContactRole. Any contact without a company name in HelpDeskEddy lands on a default Account (e.g., 'Unknown Organization') that the customer's admin can merge post-migration.

HelpDeskEddy Departments map to Salesforce Queues for case assignment or Public Groups for reporting visibility. We preserve the department hierarchy and map HelpDeskEddy agent access rights to Salesforce sharing rules at the group level. If the destination org uses Role-based sharing, we map departments to the closest matching Role hierarchy depth.

HelpDeskEddy agents referenced on tickets map to Salesforce User records by email match. We resolve the HelpDeskEddy operator ID to the Salesforce OwnerId on Case. Any HelpDeskEddy agent without a matching Salesforce User goes to a reconciliation queue; the customer's admin provisions missing users before Case migration resumes.

HelpDeskEddy supports per-ticket individual custom fields that may differ ticket-to-ticket. We enumerate all observed custom field names and types across the migration scope, deduplicate by name, and map each to a Salesforce custom field on Case. Text fields map to Text, dropdowns to Picklist, dates to Date, and numeric values to Number. We pre-create the destination custom field schema via Salesforce Metadata API before any Case import begins.

HelpDeskEddy tags on tickets migrate to Salesforce Case Tags (a standard Service Cloud feature) or to a multi-select picklist field on Case depending on the destination org's tagging strategy. The customer selects the approach during scoping. Tags used for categorization rather than labeling migrate to Salesforce Topics with TopicAssignment records.

HelpDeskEddy time-tracking data attached to tickets migrates to Salesforce Case as a custom time-entry field (Case_Hours__c) or as a billable-hours field if the destination org includes Financial Services Cloud. Precision depends on whether the destination supports time entries as sub-objects; if not, we aggregate total time into a numeric field on Case.

HelpDeskEddy CSAT ratings migrate to a custom numeric field (CSAT_Score__c) on the Case object. Some Salesforce orgs store satisfaction as a separate custom object linked to Case; we map to the most semantically close structure and flag where precision may differ. The original HelpDeskEddy rating scale is preserved in a separate field (CSAT_Scale__c) for reference.

HelpDeskEddy Knowledge Base articles migrate to Salesforce Knowledge as articles of the configured Article Type. We preserve article body content, status (published/draft), associated tags, and category assignments. Public-facing KB URLs will differ at the destination; we document the URL mapping so the customer's admin can set up redirects. If Salesforce Knowledge is not enabled in the destination org, we flag this as a pre-requisite during scoping.

HelpDeskEddy chat channel logs migrate as Case Comments (for internal notes) or EmailMessage records (for customer-visible thread entries) attached to the originating Case. We map chat timestamps, agent name, and message body; rich media links in chats migrate as text references and may require separate handling if they point to HelpDeskEddy-hosted files.