Migrate from Plumsail HelpDesk to Salesforce Service Cloud

Plumsail Tickets are SharePoint list items with status, priority, assignee, and timestamps. They map 1:1 to Salesforce Case records. The original Plumsail ticket ID migrates to a custom field plumsail_ticket_id__c for audit and cross-reference. Ticket status (Open, Pending, Resolved, Closed) maps to Salesforce Case Status picklist values, with any non-standard statuses flagged for pre-migration picklist configuration in the destination org.

Plumsail Contacts live in a dedicated SharePoint contacts list linked to tickets by email. They map to Salesforce Contact records, with name, email, phone, and organization linkage preserved. Custom Contact fields in SharePoint columns migrate as custom fields on the Contact object. Email becomes the dedupe key; any duplicate email during import is flagged for manual resolution before the Contact import phase begins.

Plumsail Organizations are a distinct SharePoint list object linked to both Contacts and Tickets. They map to Salesforce Account records. Organization name becomes Account Name, and any custom Organization fields migrate as custom Account fields. Account must be inserted before the Contact import phase because Salesforce Contacts require an AccountId reference (or null for contacts without an organization).

Plumsail Comments are rows in a related SharePoint list attached to a Ticket. Public comments (customer-visible) migrate as Salesforce EmailMessage records with IsExternallyVisible = true. Private agent notes migrate as EmailMessage with IsExternallyVisible = false. Both are linked to the parent Case via the EmailMessage.ParentId field. Comment author and timestamp preserve the Plumsail activity timeline. High-volume comment imports are staged across months to smooth Plumsail's comment billing impact.

Plumsail Agents are SharePoint users with the HelpDesk Agent role. We extract agent identities and map them to Salesforce User records by email match. Role-based access (admin vs. agent) translates to Salesforce profiles and permission sets. Any Plumsail Agent without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Plumsail Tags are SharePoint taxonomy or choice-field keywords applied to tickets for classification. Tag strings migrate to Salesforce as Case Tag records if the destination uses Salesforce Knowledge or as a custom multi-select picklist field on Case (plumsail_tags__c). The customer chooses the tagging strategy during scoping.

Plumsail Categories are choice or lookup fields on the ticket SharePoint list. Category values migrate to a custom picklist field on Case (plumsail_category__c). Any categories not present in the destination are flagged during scoping for pre-migration picklist value configuration.

Knowledge base articles in Plumsail are SharePoint list items or pages inside the HelpDesk site. We map article titles, content, and category associations. Rich text formatting migrates as Salesforce Knowledge article body; embedded media requires separate ContentDocument migration. Formatting differences between SharePoint rich text and Salesforce Knowledge HTML may require post-migration content review. Articles that reference SharePoint-specific content (images stored in the Plumsail document library) require those assets to be migrated separately before article import.

Plumsail SLA rules define response and resolution time targets by priority or ticket type. We map SLA configurations as Entitlement Process definitions and First Response/Resolution Milestones in Salesforce. Destination SLA enforcement requires the customer's admin to link Cases to an Entitlement record during migration or post-migration. SLA configurations that use Power Automate flows to enforce deadlines (rather than native Plumsail SLA enforcement) are documented as automation rebuild items.

Plumsail Triggers are Power Automate flows stored on the SharePoint site. They are not exportable as data — they are configuration tied to the Plumsail solution's internal triggers and actions. We inventory every active trigger during discovery, document its trigger conditions and actions, and deliver a runbook for rebuilding each trigger as a Salesforce Flow. We do not migrate trigger code. SLA-based triggers that send email on deadline are included in the SLA documentation output.

File attachments on tickets are stored in SharePoint document libraries linked to ticket items. We extract attachment files and their Plumsail ticket associations, then upload them as Salesforce ContentVersion records. Each ContentVersion is linked to the parent Case via ContentDocumentLink. Large attachment volumes can stress SharePoint API limits during read; we pace attachment extraction and chunk Salesforce uploads to avoid blob-size failures.