Helpdesk migration
Field-level mapping, validation, and rollback between Pylon and Salesforce Service Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Service Cloud.
Pylon
Source
Salesforce Service Cloud
Destination
Compatibility
7 of 12
objects map 1:1 between Pylon and Salesforce Service Cloud.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Migrating from Pylon to Salesforce Service Cloud is primarily a data-shape translation: Pylon's Issues map to Cases, its Accounts map to Accounts, and its Contacts map to Contacts with the same field types where possible. The complexity lives in three areas. First, Pylon's native Slack-channel threading model means conversations are structured as threaded Slack messages rather than standard email threads — we flatten that history into the Case feed and EmailMessage objects in the order the messages occurred. Second, Pylon's Account Intelligence layer (Notebooks, Tasks, Projects, Activities) is a non-standard schema that we assess at scoping: Tasks and Activities migrate as custom objects or custom fields depending on the destination org's capacity; Notebooks and Projects require a customer decision on whether to represent them as Salesforce Tasks, Opportunities, or a custom object. Third, Salesforce Service Cloud pricing scales with edition (Starter at $25/user/mo through Unlimited at $350/user/mo) and requires a Salesforce admin to provision custom fields before we run import. We deliver the complete schema diff upfront so the admin knows exactly what to create. Workflows, automations, and Pylon's AI feature configurations do not migrate; we provide a written inventory for the customer's admin to rebuild in Flow.
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
Pylon platform overview
Scorecard, SWOT, gotchas, and pricing for Pylon.
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 Pylon 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.
Pylon
Issue
Salesforce Service Cloud
Case
1:1Pylon Issues map to Salesforce Case records. Issue subject becomes Case Subject, Issue body and thread history become EmailMessage records (for email-originated Issues) or Chatter FeedItem records (for Slack-channel-originated Issues). Created time, response time, and resolution time migrate to Case CreatedDate, FirstResponseDate (custom field), and ClosedDate respectively. Issue status maps to Case Status with the customer's status matrix applied.
Pylon
Account
Salesforce Service Cloud
Account
1:1Pylon Accounts map directly to Salesforce Account records using domain matching and name matching as the dedupe key. Account-level custom fields migrate to custom Account fields created by the customer's admin before migration. Any Pylon Account with a Salesforce account_id from an existing Pylon-Salesforce integration is matched by that external ID to prevent duplicate Account creation.
Pylon
Contact
Salesforce Service Cloud
Contact
1:1Pylon Contacts map to Salesforce Contact records. The Contact's primary AccountId is resolved by matching the Pylon Contact's account association against the imported Account records. Email becomes the dedupe key. Custom contact fields migrate via the custom field pipeline. Pylon Contacts created from Slack channel membership (where email may not exist) are flagged in the reconciliation report for admin review.
Pylon
Team
Salesforce Service Cloud
Queue
1:1Pylon Teams map to Salesforce Queues. Queue membership is populated from Pylon Team membership at migration time. If the Pylon team routing is condition-based (not static assignment), we represent the routing conditions in the handoff document and recommend Omni-Channel Work Item Assignment Rules as the Salesforce equivalent.
Pylon
User
Salesforce Service Cloud
User
1:1Pylon Users map to Salesforce User records by email match. Any User without a matching Salesforce User is held in the reconciliation queue for the admin to provision. Agent-level metrics (CSAT, handle time) from Pylon are preserved as custom fields on the Salesforce User record when the destination schema supports them.
Pylon
Custom Fields (Issue-level)
Salesforce Service Cloud
Custom Fields (Case-level)
lossyPylon custom fields on Issues migrate as custom fields on Salesforce Case. The customer admin creates the destination custom fields in Object Manager before migration (type, label, and API name matched to source). We provide a complete schema diff listing each Pylon custom field with its data type, API name, and recommended Salesforce field type. Picklist values from Pylon migrate as Salesforce picklist values on the equivalent field.
Pylon
Article
Salesforce Service Cloud
Article (Knowledge Base)
1:1Pylon Articles migrate to Salesforce Knowledge Articles of the chosen Article Type. Article body migrates as the Article's Rich Text body field with HTML sanitization applied. Author and created timestamp migrate to Salesforce fields. We preserve article-to-collection assignments by tagging articles with a Category field or migrating to Salesforce Category Groups depending on the destination's Knowledge version.
Pylon
Collection
Salesforce Service Cloud
Category
1:1Pylon Collections (folders) migrate as Salesforce Knowledge Category Groups and Data Category selections. Nested sub-collections map to sub-categories in Salesforce. Permission settings on Collections migrate to Article Management permissions on the Salesforce Knowledge site if the customer has Knowledge enabled.
Pylon
Account Intelligence: Task
Salesforce Service Cloud
Task or Custom Object
lossyPylon Tasks from the Account Intelligence layer migrate to Salesforce Task records linked to the parent Account, or to a custom Account Intelligence Task object depending on the customer's chosen schema. We recommend during scoping whether to use standard Tasks (simpler, searchable in Activity timelines) or a custom object (more fields, better separation from case-level activity). The customer's admin decides and we implement the chosen approach.
Pylon
Account Intelligence: Activity
Salesforce Service Cloud
Task or Event
lossyPylon Activities from the Account Intelligence layer migrate to Salesforce Task or Event records based on activity type. Meeting-type activities map to Event; all others map to Task. Activity timestamps and descriptions preserve. The customer chooses the representation during scoping, and we apply it consistently across all migrated records.
Pylon
Account Intelligence: Notebook
Salesforce Service Cloud
Custom Object or Content Note
lossyPylon Notebooks contain free-form notes and account health summaries that do not map to a standard Salesforce object. During scoping, the customer chooses whether to migrate Notebooks as Salesforce ContentNote records (linked to Account via ContentDocumentLink) or as a custom Account Intelligence Notebook custom object with a Long Text Area field for the note body. Notebooks with structured fields (e.g., health score, risk indicators) are better suited to a custom object.
Pylon
Account Intelligence: Project
Salesforce Service Cloud
Custom Object
lossyPylon Projects are tracked projects tied to Accounts and do not map to any standard Salesforce object. We migrate them as a custom Account_Project__c object with Name, Description, Status, AccountId (lookup), and due date fields. If the customer uses Salesforce Opportunities to represent project-based revenue, we offer a mapping option where Projects become Opportunities with a custom record type.
| Pylon | Salesforce Service Cloud | Compatibility | |
|---|---|---|---|
| Issue | Case1:1 | Fully supported | |
| Account | Account1:1 | Fully supported | |
| Contact | Contact1:1 | Fully supported | |
| Team | Queue1:1 | Fully supported | |
| User | User1:1 | Fully supported | |
| Custom Fields (Issue-level) | Custom Fields (Case-level)lossy | Fully supported | |
| Article | Article (Knowledge Base)1:1 | Fully supported | |
| Collection | Category1:1 | Fully supported | |
| Account Intelligence: Task | Task or Custom Objectlossy | Fully supported | |
| Account Intelligence: Activity | Task or Eventlossy | Fully supported | |
| Account Intelligence: Notebook | Custom Object or Content Notelossy | Fully supported | |
| Account Intelligence: Project | Custom Objectlossy | 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.
Pylon gotchas
AI pricing is a separate billing line item
Annual billing with seat minimums locks migration timing
Seamless email migration only works from Zendesk, Front, or Intercom
Pylon migrates data only, not destination configuration
Learning curve delays agent productivity post-migration
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 schema decision gate
We audit the source Pylon workspace: Issues, Accounts, Contacts, Teams, Users, Knowledge Base Articles and Collections, and Account Intelligence objects. We specifically ask the customer's admin to decide how Notebooks, Projects, and Activities from the Account Intelligence layer should be represented in Salesforce. We also audit active integrations, Broadcasts, and AI Assist configurations. The discovery output is a written migration scope, a schema diff for custom fields, and the Account Intelligence schema decision form. This step gates all subsequent work.
Salesforce admin provisions custom fields
We provide the complete schema diff to the customer's Salesforce admin, who creates all required custom fields in Object Manager before the migration run. This includes custom fields on Case (for Issue-level custom fields), Account (for account-level custom fields and Account Intelligence data), Contact, and any custom Account Intelligence objects. We validate the field API names and data types match the diff before proceeding. We recommend using a Salesforce Sandbox for the first provisioning pass to avoid blocking production configuration.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox using production-like data volume. The customer's admin and support operations lead reconcile record counts (Issues in, Cases in; Contacts in; Articles in), spot-check 25-50 records against the Pylon source for field accuracy, and validate that the Account Intelligence objects landed in the correct schema representation. Any mapping corrections and custom field gaps are resolved here before production migration begins.
Owner and Team reconciliation
We extract every distinct Pylon User and Team and match against the Salesforce destination org's User table and Queue list. Pylon Users without matching Salesforce Users go to the reconciliation queue. The admin provisions missing Users or confirms they should be left inactive. Pylon Teams map to Salesforce Queues; static routing assignments migrate directly. Condition-based routing (dynamic team assignment) is documented in the routing handoff document for Omni-Channel Work Item Assignment Rule rebuild.
Production migration in dependency order
We run production migration in dependency order: Accounts first (the parent for Contacts and Cases), then Contacts (with AccountId resolved), then Cases (with ContactId and AccountId resolved, and thread history flattened from Slack format into Case feed), then Knowledge Base Articles and Categories, then Account Intelligence objects (Tasks, Activities, Notebooks, Projects) using the schema representation chosen at scoping. Each phase emits a row-count reconciliation report before the next phase begins. We use Salesforce Bulk API 2.0 with batch chunking and exponential backoff for high-volume phases.
Cutover, validation, and automation rebuild handoff
We freeze Pylon writes during cutover, run a final delta migration of records modified during the migration window, then enable Salesforce Service Cloud as the system of record. We deliver the Integration and Broadcast inventory document, the Pylon AI feature mapping to Einstein AI recommendation document, and the routing rule handoff for Omni-Channel rebuild. We support a one-week hypercare window for reconciliation issues. We do not rebuild Pylon triggers, macros, or routing rules as Salesforce Flow inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
Pylon
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 Pylon 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
Pylon: Not publicly documented.
Data volume sensitivity
Pylon 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 Pylon to Salesforce Service Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Pylon 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 Pylon
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.