Helpdesk migration
Field-level mapping, validation, and rollback between Aritic Desk and Salesforce Service Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Service Cloud.
Aritic Desk
Source
Salesforce Service Cloud
Destination
Compatibility
10 of 12
objects map 1:1 between Aritic Desk and Salesforce Service Cloud.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from Aritic Desk to Salesforce Service Cloud requires bridging a fundamental architectural gap: Aritic Desk does not publish a documented REST API, so we rely on its native export mechanism and supplemental database extraction for self-hosted instances. Salesforce Service Cloud receives the data via its Bulk API 2.0 with audit field enablement, validation rule bypass coordination, and parent-record lookup resolution for ticket-to-contact links. We preserve SLA timestamps, CSAT scores, and conversation history as structured Case data. Aritic macros with dynamic tokens, trigger logic dependent on Aritic-specific field names, and Aritic-specific KB personalization elements are flagged for manual rebuild in Salesforce because they contain syntax incompatible with the destination. We deliver a written inventory of automations, SLA policies, and KB articles with embedded macros so the customer's admin team has a documented rebuild guide post-migration.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Source platform
Aritic Desk platform overview
Scorecard, SWOT, gotchas, and pricing for Aritic Desk.
Destination platform
Salesforce Service Cloud platform overview
Scorecard, SWOT, gotchas, and pricing for Salesforce Service Cloud.
Data migration guide
The complete Salesforce Service Cloud migration guide
Data model, import mechanisms, field mapping strategy, pitfalls, and cutover — by the engineers running it.
Destination checklist
Salesforce Service Cloud migration checklist
Pre- and post-cutover tasks for moving onto Salesforce Service Cloud.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Aritic Desk object lands in Salesforce Service Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Aritic Desk
Ticket
Salesforce Service Cloud
Case
1:1Aritic Desk Tickets map directly to Salesforce Case. We extract ticket ID, subject, description, status (Open/Closed/Pending), priority, type, channel source, created and updated timestamps, and internal notes. Custom ticket fields migrate as custom Case fields pre-created in the destination org. Conversation threads (comments and replies) land as Salesforce EmailMessage records linked to the parent Case. We resolve the Aritic Customer reference to a Salesforce Contact ID before inserting Cases.
Aritic Desk
Customer
Salesforce Service Cloud
Contact
1:1Aritic Customer records map to Salesforce Contact with name, email, phone, and address fields preserved. The Aritic customer_id becomes a custom field aritic_customer_id__c on Contact for cross-reference. Customer tags migrate as a custom multi-select picklist or we link to TopicAssignment if the customer selects a topics strategy. Customer-to-ticket associations are preserved via the Case WhoId lookup to Contact.
Aritic Desk
Organization
Salesforce Service Cloud
Account
1:1Aritic Organization records map to Salesforce Account. Organization name becomes Account Name; domain maps to Website; industry and size tier map to Industry and NumberOfEmployees. The link between Aritic Customer and its parent Organization is preserved as a Contact-to-Account relationship in Salesforce with AccountId populated on the Contact record. We use the Organization domain as a dedupe key during import.
Aritic Desk
Agent
Salesforce Service Cloud
User
1:1Aritic Agent profiles map to Salesforce User records with name, email, role (Admin maps to System Administrator profile; Agent maps to a standard support profile we configure), and department preserved. Agent active/inactive status maps to Salesforce User IsActive. We extract all distinct agent emails and match against the destination org's User table. Missing users go to a reconciliation queue for the customer's admin to provision before record migration begins.
Aritic Desk
Knowledge Base Articles
Salesforce Service Cloud
Knowledge Article
1:1KB articles migrate as Salesforce Knowledge Articles with title, body content, author, creation date, and publish status preserved. We strip embedded Aritic dynamic tokens and conditional content blocks from article bodies and flag each affected article with a custom field kb_tokens_stripped__c set to true so the customer's knowledge base team can review and restore personalization using Salesforce's merge field syntax post-migration.
Aritic Desk
KB Categories and Sections
Salesforce Service Cloud
Topics and Data Categories
lossyAritic's hierarchical folder structure (Categories containing Sections containing Articles) maps to Salesforce Topics with parent-child Topic relationships, or to Data Category Groups if the destination org uses structured categorization. We replicate the same parent-child relationships in the destination so knowledge base navigation mirrors the source structure.
Aritic Desk
SLA Policies
Salesforce Service Cloud
Entitlement Process and Milestones
1:1Aritic Desk SLA policies (first response time, resolution time) are documented as structured metadata. We map them to Salesforce Entitlement Processes linked to Cases via the Entitlement object. We extract SLA rule conditions and action thresholds and deliver a written Entitlement Process configuration guide for the customer's admin to implement. SLA timestamps from Aritic migrate as custom fields on Case if the destination org does not have an active Entitlement Process configured.
Aritic Desk
CSAT Survey Responses
Salesforce Service Cloud
Survey and SurveyResponse or Custom Fields
1:1CSAT scores and survey responses linked to ticket records migrate as structured data. We preserve the rating value, respondent email, and ticket reference. If the destination Salesforce org has Salesforce Survey enabled, responses land as SurveyResponse records linked to the Case. If not, CSAT data lands as custom numeric fields on Case (csat_score__c, csat_respondent_email__c) for reporting without a full Survey configuration.
Aritic Desk
Macros
Salesforce Service Cloud
Quick Actions or Email Templates (documented)
1:1Aritic macros contain dynamic placeholders like {{ticket.customer_name}} and {{ticket.id}} that do not resolve in Salesforce because the destination uses different merge field syntax {!Contact.Name} and {!Case.Id}. We extract macro text content as plain-text templates and flag each macro with its Aritic token list for the customer's admin to repopulate in Salesforce as Quick Actions or Email Templates with Salesforce-appropriate merge fields. Macros with conditional logic based on Aritic-specific field names are documented for manual rebuild in Salesforce Flow.
Aritic Desk
Attachments
Salesforce Service Cloud
ContentDocument and ContentVersion
1:1File attachments on tickets and KB articles are extracted from Aritic Desk and uploaded to Salesforce as ContentVersion records linked via ContentDocumentLink to the parent Case or Knowledge Article. We flag files exceeding Salesforce's 25 MB per attachment limit or unsupported file types for manual handling. Inline images embedded in KB article bodies migrate as separate ContentVersion records with the article body updated to reference the new Salesforce-hosted URLs.
Aritic Desk
Tags
Salesforce Service Cloud
Multi-Select Picklist or Topic
lossyTags applied to tickets and customers in Aritic Desk migrate as flat label arrays. We validate character encoding compatibility between source and destination. The customer chooses during scoping whether tags land as a custom multi-select picklist field on Case and Contact, or as Salesforce Topics with TopicAssignment records linked to the parent record.
Aritic Desk
Time Entries
Salesforce Service Cloud
Custom Time Tracking Object
1:1Billable or internal time logged against tickets transfers as structured time records with agent, duration, description, and billable flag. We map to a custom Salesforce object (Time_Entry__c) with lookup to Case and User if the destination org does not have a native time tracking add-on installed. The custom object schema is deployed before migration begins.
| Aritic Desk | Salesforce Service Cloud | Compatibility | |
|---|---|---|---|
| Ticket | Case1:1 | Fully supported | |
| Customer | Contact1:1 | Fully supported | |
| Organization | Account1:1 | Fully supported | |
| Agent | User1:1 | Fully supported | |
| Knowledge Base Articles | Knowledge Article1:1 | Mapping required | |
| KB Categories and Sections | Topics and Data Categorieslossy | Fully supported | |
| SLA Policies | Entitlement Process and Milestones1:1 | Fully supported | |
| CSAT Survey Responses | Survey and SurveyResponse or Custom Fields1:1 | Mapping required | |
| Macros | Quick Actions or Email Templates (documented)1:1 | Mapping required | |
| Attachments | ContentDocument and ContentVersion1:1 | Mapping required | |
| Tags | Multi-Select Picklist or Topiclossy | Fully supported | |
| Time Entries | Custom Time Tracking Object1:1 | Mapping required |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Aritic Desk gotchas
No public REST API for programmatic data extraction
Agent-seat billing model is migration-critical
Macros and triggers contain Aritic-specific dynamic tokens
KB articles may embed macros and dynamic content
Limited third-party integration ecosystem
Salesforce Service Cloud gotchas
Data Export 512MB file size cap breaks large org exports
API Daily Request Limits vary by license edition
No automatic data backup in base Salesforce
Picklist dependencies silently break records when unmapped
Workflow rules fire unexpectedly during data load
Pair-specific challenges
Migration approach
Discovery and extraction method confirmation
We audit the source Aritic Desk environment across deployment type (cloud or self-hosted), agent count, ticket volume, knowledge base article count, active SLA policies, and macro count. For cloud instances we test the native export scope and confirm row counts against in-app reports. For self-hosted instances we confirm database access and schema documentation. We document active integrations (telephony, chat, CRM) and confirm whether equivalent Salesforce integrations exist. The discovery output is a written migration scope with extraction method, object inventory, and automation rebuild handoff list.
Salesforce org preparation and permission configuration
We work with the customer's Salesforce admin to configure the destination org for migration: grant Modify All Data permission and Enable Set Audit Fields upon Record Creation to the migration user profile, disable all active workflow rules, and identify any validation rules that may block import. We pre-create any custom fields, custom objects (Time_Entry__c, aritic_customer_id__c), and KB article custom fields before migration begins. We configure Entitlement Processes or prepare custom SLA fields based on the customer's SLA rebuild preference.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox (Developer or Full Copy depending on data volume) using production-like data from Aritic Desk. The customer's support operations lead reconciles record counts (Cases in, Contacts in, Accounts in, Knowledge Articles in), spot-checks 25-50 random records against the source system, and validates that conversation thread ordering and timestamp accuracy meet expectations. Any mapping corrections and field type adjustments occur in Sandbox before production migration begins.
Agent-to-User reconciliation and KB macro flagging
We extract every distinct Aritic Agent referenced on ticket records and match by email against the destination org's User table. Agents without a matching Salesforce User go to a reconciliation queue for the admin to provision. We flag Aritic macros with dynamic tokens and KB articles with embedded personalization as a separate migration artifact. The customer receives a written rebuild guide listing each flagged macro, its Aritic token references, and the recommended Salesforce Quick Action or Flow equivalent.
Production migration in dependency order
We run production migration in record-dependency order: Salesforce Users (validated against reconciled list), Accounts (from Aritic Organizations with domain as dedupe key), Contacts (with AccountId resolved), Cases (with WhoId pointing to Contact and custom SLA fields populated), Knowledge Articles (with stripped token bodies and Topics assigned), then attachments via ContentVersion. SLA policy metadata is delivered as a written Entitlement Process configuration guide. CSAT data lands as custom fields or Survey Responses depending on destination Survey configuration. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, delta sync, and automation rebuild handoff
We freeze writes in Aritic Desk during cutover, run a final delta migration of any records created or modified during the migration window, then re-enable workflow rules in Salesforce and set the destination org as system of record. We deliver the macro and SLA rebuild documentation to the customer's admin team. We provide a one-week hypercare window where we resolve reconciliation issues raised by the support team. We do not rebuild Aritic macros, triggers, or SLA policies as Salesforce Flow or Entitlement Processes inside the migration scope; that work is a separate engagement or an internal admin task.
Platform deep dives
Aritic Desk
Source
Strengths
Weaknesses
Salesforce Service Cloud
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 1 of 7 objects need a manual workaround.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Aritic Desk and Salesforce Service Cloud.
Object compatibility
1 of 7 objects need a manual workaround.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Aritic Desk: Not publicly documented.
Data volume sensitivity
Aritic Desk doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Aritic Desk to Salesforce Service Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Aritic Desk to Salesforce Service Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Aritic Desk
Other ways to arrive at Salesforce Service Cloud
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.