Will my Connect Field Service workflows and scheduling policies migrate to Salesforce Flow?

No. FlitStack AI migrates data and schema only — Power Automate workflows built inside Dynamics 365, CFS scheduling policies, optimization recipes, and territory management rules do not transfer to Salesforce. They use incompatible action models: CFS workflows execute against Dynamics 365 entities; Salesforce Flow executes against Salesforce objects. We deliver a Scheduling and Territory Configuration Checklist as part of every migration package, itemizing every CFS scheduling policy and territory so your Salesforce admin can rebuild them in Salesforce Flow or the Field Service add-on. Scheduling policy logic (first-available technician, skill matching, travel-time optimization) requires manual rebuild — no automated translation exists between the two scheduling engines.

What does a Connect Field Service Work Order become in Salesforce?

A Connect Field Service Work Order maps to a Salesforce Case record. The CFS work order name becomes Case Subject; description, priority, and status map to the corresponding Case fields. The customer account reference (msdyn_serviceaccount) resolves to Case AccountId. Scheduled start and end times, along with FSM-specific fields like service territory and work order type, migrate to custom fields on the Case object because Salesforce's standard Case has no native fields for field service scheduling data. Work Order line items with a product or billing component map to Salesforce OpportunityLineItem records linked to an Opportunity — your team decides whether to create Opportunities from CFS Work Order amounts or treat Cases as service-of-record only.

Can I migrate Connect Field Service custom fields and custom entities to Salesforce?

Yes. Any custom properties on Connect Field Service Work Orders, Service Appointments, or Assets migrate as custom fields on the corresponding Salesforce object. We generate a custom field creation plan specifying the field API name, data type (text, pick-list, number, datetime), and whether the field needs a value-mapping table for pick-list alignment. Custom entities in Connect Field Service — such as custom lookup tables or extended objects — map to Salesforce custom objects. Custom entities with many-to-many relationships to Work Orders or Assets require a Salesforce junction object, which we surface in the mapping plan before the migration run so your admin can pre-create the object in Salesforce.

How are Connect Field Service Asset hierarchies handled in Salesforce?

Connect Field Service asset hierarchies — a parent installed product (such as an HVAC system) with child components (compressors, filters, sensors) — map to Salesforce's Asset object using the ParentId field. The hierarchy loads top-down: top-level assets migrate first so their Salesforce IDs are available as ParentId values for child assets. Any circular references (an asset that references itself or creates a loop) are flagged and excluded from the load. The installed date, product reference, and status of each asset migrate to the corresponding Salesforce Asset fields. Asset relationships from CFS (replacement or upgrade type) map to Salesforce Asset Relationship records.

Does the migration affect my Connect Field Service account during cutover?

No. FlitStack AI connects to Connect Field Service using scoped read-only API permissions — your team continues working in Dynamics 365 throughout the migration. The extraction phase reads records without modifying them. During the cutover window, a delta-pickup pass captures any Work Orders, Service Appointments, or Asset records created or modified after the initial extraction so Salesforce reflects the complete final state of your Connect Field Service data at go-live. The delta window typically runs 24–48 hours depending on your team's cutover schedule. No changes are made to your Connect Field Service data at any point.

Why do Connect Field Service migrations often cost more than standard CRM migrations?

Connect Field Service to Salesforce migrations carry higher scope than typical CRM pairs because the FSM layer — asset hierarchies, Work Order line items, service territories, and scheduling data — requires more custom field creation in Salesforce than a standard contact/company migration. Each CFS custom property on a Work Order or Service Appointment needs a corresponding Salesforce custom field before validation passes. Asset hierarchies need parent-before-child loading sequencing and circular-reference detection. Work Order status and priority pick-lists must be value-mapped against your specific Salesforce Case pick-list configuration. The added custom field count and validation complexity push the price into the upper half of the $500–$3,800 range, particularly when the CFS instance has more than 20 custom fields on Work Order or multiple active service territories.

Connect Field Service to Salesforce Sales Cloud Migration — Field-Level Mapping & Rollback

Overview

What this migration involves

