Migrate from Supportbench to Salesforce Service Cloud

Supportbench Tickets map directly to Salesforce Case. We preserve case Subject, Description, Status, Priority, Type, created and modified timestamps, and the full message thread (emails, comments, attachments) as CaseComments and EmailMessages linked to the Case. Any Supportbench SLA metadata (response timer, breach timestamp) migrates to custom Case fields; the active SLA enforcement requires rebuild in Salesforce via Entitlement Processes post-migration.

Supportbench Customers map to Salesforce Contact records, with a paired Account record constructed from the Customer's company data. We use the Customer's company name as the Account Name and the Customer email as the Contact Email, resolving the AccountId on Contact before Case import so that cases attach to the correct Account. Any Salesforce-linked Company record in Supportbench (from its native Salesforce sync) is preserved as the Account record with the original Salesforce Account ID carried forward in a custom field.

Supportbench Agent records map to Salesforce User by email match. We preserve role, team assignment, and permissions as UserRole and custom fields. Unlimited custom roles (Enterprise-only in Supportbench) may require manual role mapping if the destination org has a different role hierarchy; we document any gap during scoping and the customer provisions missing roles before production migration.

Supportbench's internal agent KB exports as a separate pass from the external KB. Internal articles migrate to Salesforce Knowledge with Article Type set to an internal-facing variant and Channel set to Internal Only. Category hierarchy from Supportbench maps to Salesforce Knowledge Category Taxonomy. Attachment URLs are fetched and re-uploaded as ContentDocument records linked to the article.

Supportbench's customer-facing external KB migrates as a second pass to Salesforce Knowledge with Channel set to Public. Internal links within article body are rewritten to reference the new Salesforce Knowledge URLs. Translation data migrates as Salesforce Knowledge Translation records tied to the same Article ID. We flag articles with visibility restrictions for admin review post-migration.

Supportbench Survey responses tied to closed tickets migrate as Salesforce Case Comments with the survey type (CSAT, NPS, CES) and numeric score stored in custom Case fields. Survey widget configuration (branding, placement, trigger conditions) does not migrate; we document the survey setup as a checklist for the admin to reconfigure in Salesforce Survey or a third-party survey tool.

Supportbench's tiered SLA policies with escalation stages and response targets export as structured records but cannot be reproduced directly in Salesforce's Entitlement model. We deliver a written Entitlement Process and Milestone design document mapped from the Supportbench SLA policy structure. The customer's admin creates the Entitlement and assigns it to Accounts or Contacts post-migration. We do not automate Entitlement creation via API because Salesforce's entitlement model requires active assignment and activation steps that are org-specific.

Supportbench custom fields on Tickets map to custom fields on Salesforce Case. We handle data type conversion: Supportbench date pickers become Salesforce Date fields, dropdowns become Picklist with values preserved, and multi-select fields become Multi-Select Picklist. Free-text custom fields with no enforced format migrate as Long Text Area to avoid length truncation. Required-field constraints are flagged for the admin to reapply in Salesforce field-level security settings.

Supportbench Views are saved filter configurations scoped to an agent or team. There is no documented export of View definitions as structured objects. We capture View logic during the audit phase (filter fields, operators, values) from screenshots and admin descriptions, then re-implement each as a Salesforce List View or Saved Filter. Complex Views with nested conditions may require simplification or conversion to Salesforce Flow for dynamic assignment.

Supportbench ticket tags are free-form vocabulary stored per ticket. We export the tag values as a flat list, deduplicate naming collisions, and re-apply them in Salesforce as a Case Multi-Select Picklist field. If the customer prefers a taxonomy model, we offer Salesforce Topics with TopicAssignment as an alternative; the customer selects the strategy during scoping.

Customer health scores in Supportbench are computed from behavioral and support interaction signals using platform-internal algorithms. We migrate the current score as a static numeric custom field on the Salesforce Contact record (health_score__c). The scoring model itself cannot be replicated in Salesforce. We establish a baseline score at cutover and recommend that the customer evaluate Einstein Health Score or a Customer Success platform post-migration for recalibrated health tracking.

Supportbench Company records maintain a native sync link to Salesforce Account. We export the Company record and resolve the Salesforce Account ID from the sync reference. If the Salesforce Account has been modified since the last sync, we flag the record for the admin to verify the merge state before importing the Supportbench Company data.