Helpdesk migration
Field-level mapping, validation, and rollback between ASAPP and Salesforce Service Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Service Cloud.
ASAPP
Source
Salesforce Service Cloud
Destination
Compatibility
10 of 12
objects map 1:1 between ASAPP and Salesforce Service Cloud.
Complexity
BStandard
Timeline
4-8 weeks
Overview
ASAPP organizes its data around Conversations, Agents, Customers, Structured Data Fields, and Segments, delivered through S3 batch, File Exporter API, and real-time event APIs with different latency profiles. We query all three channels during scoping to reconstruct a unified conversation timeline and avoid gaps. Custom structured-data fields and segments require manual schema mapping because ASAPP field names and data types do not map automatically to Salesforce's custom field model. ASAPP's AI model tuning, routing rules, and workflow automations are proprietary platform settings that cannot be exported and must be rebuilt in Salesforce Service Cloud using Flow, Omni-Channel, and Einstein Bot. We deliver a written configuration inventory during discovery so the destination team has a rebuild spec from day one.
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
ASAPP platform overview
Scorecard, SWOT, gotchas, and pricing for ASAPP.
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 ASAPP 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.
ASAPP
Conversation
Salesforce Service Cloud
Case
1:1ASAPP conversations are the primary data unit and map directly to Salesforce Case records. Channel type (voice, messaging, digital) maps to Case Origin; conversation start and end timestamps map to Case CreatedDate and ClosedDate. Resolution outcome, CSAT scores, and routing information transfer to standard and custom Case fields. If ASAPP segments are defined for specific conversation types, we use the segment identifier to set the Case Record Type during import so that stage values and page layouts are scoped per conversation category.
ASAPP
Customer
Salesforce Service Cloud
Contact
1:1ASAPP customer profiles associated with conversations map to Salesforce Contact records. Customer name, email, phone, and any custom profile fields migrate to Contact fields. We use email as the dedupe key and match against the destination Contact table; unmatched customers create new Contact records. The association between each ASAPP conversation and its customer is preserved as a ContactId reference on the migrated Case so agent consoles show the full customer context without switching systems.
ASAPP
Customer
Salesforce Service Cloud
Account
lossyWhen ASAPP customer records include a company or organization field, we map it to Salesforce Account and link the Contact to the Account via AccountId. If ASAPP does not expose a company association for a customer, we create an Account using the customer domain as a placeholder and flag it for the customer's Salesforce admin to merge into the correct Account during reconciliation. This prevents orphaned Contacts with no Account reference in Salesforce Service Cloud.
ASAPP
Agent
Salesforce Service Cloud
User
1:1ASAPP agent records including performance metrics, handle time data, and assignment metadata map to Salesforce User records. We match agents by email against the destination Salesforce org's User table during scoping. Any ASAPP agent without a matching Salesforce User is held in an Owner reconciliation queue for the customer's admin to provision the User before the Case migration phase begins. Agent performance data (average handle time, CSAT per agent) migrates to a custom Agent_Stats__c object created in the destination org before load.
ASAPP
Structured Data Field
Salesforce Service Cloud
Custom Field (Contact or Case)
1:1ASAPP custom structured-data fields extracted from conversations via the structured-data-field API do not have direct Salesforce equivalents. We export the full ASAPP field schema during scoping, identify each field's data type, and map it to the closest Salesforce field type: text fields become Text, numeric extractions become Number, date values become Date, and categorical data becomes Picklist. We pre-create all custom fields on the Case object in Salesforce before any migration batch runs so that field IDs are stable during import.
ASAPP
Segment
Salesforce Service Cloud
Case Record Type
1:1ASAPP segments define which structured data the system extracts for specific conversation types. Segment definitions and their associated field sets are exported via ASAPP's segments API. We use segment identifiers to set Salesforce Case Record Types so that stage values, page layouts, and custom field visibility are scoped per conversation category in the destination org. Segment-to-Record-Type mapping is defined during scoping and applied as the first transform step during Case migration.
ASAPP
Conversation Metadata
Salesforce Service Cloud
Case Fields
1:1Conversation metadata including channel type, routing information, queue assignment, wait time, wrap-up time, and CSAT score migrates to standard and custom Case fields. We map ASAPP's queue and routing identifiers to Salesforce Omni-Channel routing configuration names so that routing context is preserved in the destination. Historical CSAT scores transfer to a custom field Case.CSAT_Score__c for reporting continuity.
ASAPP
Engagement: Call
Salesforce Service Cloud
Task (TaskSubtype = Call)
1:1ASAPP voice engagement records including call duration, disposition, and recording URL map to Salesforce Task records with TaskSubtype set to Call. Call duration in seconds transfers to CallDurationInSeconds; disposition code transfers to a custom Task field Call_Disposition__c; recording URL transfers to a custom Task field Call_Recording_URL__c. The Task links to the parent Case via WhatId and to the Contact via WhoId so agents see the full call history within the case console.
ASAPP
Engagement: Email and Messaging
Salesforce Service Cloud
EmailMessage + Task
1:1ASAPP messaging and email engagement records migrate to Salesforce EmailMessage records (the message content) linked to a Task record (the activity timeline entry). The WhoId on Task points to the Contact; WhatId points to the related Case. Message timestamps preserve activity timeline ordering by setting ActivityDate to the original ASAPP engagement timestamp. Rich text content and inline images transfer as-is; attachments migrate as ContentDocument records linked via ContentDocumentLink.
ASAPP
Engagement: Note
Salesforce Service Cloud
Note
1:1ASAPP note engagements migrate to Salesforce Note records linked via ContentDocumentLink to the parent Case. Note body transfers as rich text with any embedded attachments preserved as separate ContentDocument records. We verify that the Notes object is enabled in the destination org during schema design, as Salesforce Classic and some Lightning configurations disable Notes in favor of ContentNotes.
ASAPP
Report (Batch)
Salesforce Service Cloud
Report
lossyASAPP delivers reports via three channels with batch reports considered the authoritative source for historical data. We export report metadata (report names, field definitions, filter criteria) from ASAPP and provide a written report inventory specifying the Salesforce standard report type or custom report type that corresponds to each ASAPP report. Reports themselves do not migrate as executable Salesforce reports; we deliver the requirements spec for rebuilding in Salesforce Reports and Dashboards.
ASAPP
AI Model Configuration
Salesforce Service Cloud
Not Migratable
1:1ASAPP GenerativeAgent model tuning, routing rules, intent configurations, and AI triage thresholds are proprietary platform settings stored in ASAPP's managed environment. These cannot be exported via API. We document the full configuration inventory during the discovery phase, capturing routing logic, intent definitions, triage decision trees, and AI confidence thresholds as a written requirements spec. The customer's Salesforce team or implementation partner rebuilds equivalent routing and case classification logic in Salesforce Omni-Channel, Flow, and Einstein Bot post-migration.
| ASAPP | Salesforce Service Cloud | Compatibility | |
|---|---|---|---|
| Conversation | Case1:1 | Fully supported | |
| Customer | Contact1:1 | Fully supported | |
| Customer | Accountlossy | Fully supported | |
| Agent | User1:1 | Fully supported | |
| Structured Data Field | Custom Field (Contact or Case)1:1 | Fully supported | |
| Segment | Case Record Type1:1 | Fully supported | |
| Conversation Metadata | Case Fields1:1 | Fully supported | |
| Engagement: Call | Task (TaskSubtype = Call)1:1 | Fully supported | |
| Engagement: Email and Messaging | EmailMessage + Task1:1 | Fully supported | |
| Engagement: Note | Note1:1 | Fully supported | |
| Report (Batch) | Reportlossy | Fully supported | |
| AI Model Configuration | Not Migratable1:1 | Fully supported |
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.
ASAPP gotchas
ASAPP API rate limit of 100 req/s with daily hard cap
ASAPP exports are split across three distinct reporting channels
Custom structured data fields and segments require manual schema mapping
Configuration and AI model settings are not exportable
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 export architecture audit
We audit the ASAPP environment across data export channels (S3 batch, File Exporter API, real-time event API), agent count, conversation volume, structured-data field schemas, and segment definitions. We pair this with a Salesforce edition decision: Essentials ($25/user) for basic case management, Professional ($100/user) for Flow automation and custom fields, Enterprise ($175/user) for Omni-Channel routing and Einstein AI, or Agentforce 1 Service ($550/user) for full autonomous AI agent capabilities. The discovery output is a written migration scope, Salesforce edition recommendation, and the ASAPP-to-Salesforce field mapping document.
Schema design and Salesforce sandbox configuration
We design the destination schema in Salesforce: custom fields on Case and Contact with types mapped from ASAPP structured-data field schemas, Case Record Types derived from ASAPP segment definitions, Omni-Channel routing configuration matched to ASAPP queue structures, and a custom Agent_Stats__c object for agent performance data. Schema is deployed via metadata API into a Salesforce Sandbox first for validation. We pre-create all custom fields and validate that picklist values, field lengths, and required constraints are consistent with ASAPP data before any data extraction begins.
Three-channel export reconciliation and scoping
We extract data from all three ASAPP export channels (S3 batch, File Exporter API, real-time event API) and cross-reference records by conversation ID to build a unified migration dataset. Any conversations present in real-time exports but absent from batch files are flagged for customer review. We compute the total record count per object and estimate the number of API calls required to validate that the export fits within ASAPP's daily quota and spike arrest limits across the migration window.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox using production-like data volume. The customer's Salesforce admin or service operations lead reconciles record counts (Cases in, Contacts in, Tasks in), spot-checks 25-50 records against the ASAPP source, and validates that custom fields are populated and picklist values are correctly mapped. Any mapping corrections happen in the sandbox before production migration begins. The customer signs off the sandbox results before we proceed.
Owner reconciliation and User provisioning
We extract every distinct ASAPP agent referenced on conversations and engagement records and match by email against the destination Salesforce org's User table. Agents without a matching Salesforce User go to a reconciliation queue. The customer's admin provisions any missing Users (active or inactive depending on whether the original ASAPP agent is still employed) before record import resumes. This step gates the Case migration phase because OwnerId references must be valid on every Case record.
Production migration in dependency order
We run production migration in record-dependency order: Users (validated), Accounts (from ASAPP company data), Contacts (with AccountId resolved), Cases (with ContactId, OwnerId, and RecordTypeId resolved), Tasks and EmailMessages (via Bulk API 2.0 with parent-record lookup resolution). Custom structured-data field values load last as additional Case field updates. Each phase emits a row-count reconciliation report before the next phase begins. We freeze ASAPP writes during cutover and run a final delta migration for any records modified during the migration window.
Cutover, validation, and configuration rebuild handoff
We enable Salesforce Service Cloud as the system of record and deliver the AI configuration inventory document specifying routing rules, intent definitions, triage thresholds, and Flow rebuild recommendations for the destination team. We provide a hypercare window of up to one week to resolve reconciliation issues raised by the service team. We do not rebuild ASAPP routing logic as Salesforce Flow or Einstein Bot within the migration scope; that is a separate engagement.
Platform deep dives
ASAPP
Source
Strengths
Weaknesses
Salesforce Service Cloud
Destination
Strengths
Weaknesses
Complexity grading
Standard Helpdesk migration. 1 of 7 objects need a manual workaround.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across ASAPP 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
ASAPP: 100 requests per second spike arrest; daily hard cap that returns 429 and can trigger token revocation.
Data volume sensitivity
ASAPP exposes a bulk API — large-volume migrations stream efficiently.
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 ASAPP to Salesforce Service Cloud migration scoping. Not seeing yours? Book a call.
Walk through your ASAPP 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 ASAPP
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.