Migrate from Sobot Omnichannel Suite to Salesforce Service Cloud

Sobot Customer records map directly to Salesforce Contact with the primary Account created first as the parent. Sobot's customer list-view fields including email, phone, name, and custom properties map to standard Contact fields or custom Contact fields. Sobot's company-level data attached to Customer records creates a Salesforce Account record that the Contact references. We use Sobot's export field list to build the field mapping schema before import and flag any Sobot custom fields that do not have a direct Salesforce type equivalent for admin review.

Sobot Tickets map to Salesforce Cases with ticket status translated to Salesforce Case Status picklist values and ticket priority translated to Case Priority. Sobot's ticket ID is preserved in a custom field sobot_ticket_id__c for audit traceability. If Sobot uses a multi-pipeline ticket structure, each pipeline becomes a Salesforce Case Record Type with a corresponding Business Process that scopes the available status values. Cases are inserted after Accounts and Contacts so that the AccountId and ContactId lookups are satisfied at insert time.

Sobot conversation threads aggregate messages from email, chat, WhatsApp, and social channels into a single thread. We split each thread into individual Salesforce EmailMessage records (one per inbound and outbound message) and link them to the parent Case via the ParentId field. The channel type (email, chat, WhatsApp) is stored in a custom field channel_type__c. Agent handoff context and internal notes migrate as Task records with Status=Completed attached to the Case.

Sobot's ticket pipeline configuration maps to Salesforce Case Record Types, each paired with a Business Process that defines the available status values. Sobot's pipeline stage names translate to Case Status values. If Sobot uses multiple pipelines for different product lines or customer segments, we configure one Record Type per pipeline with separate Page Layouts assigned so agents see only relevant status options per case type.

Sobot Agent records map to Salesforce User records resolved by email match. Sobot's agent role (admin, supervisor, agent) and status fields map to Salesforce Profile, Role hierarchy, and User.IsActive. We run a pre-migration reconciliation to identify Sobot agents without a matching Salesforce User; the customer's admin provisions missing Users before record import proceeds because OwnerId is a required reference on Case and other standard objects.

Sobot team structures and skills-based routing configurations map to Salesforce Public Groups for team hierarchy and Omni-Channel Routing Configurations for skills-based routing. If Sobot uses queue-based ticket assignment, we configure Salesforce Omni-Channel Queues linked to the Routing Configuration. Skills and competencies defined in Sobot become Skills in Salesforce Omni-Channel and are assigned to Users before case routing begins.

Sobot channel configurations (email, WhatsApp, Facebook, Twitter, live chat) are preserved as channel-type metadata in Salesforce. Email channels migrate as Salesforce Email-to-Case configurations with the Sobot incoming email address re-pointed to the Salesforce routing address. WhatsApp channel migration requires independent Facebook Business Manager setup; we flag WhatsApp as a re-provisioning step in the migration scope. Social channels require new Facebook App and Twitter App registrations linked to Salesforce Social Customer Service.

Sobot KB Articles and KB Categories map to Salesforce Knowledge Article Versions with category assignments mapped to Salesforce Data Category Groups. Sobot's knowledge optimization data including view counts and feedback ratings migrate as custom fields on the Salesforce article. Articles are published to the appropriate Data Categories matching Sobot's category hierarchy before agents can access them in the Salesforce console.

Sobot workflow automation rules and chatbot task workflows export as structured logic definitions rather than visual drag-and-drop flows. We do not migrate automations as executable code to Salesforce Flow because the logic models differ structurally. Instead, we deliver a written inventory of every active Sobot workflow and automation with its trigger, conditions, actions, and a recommended Salesforce Flow equivalent. The customer's admin or a Salesforce partner rebuilds them post-migration.

Sobot tags on Customer records and Tickets migrate to Salesforce multi-select picklist fields on Contact and Case. We map the Sobot tag taxonomy directly to the destination picklist values and configure the field as a multi-select picklist type matching Sobot's multi-checkbox behavior.