Connect Field Service (Microsoft Dynamics 365 Connected Field Service) is a field service management platform built around Work Orders, Service Appointments, Bookings, and a resource-and-territory scheduling model. Salesforce Sales Cloud is a CRM centered on Leads, Accounts, Contacts, Opportunities, and Cases. The two platforms share a relational object model — Accounts map to Connect Field Service's customer accounts, and Work Orders map to Salesforce Cases — but the FSM-specific layer (service territories, scheduling policies, work order line items, and asset hierarchies) requires custom field creation and a value-mapping pass for status and priority pick-list values. FlitStack AI extracts Connect Field Service data via the Dynamics 365 API, transforms Work Order and Service Appointment records into Salesforce Case and Task objects, and maps asset hierarchies into the Salesforce Asset object with ParentId chains intact. We preserve original Work Order create dates as a custom datetime field because Salesforce's CreatedDate reflects migration time. Connect Field Service resources resolve to Salesforce Users by email match; unmatched resources land under a designated fallback owner and are flagged for admin review. What does not migrate: Connect Field Service scheduling policies, FSM territory management, booking optimization rules, and any Power Automate workflows built inside Dynamics 365. Those require a separate rebuild project in Salesforce — we deliver an FSM configuration checklist as part of every migration so your admin knows exactly what to set up post-migration. Automation logic does not transfer between platforms because the underlying action models are incompatible.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Object mapping

How Connect Field Service objects map to Salesforce Sales Cloud

Each row shows how a Connect Field Service object lands in Salesforce Sales Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

Connect Field Service

Account (Connect Field Service)

maps to

Salesforce Sales Cloud

Account

1:1

Fully supported

Direct map. Connect Field Service customer accounts map to Salesforce Accounts by name, using case‑insensitive matching; duplicate account names are flagged for admin review. Address, phone, and industry fields map field‑by‑field, and any missing required fields trigger a pre‑load validation report. Parent‑child account hierarchies in Connect Field Service translate to Salesforce's ParentId chain, so the top‑level account must load before its child accounts to satisfy foreign‑key constraints.

Connect Field Service

Contact (Connect Field Service)

maps to

Salesforce Sales Cloud

Contact

1:1

Fully supported

Direct map. Field technicians, dispatchers, and customer contacts migrate to Salesforce Contacts linked to their Account, using email address as the primary match key. Duplicate contacts with the same email are flagged for admin resolution, and any missing required fields (such as LastName or AccountId) generate a pre‑load validation report. Because each Contact requires an AccountId, the parent Account must be loaded first so foreign‑key references resolve correctly during the load.

Connect Field Service

Work Order

maps to

Salesforce Sales Cloud

Case

1:1

Fully supported

Work Order maps to Salesforce Case as the primary service record. CFS-specific Work Order fields (priority, status, description, address) map to Case fields. FSM-specific fields — scheduling policy reference, service territory, and assigned resource — become custom fields on Case because Salesforce's standard Case object has no native territory or resource-assignment fields.

Connect Field Service

Work Order

maps to

Salesforce Sales Cloud

Opportunity

1:1

Fully supported

Connect Field Service Work Orders with a revenue component do not map to Salesforce Opportunity without business logic — revenue-bearing work orders require your team to decide whether to create Opportunities from Work Order amounts or treat Case records as the service-of-record only.

Connect Field Service

Service Appointment

maps to

Salesforce Sales Cloud

Task

1:1

Fully supported

Connect Field Service Service Appointments map to Salesforce Tasks. Scheduled Start and End times from CFS become custom datetime fields on the Task because Salesforce Tasks store a single DueDate field. Appointment status (Scheduled, In Progress, Completed) maps via value mapping to Salesforce Task Status.

Connect Field Service

Asset

maps to

Salesforce Sales Cloud

Asset

1:1

Fully supported

Direct map. Connect Field Service assets (installed products at customer locations) map to Salesforce Asset using the asset name as a matching key. Parent‑child hierarchies translate to Salesforce Asset.ParentId links, so top‑level assets load first to generate IDs for children; missing ParentId triggers a validation error. AccountId on each Asset links to customer's Salesforce Account, and assets without a matching Account are flagged for admin review before the load.

Connect Field Service

Work Order Product (Line Item)

maps to

Salesforce Sales Cloud

OpportunityLineItem

1:1

Fully supported

Work Order Line Items map to OpportunityLineItems when the Work Order has a revenue or product component. Requires a Salesforce Pricebook2 to be active before line items can load — PricebookEntryId is mandatory on every OpportunityLineItem. Quantity and UnitPrice from CFS map directly; product lookup resolves via product name match.

Connect Field Service

Bookings (Resource Scheduling)

maps to

Salesforce Sales Cloud

Custom Field on Case

1:1

Fully supported

Connect Field Service Bookings record which technician is assigned to which work order at which time. Salesforce Sales Cloud has no native booking object — this data migrates as custom fields on the Case (Assigned_Technician__c, Booking_Start__c, Booking_End__c). Scheduling visualization requires Salesforce Field Service add-on or a third-party app.

