Migrate from Field Squared to Microsoft Dynamics 365 Sales

Field Squared Organizations (company-level records) map 1:1 to Dynamics 365 Accounts. Company name maps to Account.Name, main phone to Telephone1, website to Website. Original create and modify timestamps from Field Squared are preserved as custom datetime fields on the Account record.

Field Squared Contacts map directly to Dynamics 365 Contacts. First name, last name, email, job title, phone, and mobile phone map to their Dynamics 365 equivalents. The parent AccountId is resolved via the linked Organization, which has already been migrated to Account.

Field Squared Tasks are the core work-order entity. Dynamics 365 Sales has no native work-order equivalent, so FlitStack provisions a custom WorkOrder__c table on Dataverse with columns for TaskName (WorkOrderNumber__c), Status__c, ScheduledStart__c, ScheduledEnd__c, TaskType__c, Priority__c, EstimatedDuration__c, ActualDuration__c, Description__c, and original create/modify timestamps.

Field Squared's flexible custom field engine stores FSM-specific properties per task (e.g., parts used, service type, customer sign-off). These map to named columns on the custom WorkOrder__c table. Pick-list values from Field Squared require explicit value-mapping to Dynamics 365 option-set values during migration.

Field Squared Documents (attachments, images, service reports) re-upload as Dynamics 365 Notes (Annotation). Original filenames, MIME types, and creation timestamps are preserved. Notes are linked to the parent WorkOrder__c record or Account/Contact based on the original document's association in Field Squared.

Field Squared Organizations can have unlimited addresses (billing, service site, warehouse). Dynamics 365 Accounts support a single address composite. The primary or most-recently-modified address becomes Account.Address; additional addresses are stored as a custom Location__c table with a relationship to Account, or as a JSON custom field if the team prefers minimal schema changes.

Field Squared Contacts linked to Organizations without an active service relationship are evaluated as Prospects. These route to Dynamics 365 Leads with the original Organization name mapped to Company Name on Lead and the contact's email and phone preserved. Active service contacts land as Dynamics 365 Contacts under the migrated Account.

Field Squared Users with field-service roles (Technician, Dispatcher) are resolved by email match against existing Dynamics 365 SystemUser records. Matched users become Task and WorkOrder owners in Dynamics 365. Unmatched users are flagged before migration; your team either provisions their Dynamics user account or assigns their records to a fallback owner.

Field Squared Assets (equipment under service contracts) have no native Dynamics 365 Sales equivalent. We preserve Asset data as a custom Asset__c table linked to the parent Account, capturing asset ID, type, serial number, status, installation location, and linked Customer Contact. An alternative maps assets to the Product entity if your team prefers a catalog-style approach.

Field Squared Organization custom fields (e.g., contract tier, service-level agreement, billing model) map to custom columns on the Account record. Pick-list values require explicit value-mapping; multi-select values are stored as delimited text in a custom field pending Dynamics 365's multi-select option-set support.

Field Squared Contact custom fields (e.g., certifications, dispatch preferences, home depot) map to custom columns on the Dynamics 365 Contact record. Field types are preserved: date fields map to Date fields, number fields to Number fields, and pick-lists to OptionSet values.

Field Squared task status values (Not Started, In Progress, Completed, Cancelled, On Hold) map one‑to‑one to the WorkOrder__c.Status__c option‑set in Dynamics 365. During schema setup, FlitStack creates the option‑set entries and populates a mapping table so each source status resolves to the correct Dynamics 365 label. Custom or non‑standard statuses are flagged for value‑mapping before migration; unmapped statuses are logged as warnings and can be adjusted in the mapping table prior to run.