Migrate from ServiceNow Field Service Management to Pipedrive

ServiceNow work orders map directly to Pipedrive deals. The work order number becomes a custom field (Work_Order_Number__c) for traceability. Pipeline stages in Pipedrive are configured to reflect FSM work-order states: Open, Scheduled, In Progress, Completed, Cancelled. Original dispatch assignment and priority level migrate as custom fields on the deal.

Each FSM work order task becomes a Pipedrive activity linked to the target deal. Task type (Repair, Installation, Inspection) is stored in a custom deal field. Completed task timestamps and technician comments become the activity body. Tasks without a parent work order are linked to the nearest matched deal by reference number.

Dispatcher workspace assignments (which ServiceNow resolves using skill-based routing rules) do not have a Pipedrive equivalent. We preserve dispatcher name and assignment timestamp as custom text fields on the deal. Routing logic itself cannot migrate and must be reconstructed as Pipedrive workflow triggers if needed.

Technicians with active Pipedrive user accounts are matched by email and resolved to User records. Technicians without Pipedrive accounts are migrated as Person records with a Technician_Role__c custom field set to 'Field Agent'. Multiple role assignments in ServiceNow collapse to the primary role for Pipedrive assignment mapping.

ServiceNow customer records — whether stored in the Account table or as business entity CIs — map to Pipedrive organizations. Primary contact, address, phone, and industry fields migrate as direct matches. Multi-site location hierarchies in ServiceNow (parent/child locations) are stored as a custom organization field (Parent_Location__c) in Pipedrive.

ServiceNow locations (street address, lat/long coordinates, location type) are mapped to organization custom fields: Location_Address__c, Location_Latitude__c, Location_Longitude__c. If a work order references a specific site, the address fields on the linked organization record are populated from that location. Pipedrive's geo‑enrichment can add missing coordinates after migration, but it does not create a separate location object; the data remains embedded in the organization record.

ServiceNow asset records attached to work orders are mapped to organization custom fields (Primary_Asset__c, Asset_Serial__c, Asset_Model__c). Pipedrive has no native asset registry; only the primary asset linked to the most recent work order is migrated per organization. Full CI history requires export as a separate reference document.

Files attached to ServiceNow work orders (photos, signed forms, inspection reports) are downloaded and re-uploaded to the corresponding Pipedrive deal as deal attachments. File size limits in Pipedrive (default 75 MB per file) are enforced during transfer. Inline images in work order notes are extracted and stored as separate deal attachments.

ServiceNow state flows (e.g., Open → Assigned → In Progress → Pending Parts → Closed) are mapped to Pipedrive pipeline stage values. State flow transition rules encoded in ServiceNow's Flow Designer have no Pipedrive equivalent and must be rebuilt as Pipedrive Automations after migration. We deliver a state-to-stage mapping table as part of the migration plan.

ServiceNow SLA timers and SLA agreements attached to work orders do not have a Pipedrive equivalent. SLA target timestamps and breach status are preserved as custom datetime fields (SLA_Target__c, SLA_Breached__c) on the deal. SLA breach logic must be rebuilt in Pipedrive through custom automation if compliance reporting is required.

If the FSM deployment also uses ServiceNow Customer Service Management for case intake, those cases can be mapped to Pipedrive deals using the same work-order-to-deal logic. Case origin (phone, email, portal) is preserved as a custom field (Case_Origin__c). Cases without linked work orders are treated as open deals in the initial pipeline stage.

ServiceNow knowledge articles linked to work orders are exported as notes on the corresponding Pipedrive deal. The article title and a truncated summary are stored in the note body; the full article URL is preserved as a link. Knowledge-base structure and versioning do not migrate — articles must be recreated in a knowledge tool outside Pipedrive.

Parts used and inventory reservations on ServiceNow work orders do not have a Pipedrive equivalent. Part names and quantities are preserved as a text custom field (Parts_Used__c) on the deal. Inventory management must remain in a separate inventory system post-migration; Pipedrive Products can be linked to deals for part tracking if the Products module is activated.

Every migrated record stores its ServiceNow sys_id in a custom field (Source_System_ID__c) for traceability, de-duplication during delta runs, and cross-referencing in the ServiceNow export log. The sys_id is preserved as a 32-character string in the format [instance_hash]-[record_hash] for reconstruction reference.