Migrate from Brisk Support to Salesforce Service Cloud

Brisk Support Tickets map directly to Salesforce Case records. Ticket subject maps to Case Subject, ticket status maps to Case Status, priority maps to Case Priority, and origin (email, phone, chat) maps to Case Origin. We preserve the original Brisk Support ticket ID in a custom field brisk_ticket_id__c for cross-reference. Conversation threads migrate as EmailMessage records linked to the Case via ContentDocumentLink for inline attachments. Internal notes migrate as Case Comments (IsPublished=false). Brisk Support's queue assignment maps to Salesforce Case Owner, which may reference a Queue if the destination org uses queue-based assignment.

Brisk Support Customer records map to Salesforce Contact. Name, email, phone, and company name migrate. We create a corresponding Account from the company name field if the customer provides one during scoping; if not, contacts attach to a designated default Account. Customer-to-ticket associations migrate as Case Contact roles. Any custom attributes on the Customer record migrate as custom Contact fields. Email becomes the dedupe key; we check for existing Contacts by email before insert to avoid duplicate records.

When a Brisk Support Customer record includes a company name, we create a corresponding Salesforce Account. Account Name comes from the company field, Website from any stored domain, and Industry or Phone from available source fields. Account is created before Contact insert so that AccountId is resolved on the Contact record at migration time. If the source account is on a Brisk Support tier without company-level data, we map to a default Account configured during scoping.

Brisk Support Agents map to Salesforce User records. We resolve agents by email match against the destination org's User table. Any Agent without a matching User goes to a reconciliation queue for the customer's Salesforce admin to provision before record import resumes. Role-based access controls in Brisk Support are not exportable; we document the role hierarchy from Brisk Support during discovery and recommend a Profile and Permission Set structure in Salesforce.

Brisk Support Queues map to Salesforce Queues of the Case object. We extract queue names and member lists during discovery but routing logic (weighting, conditions, escalation triggers) is platform-specific and does not migrate. We deliver a written inventory of every Brisk Support queue with its routing conditions, member agents, and SLA thresholds, plus a recommended Omni-Channel Configuration or Flow Builder equivalent for the customer's admin to implement post-migration.

Brisk Support Knowledge Base Articles map to Salesforce Knowledge. Article title maps to Title, article body (HTML or rich text) maps to Summary or the body field of the configured Article Type. Publication status (draft, published, archived) maps to Salesforce Knowledge ArticleVersion Status. Categories from Brisk Support migrate to Salesforce Knowledge Data Category Groups. Internal links within article bodies are flagged for manual update post-migration since relative paths break at the destination.

Brisk Support file attachments migrate to Salesforce Files (ContentDocument + ContentVersion). We download each attachment from the source UI, upload to Salesforce via the REST API, and link to the parent Case record via ContentDocumentLink. Free tier customers face a 60-day expiration risk; we flag any records with attachments during discovery and prioritize attachment export before the expiration window closes. Attachment metadata (filename, size, upload date) migrates as ContentVersion fields.

Brisk Support routing rules (Tier 2+) are non-portable by design. We document the rule logic during discovery: trigger conditions, condition operators, assignment targets, and weighting factors. The output is a written routing rule inventory with a recommended Omni-Channel Skills-Based Routing configuration or record-triggered Flow equivalent for each rule. Routing rules require re-implementation in Salesforce; they are not migrated as code.

Brisk Support escalation rules (Tier 2+) define time-based escalation paths. We document the rule structure: initial SLA duration, escalation trigger time, escalation target (agent, queue, or supervisor), and notification actions. The Salesforce equivalent is Entitlements and Milestones attached to the Contact or Account, with Salesforce Flow handling the escalation routing actions. Escalation rules require re-implementation in Salesforce and are delivered as a written inventory, not migrated.

Brisk Support custom ticket attributes (Tier 3 only) are per-organization and require field-level mapping to Salesforce Case custom fields. We extract the attribute names, data types, and picklist values from the source account, pre-create matching custom fields on the Case object in the destination org (via metadata API into Sandbox first), then map values during Case migration. If the customer downgrades tiers post-migration, custom attribute data remains in Salesforce and is not affected by the Brisk Support tier change.