Migrate from Servicely to Salesforce Service Cloud

Servicely Tickets (covering incidents, service requests, and problems) map directly to Salesforce Case records. Ticket status, priority, assignment, created date, and modified date migrate 1:1. The Servicely ticket ID is preserved in a custom field src_ticket_id__c for audit trail. Servicely's custom ticket fields are enumerated during the mandatory discovery call and mapped to typed Salesforce fields (text, picklist, number, date, or checkbox) before migration. Note that Salesforce supports separate Problem, Incident, and Request record types; we map Servicely's problem tickets to the Problem record type and incidents/requests to Incident and Request types based on the customer's Servicely workflow configuration.

Servicely Companies map to Salesforce Account records. The company name becomes the Account Name; any domain or website property becomes the Website field. Custom company properties (enumerated during discovery) map to typed Account custom fields. Account is created before any Contact or Case import so that AccountId lookups are satisfied at the moment of record insert. Companies without an associated customer record in Servicely are imported as B2B Accounts with no primary Contact.

Servicely Customer records map to Salesforce Contact records linked to the migrated Account. Email, name, phone, and portal association migrate directly. If the Servicely Customer has a lifecycle type indicating it is an unqualified prospect, we create a Salesforce Lead instead and convert to Contact post-migration. We preserve the Servicely customer_id in a custom field src_customer_id__c. Portal users from Servicely map to Salesforce Customer Portal users or Experience Cloud contacts depending on the Salesforce edition.

Servicely Agent records map to Salesforce User records. We resolve agents by email match against the destination org's User table. Permission set definitions (Servicely role-based access) have no direct Salesforce equivalent, so we flag each role for the customer's Salesforce admin to configure as Permission Sets and Profiles post-migration. Agents without a matching User go to a reconciliation queue for manual provisioning before record import resumes.

Servicely Service Catalog items (requestable services with variable fields and approval chains) do not have a direct Salesforce equivalent. Salesforce handles requestable services through Entitlements (defining what a customer is entitled to), Products (defining service offerings), and Flow-driven intake screens. We map Servicely catalog item names and approval routing metadata to Salesforce Entitlement records and document the Flow-based intake process the customer's admin must build. Approval chain logic is not migrated as automation; it is documented for manual rebuild.

Servicely SLA configurations (response and resolution deadlines tied to ticket priority) map to Salesforce Entitlement Processes with Milestone tracking. SLA names and target hours migrate as Entitlements. However, SLA enforcement logic (scheduling, business hours, escalation triggers) depends on Salesforce's Entitlement Process configuration and must be rebuilt in the destination. We deliver a written SLA mapping document specifying which Servicely SLA maps to which Entitlement Process, which business hours apply, and which milestones are triggered per Case priority.

Servicely stores workflow trees as structured JSON with activity node types (comment, user action, approval, complete, scriptable, scriptable async, timer, if/else branches) that have no guaranteed 1:1 equivalent in Salesforce Flow. We do not migrate workflows as code. We export the full workflow JSON, enumerate every node type and branch, and deliver a written Flow rebuild specification for each workflow that includes trigger conditions, branch logic, and recommended Salesforce Flow element equivalents. Workflow nodes using scriptable async or complex timer logic are flagged as high-complexity items requiring a Salesforce developer.

Servicely Knowledge Base articles (title, body HTML, category, tags) map to Salesforce Lightning Knowledge articles. Note that Salesforce Lightning Knowledge is a separate system from the deprecated Classic Knowledge, and the Lightning Knowledge Migration Tool is required if the destination org still uses Classic. We use the appropriate Salesforce Knowledge API (ArticleType create, ArticleVersion publish) and map Servicely categories to Salesforce Data Category Groups. HTML formatting compatibility is verified during the sandbox migration phase. Rich text images are migrated as ContentDocument records and linked via ContentDocumentLink.

File attachments on Servicely tickets and Knowledge articles migrate as Salesforce ContentDocument and ContentVersion records. Original filenames and MIME types are preserved. Attachments are linked to the parent Case or Knowledge Article via ContentDocumentLink. We download from Servicely's storage and upload to Salesforce's, preserving URL references where both platforms support it.

Tags applied to Servicely tickets and articles migrate as Salesforce Topics (for article categorization) or as multi-select picklist values on the Case object. We use Topics with TopicAssignment records for Knowledge article tags and multi-select picklist fields for ticket tags. The customer chooses the tag strategy during scoping based on whether they want cross-object tag queries in Salesforce.