Migrate from Hiver to Salesforce Service Cloud

Hiver Conversations map to Salesforce Cases. Each conversation thread becomes a Case record with the subject line mapped to Case Subject, the first inbound email body mapped to Case Description, and the current assignee mapped to Case OwnerId. Conversation status (Open, Pending, Closed) maps to Case Status (New, Working, Escalated, Closed). The original Shared Inbox reference is preserved in a custom field hiver_inbox_name__c for reporting and routing audit. Status and assignee are mapped directly; thread ordering is preserved by setting Case.CreatedDate to the first email timestamp in the Hiver thread.

Hiver Shared Inboxes map to Salesforce Queues (for routing) or Case Record Types (for segmentation) depending on the customer's intended Service Cloud configuration. A team with one Shared Inbox per product line typically maps each to a Case Record Type with its own Page Layout, Business Hours, and Entitlement. A team using inbox-level routing without segmentation maps the Shared Inbox to a Queue for Omni-Channel routing assignment. We confirm the configuration choice during scoping, design the Record Type or Queue structure in the Sandbox before production migration, and document the mapping in the handoff inventory.

Hiver exports all contacts as a discrete data type, separate from contacts embedded in conversation threads. We handle both exports and deduplicate where a contact appears in both exports. The Contact.Email maps to Salesforce Contact Email, Contact.Phone to Phone, and Contact.Name to Name. Hiver's address book contacts that have no associated conversation history are imported as Salesforce Contacts without an Account link; contacts that appear in conversations are linked to the corresponding Account by email domain match or an explicit AccountId field provided during scoping. We flag any naming collisions for manual resolution before import.

Hiver tags applied at the conversation level migrate to a Salesforce multi-select picklist field on Case (e.g., Case.Hiver_Tags__c) or to a custom Label set if the destination org uses the Case Labels feature. We extract the full tag taxonomy during scoping, confirm the tagging strategy with the customer (multi-select vs. label-based), and apply tags during Case import. Tags used for routing (e.g., auto-tagged by inbox or sender domain) are documented separately as potential Omni-Channel routing criteria.

Hiver Shared Notes are internal comments attached to conversations and visible to all team members. They map to Salesforce CaseComment records with CommentType = Internal. We confirm with the customer during scoping which notes should be marked internal versus public, as some platforms distinguish between internal notes and public replies. Notes that reference other Hiver conversations or users are documented with a note in the import output for manual follow-up. CaseComment does not support rich text natively; plain-text notes migrate as-is; formatted notes are converted to plain text with a warning logged.

Hiver Email Templates are stored as discrete objects with body, subject, and conditional logic. They migrate to Salesforce EmailTemplate (Classic or Lightning). Subject variables map to Salesforce merge field syntax (e.g., {{contact.firstname}}). Conditional logic built in Hiver's template engine is documented as a feature gap — Salesforce Email Templates support conditional merge fields and HTML but not the same step-based conditional branches found in Hiver. We preserve the full template body, flag any unsupported logic, and recommend Salesforce Lightning Email Templates or a third-party template tool (like Salesforce Inbox or an AppExchange solution) as the replacement for advanced conditional templating.

Hiver Shared Drafts are unsent email replies saved within conversations. They migrate as draft Salesforce EmailMessage records linked to the parent Case. Whether draft emails render in the Case activity timeline depends on the Salesforce edition and email-to-case configuration. We flag draft migration as conditional: if the destination org uses Salesforce Email-to-Case and the email-to-case address is configured to auto-create Cases, draft migration adds complexity. We recommend the customer review whether Shared Drafts need to migrate or whether agents should rebuild them post-migration.

Hiver agent records (name, email, assignment permissions) map to Salesforce User records. We extract the user roster from Hiver and match by email against the destination Service Cloud org. Any Hiver agent without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before Case OwnerId references can be resolved. Permissions (view-only, admin, inbox member) map to Salesforce Permission Sets or Profile assignments post-migration. We do not migrate Hiver permissions as-is; we deliver a permission matrix for the admin to configure in Salesforce.

Hiver SLA Policies define business hours and response/resolution deadlines enforced at the Shared Inbox level. They map to Salesforce Entitlement Processes (scoped to an Entitlement) with Milestone types for First Response and Resolution. Each Hiver SLA Policy becomes a Salesforce Entitlement record tied to the Account (for account-level SLA) or the Case (for case-level SLA depending on the customer's Hiver configuration). Business Hours defined in Hiver migrate to Salesforce Business Hours linked to the Entitlement. We extract the full SLA configuration during scoping, map each inbox-level SLA to an Entitlement Process with milestones, and document any tier-based SLA structures (e.g., Premium vs Standard) that require multiple Entitlement Processes.

CSAT survey responses and aggregate scores tied to resolved Hiver conversations migrate to a Salesforce custom field on Case (e.g., Case.CSAT_Score__c) or to Salesforce Surveys if the destination org licenses the Surveys feature. Hiver's survey configuration (question text, rating scale) migrates as survey questions in Salesforce Surveys, but individual responses are linked to the originating Case by CaseNumber. Survey configuration requires manual setup in Salesforce Surveys; we deliver a survey field mapping document and recommend the customer's admin configure the survey questions post-migration if the survey structure is complex.

Hiver custom fields on conversations (e.g., Order ID captured via AI Extract, product tier, region) map to custom fields on Salesforce Case. We export the full field schema during scoping, map each to an equivalent Salesforce field type (text, number, picklist, checkbox, date), pre-create the custom fields in the destination org before migration, and populate them during Case import. Custom fields that reference other Hiver objects (e.g., a linked order from a separate system) are documented as external-ID-style references for the customer's admin to reconcile post-migration.

Hiver Automations (trigger/condition/action/AI-Extract steps) have no bulk export path and cannot be migrated as code. We document every active Automation during the pre-migration audit: trigger type, conditions, actions, AI Extract steps, and the Shared Inbox or tag context where it fires. This inventory is delivered as a written handoff document with each Automation translated to a recommended Salesforce Flow type (record-triggered Flow for field-change triggers, scheduled Flow for time-based delays, Screen Flow for agent-facing guidance). The customer's admin or a Salesforce partner rebuilds them post-migration. We do not configure Flow as part of the migration scope.