Connect Field Service

Service Territory

maps to

Salesforce Sales Cloud

Custom Field on Case + Salesforce Territory (if enabled)

1:1

Fully supported

Connect Field Service service territories define geographic dispatch zones. Salesforce Sales Cloud standard does not include Territory management — territory names migrate as a custom pick-list on Case (Service_Territory__c). Full territory-based routing requires Salesforce Territory Management or Field Service add-on.

Connect Field Service

Resource / Technician

maps to

Salesforce Sales Cloud

User

1:1

Fully supported

Connect Field Service Resources (technicians and dispatchers) resolve to Salesforce Users by email match. CFS Resources without a matching Salesforce User email are assigned to a designated fallback User and flagged. Salesforce User records must exist before Work Orders and Bookings can link to OwnerId.

Connect Field Service

Custom Field on Work Order

maps to

Salesforce Sales Cloud

Custom Field on Case (__c)

1:1

Fully supported

Any Connect Field Service custom properties on Work Order require a corresponding custom field on Salesforce Case. We generate a custom field creation plan before the migration run so Salesforce-side schema is ready for validation. Custom pick-list fields on CFS need value-by-value mapping to Salesforce pick-list options.

Connect Field Service

Agreement / Contract

maps to

Salesforce Sales Cloud

Contract

1:1

Fully supported

Connect Field Service service agreements and SLAs map to Salesforce Contract linked to the Account, using the agreement name as the match key. Contract start and end dates, status, and description migrate directly; any missing fields (such as Contract Type or ActivationDate) are flagged before the load. CFS agreement line items translate to Salesforce Contract Line Items, each requiring a ContractId and a valid Product2 record to pass validation.

Connect Field Service	Salesforce Sales Cloud	Compatibility
Account (Connect Field Service)	Account1:1	Fully supported
Contact (Connect Field Service)	Contact1:1	Fully supported
Work Order	Case1:1	Fully supported
Work Order	Opportunity1:1	Fully supported
Service Appointment	Task1:1	Fully supported
Asset	Asset1:1	Fully supported
Work Order Product (Line Item)	OpportunityLineItem1:1	Fully supported
Bookings (Resource Scheduling)	Custom Field on Case1:1	Fully supported
Service Territory	Custom Field on Case + Salesforce Territory (if enabled)1:1	Fully supported
Resource / Technician	User1:1	Fully supported
Custom Field on Work Order	Custom Field on Case (__c)1:1	Fully supported
Agreement / Contract	Contract1:1	Fully supported

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

Connect Field Service gotchas

High

Per-seat licensing applies to dispatchers, technicians, and often read-only users

High

Custom fields and non-standard objects require explicit mapping before migration

Medium

Offline sync state is not persistently exported via standard API

Medium

Scheduling optimization rules and territory logic do not transfer between platforms

Salesforce Sales Cloud gotchas

High

Workflow Rules and Process Builder are retired

High

Bulk API batch quota exhaustion during large imports

Medium

Storage overage billing is non-obvious

Medium

Account-Contact many-to-many relationship mapping

Low

Territory and team member import ordering dependencies

Connect Field Service gotchas		Salesforce Sales Cloud gotchas
Severity	Issue	Severity	Issue
High	Per-seat licensing applies to dispatchers, technicians, and often read-only users	High	Workflow Rules and Process Builder are retired
High	Custom fields and non-standard objects require explicit mapping before migration	High	Bulk API batch quota exhaustion during large imports
Medium	Offline sync state is not persistently exported via standard API	Medium	Storage overage billing is non-obvious
Medium	Scheduling optimization rules and territory logic do not transfer between platforms	Medium	Account-Contact many-to-many relationship mapping
		Low	Territory and team member import ordering dependencies

Pair-specific challenges

Work Order FSM fields have no Salesforce standard equivalent

Connect Field Service Work Orders carry fields specific to field service management — service territory, scheduling policy reference, work order type, and billing type — that have no corresponding standard field on the Salesforce Case object. Salesforce's native Case supports priority, status, and origin, but not territory-based routing or FSM work order type. We map FSM-specific fields to custom fields on Case (Service_Territory__c, Work_Order_Type__c, Scheduling_Policy__c). Your Salesforce admin must create these custom fields before the migration load validates. Failing to pre-create them results in validation errors that halt the migration run until schema is corrected.
Resource-to-User resolution requires existing Salesforce users

