Migrate from Fieldy to Microsoft Dynamics 365 Sales

D365 Sales Professional caps custom tables at 15 — complex Fieldy setups may need Enterprise

Fieldy FSM deployments with many custom fields on Jobs, Customers, and Quotes can exceed D365 Sales Professional's 15-table limit for custom entities. If your Fieldy setup uses more than 15 distinct custom-field groups, D365 will require either a Sales Enterprise license (unlimited custom tables) or a schema consolidation strategy before migration. We surface this during the pre-migration schema audit and advise on whether a table-refactor is needed before data moves. The Professional cap is a hard limit enforced by the Dataverse platform — exceeding it blocks the migration.

Fieldy workflows, dispatch rules, and quote-approval chains do not migrate to D365

Fieldy's job-scheduling automations, technician-dispatch rules, and multi-step quote-approval workflows are business-logic constructs stored in Fieldy's workflow engine — they have no equivalent in D365 Sales and cannot be carried over as data. Job-triggered reminders, status-change notifications, and routing logic must be rebuilt in D365 using Power Automate or the native Business Rules designer. FlitStack exports your Fieldy workflow definitions as a structured rebuild reference document that your D365 admin or consultant can use to reconstruct the logic in Power Automate cloud flows.

Invoice payment records and deposit tracking require a custom entity or D365 Finance integration

Fieldy stores invoice payment history, deposit amounts, and partial-payment records as native fields on the Invoice object. Dynamics 365 Sales Invoice entity tracks invoice status and totals but does not natively maintain accounts-receivable aging, deposit applied, or payment schedule data. We migrate payment status as a custom pick-list (Paid, Partial, Overdue) and the last payment date as a custom field. Full payment history, deposit tracking, and aged-receivables reporting require a custom Payments entity in Dataverse or integration with D365 Finance / Business Central — scoped separately from the core migration.

Technician and dispatcher roles need a role-resolution strategy before migration

Fieldy staff members (technicians, dispatchers, account managers) are People records with role metadata. In D365 Sales, every record has an OwnerId pointing to a licensed User — there is no native Staff or Technician object. We resolve Fieldy staff to D365 Users by email match. Staff without D365 user accounts are migrated as Contacts with a custom Role__c pick-list field (Technician, Dispatcher, Account Manager). Before migration, your team should decide which Fieldy staff need D365 user licenses versus Contact records — licensing costs differ significantly between the two approaches.

Multi-location customers create multiple address records that must be linked back to the parent Account

Fieldy allows a single Customer to have multiple service Locations, each with its own address and GPS coordinates. D365 Account stores a single primary billing address and a single shipping address natively. Multi-location customers from Fieldy require a site-address strategy: either multiple Account records (one per location, linked by a Parent Account hierarchy) or a custom Site custom entity in Dataverse with a lookup from the Work Order. We recommend the custom Site entity approach for most FSM-to-D365 migrations because it preserves the one-Account-per-customer D365 convention while keeping location data accessible on Work Orders.