Migrate from FieldFX to Microsoft Dynamics 365 Sales

FieldFX uses standard Salesforce Account objects to store company data — Name, Industry, AnnualRevenue, and NumberOfEmployees are among the fields that map directly to D365 Account attributes. Industry pick-list values require value-by-value mapping since D365 ships with its own industry taxonomy. Parent-account hierarchies (if configured) map to the D365 Parent Account lookup.

FieldFX stores contact records on standard Salesforce Contact with name, email, phone, and address fields. These map directly to D365 Contact attributes using the same field semantics. Any FieldFX-specific contact properties — technician role, certification flags — migrate as custom fields on the D365 Contact table. Original create dates from Salesforce CreatedDate are preserved as a custom datetime field.

D365 Sales has no native ticket equivalent. FieldFX Ticket records migrate to a custom Dataverse Case table pre-created by your admin (or by FlitStack as part of the schema setup plan). The custom table must exist before migration so foreign-key lookups can resolve. Ticket status values map as option-set integers on the custom case table — a mismatch in integer values causes incorrect status display.

FieldFX Work Order is a primary custom object with a parent Ticket lookup, work-type classification, and a set of actual and estimated fields. D365 Sales ships no Work Order entity. We map this to a custom Dataverse table named to match your FSM naming convention, pre-created before migration. Work Order Line Items require a separate junction table in Dataverse because D365 has no built-in order-detail entity.

FieldFX Work Order Line Items store parts, labor, and travel line types with quantity, unit price, cost, and duration. Each line has a master-detail relationship to Work Order. D365 Sales has no equivalent — we map this to a custom Dataverse junction table with lookup columns to the custom Work Order table and to the Contact or Account for service-resource assignment.

FieldFX Ticket Line Items store the line-level detail of each service event — description, quantity, work type, pricing, and labor hours. D365 Sales has no Case Product or equivalent for ticket-level line items. We model this as a custom Dataverse table with a lookup to the custom FSM case table, preserving the parent-child hierarchy from FieldFX.

FieldFX creates Salesforce Tasks for service-call log entries, follow-up actions, and dispatch communications. These map directly to D365 Task records. Original timestamps, subject, and owner fields carry over. Uncompleted tasks retain their status as open items in D365 for your team to action after cutover.

FieldFX file attachments on tickets and work orders (such as signatures, photos, or PDF reports) re-upload to D365 Notes with an attachment lookup to the target custom FSM table. Salesforce Files are downloaded and re-uploaded to D365 SharePoint-connected or Dataverse file storage. File size limits from D365 apply — files over 32 MB require chunked upload handling.

FieldFX EAM, Schedule & Dispatch, and Timecards modules introduce additional custom objects beyond core FSM tickets and work orders. Each module's custom objects map to custom Dataverse tables. Your admin decides which module objects to carry over — assets from EAM may map to D365 Field Service Customer Assets if the Field Service module is licensed. Non-FSM module objects are candidates for archival or exclusion.

FieldFX user records exist in Salesforce as Users with assigned profiles and permission sets. Owner resolution maps by email — each Salesforce User email is matched against a D365 SystemUser record. Unmatched owners are flagged before migration so your team either creates the D365 user first or assigns records to a fallback owner. Role hierarchies from FieldFX do not migrate and must be re-established in D365 security roles.