Connect Field Service Resources (technicians and dispatchers) do not automatically become Salesforce Users — they are a different entity type in the Dynamics 365 data model. FlitStack AI resolves Resources to Salesforce Users by matching the email address on the CFS Resource record to an existing Salesforce User.email address. If a CFS Resource has no matching Salesforce User, their Work Order assignments land under a designated fallback User and the record is flagged. Your team must create Salesforce User accounts for all active technicians before the migration run or accept fallback owner assignment for unresolved Resources.
Asset hierarchy requires parent-before-child loading order

Connect Field Service assets support parent-child hierarchies — a parent asset (such as an HVAC system) with child components (compressors, filters). Salesforce Asset also uses a ParentId field for hierarchy. The migration must load top-level assets before child assets so the ParentId foreign key resolves correctly on load. Circular references in the CFS asset hierarchy (an asset that is its own ancestor) will be flagged and excluded from the load with a list of affected records so your admin can resolve the data quality issue before re-running.
Work Order status and priority pick-list values must be pre-aligned

Connect Field Service uses its own pick-list values for Work Order status (Open, In Progress, On Hold, Closed, Canceled) and priority (Low, Normal, High, Critical). Salesforce Case has separate pick-list values that your org's admin configures independently. If the two sets do not match, a Work Order with CFS status 'In Progress' could land as an invalid pick-list value in Salesforce and fail the record load. FlitStack AI generates a value-mapping specification before the migration and maps each CFS value to the corresponding Salesforce value — but your admin must confirm the Salesforce Case Status and Priority pick-lists are populated with the mapped values in Setup before the run.
Scheduling policies and territory management require a separate rebuild

Connect Field Service includes scheduling policies, optimization recipes, and service territories that govern how work is dispatched to technicians. Salesforce Sales Cloud standard edition does not include these features — they live in the Salesforce Field Service add-on. The scheduling policy logic, optimization rules, and territory boundaries stored in Connect Field Service have no Salesforce equivalent that a migration tool can carry over. FlitStack AI migrates the territory names as a custom field on Case so the geographic context is preserved, but the scheduling automation must be rebuilt using Salesforce Flow or the Field Service add-on post-migration.

Migration approach

Six steps for a successful Connect Field Service to Salesforce Sales Cloud data migration

Extract Connect Field Service data via Dynamics 365 API

FlitStack AI connects to your Connect Field Service instance using the Dynamics 365 Web API with read-only permissions. We extract Accounts, Contacts, Work Orders, Service Appointments, Assets, Work Order Products, Resources, and any custom entities. A pre-extraction data audit profiles record counts, identifies missing required fields, and surfaces duplicate Account records before transformation begins. API extraction uses pagination and rate-limit handling to avoid throttling your Dynamics 365 environment.
Build Salesforce schema: custom fields and pick-list alignment

Before data loads, FlitStack AI generates a Salesforce custom field creation plan covering every CFS field that has no direct Salesforce equivalent — Service_Territory__c, Work_Order_Type__c, Scheduling_Policy__c, Original_Create_Date__c, and Source_System_ID__c on Case, and Appointment_Start__c and Appointment_End__c on Task. Your Salesforce admin creates these fields using the provided API names and field types. We also deliver a value-mapping spreadsheet aligning CFS Work Order status and priority pick-list values to your Salesforce Case pick-list values so the load does not hit validation errors.
Resolve Connect Field Service Resources to Salesforce Users

FlitStack AI runs an email-match pass against your Salesforce User list for every CFS Resource record. Matched Resources link Work Orders to OwnerId on the Case record. Unmatched Resources are flagged in a pre-migration report with the CFS Resource name, email, and role. Your team either creates Salesforce User accounts for those technicians or designates a fallback User owner. No Work Order loads with an unresolved owner — Salesforce requires OwnerId to be a valid User ID.
Run sample migration with field-level diff

A representative slice — typically 100–500 records spanning Accounts, Contacts, Work Orders, Service Appointments, and Assets — migrates to a Salesforce sandbox first. FlitStack AI generates a field-level diff comparing source values against destination values so your team can verify that CFS status and priority pick-list values landed in the correct Salesforce pick-list options, that Asset.ParentId chains resolved correctly, and that Resource-to-User resolution covered the active technician roster. Approval of the sample diff triggers the full migration run.
Full migration run with delta-pickup window

The full data set loads into Salesforce with records sequenced to satisfy foreign key dependencies: Accounts → Contacts → Assets (top-down for hierarchy) → Work Orders → Service Appointments. A delta-pickup window of 24–48 hours captures any Connect Field Service records modified or created during the cutover window so Salesforce reflects the final CFS state at go-live. FlitStack AI generates an audit log of every record created or updated. One-click rollback reverts all migrated records if post-migration reconciliation reveals data integrity issues.

Platform deep dives

Context on both ends of the pair

Connect Field Service

Source

Strengths

Tightly coupled with major CRM backends like Salesforce and Dynamics 365 for unified customer records.
Mobile-first design with offline sync capability for technicians working in low-connectivity environments.
IoT and remote monitoring integration for predictive maintenance alerting.
Dynamic scheduling with territory-based routing and real-time dispatcher reassignment.
Multi-currency and multi-region support for organizations operating across geographic business units.

Weaknesses

Per-user license costs scale linearly with technician and dispatcher count, creating budget pressure during seasonal peaks.
Workflow and business rule configuration requires specialized admin expertise, increasing total cost of ownership.
Custom field and object development requires Salesforce DX or equivalent developer tooling, limiting declarative extensibility.
API rate limits and bulk API availability vary by edition, constraining automated migration throughput.
Offline data synchronization can produce conflicts that require manual resolution when technicians work in intermittent connectivity.

Salesforce Sales Cloud

Destination

Strengths

Largest enterprise app ecosystem in CRM with 5,000+ AppExchange integrations covering nearly every vertical workflow.
Native Einstein AI delivers lead scoring, opportunity insights, and predictive forecasting without a third-party layer.
Advanced territory management, multi-currency, and flexible forecasting satisfy complex B2B revenue structures.
Deep platform extensibility: Custom Objects, Apex, Flow, and the Metadata API allow full schema customization.
Well-documented REST API, Bulk API, and Composite API with published rate limits for programmatic migration.

Weaknesses

Pricing model is layered and opaque in practice: per-seat fees plus storage overages, add-on subscriptions, and annual uplifts compound to 30–40% above sticker price.
Workflow Rules and Process Builder are deprecated, forcing all orgs onto Salesforce Flow — a migration task that catches many teams by surprise.
Steep administrative complexity: meaningful configuration requires a dedicated Salesforce admin or consultant.
API rate limits are edition-gated (100k/day base for Enterprise) and easily exhausted by large historical imports without throttling.
Data export is exportable via Data Loader but preserving relationship integrity across 30+ objects requires careful ETL sequencing.

	Connect Field Service Source	Salesforce Sales Cloud Destination
Strengths	Tightly coupled with major CRM backends like Salesforce and Dynamics 365 for unified customer records. Mobile-first design with offline sync capability for technicians working in low-connectivity environments. IoT and remote monitoring integration for predictive maintenance alerting. Dynamic scheduling with territory-based routing and real-time dispatcher reassignment. Multi-currency and multi-region support for organizations operating across geographic business units.	Largest enterprise app ecosystem in CRM with 5,000+ AppExchange integrations covering nearly every vertical workflow. Native Einstein AI delivers lead scoring, opportunity insights, and predictive forecasting without a third-party layer. Advanced territory management, multi-currency, and flexible forecasting satisfy complex B2B revenue structures. Deep platform extensibility: Custom Objects, Apex, Flow, and the Metadata API allow full schema customization. Well-documented REST API, Bulk API, and Composite API with published rate limits for programmatic migration.
Weaknesses	Per-user license costs scale linearly with technician and dispatcher count, creating budget pressure during seasonal peaks. Workflow and business rule configuration requires specialized admin expertise, increasing total cost of ownership. Custom field and object development requires Salesforce DX or equivalent developer tooling, limiting declarative extensibility. API rate limits and bulk API availability vary by edition, constraining automated migration throughput. Offline data synchronization can produce conflicts that require manual resolution when technicians work in intermittent connectivity.	Pricing model is layered and opaque in practice: per-seat fees plus storage overages, add-on subscriptions, and annual uplifts compound to 30–40% above sticker price. Workflow Rules and Process Builder are deprecated, forcing all orgs onto Salesforce Flow — a migration task that catches many teams by surprise. Steep administrative complexity: meaningful configuration requires a dedicated Salesforce admin or consultant. API rate limits are edition-gated (100k/day base for Enterprise) and easily exhausted by large historical imports without throttling. Data export is exportable via Data Loader but preserving relationship integrity across 30+ objects requires careful ETL sequencing.

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

Migrate from Connect Field Service to Salesforce Sales Cloud

What this migration involves

Field-level fidelity

Schema-aware mapping

Relationships preserved

Full activity history

Attachments & notes

Two sides of the same decision