What do you like best about Dynamics 365 Field Service?
Dynamics 365 Field Server (FS) allows for very flexible deployment of service contracts, having all of the features of the D365 CRM solution, with FS concepts like agreements, work orders, tasks, etc., built in. Like all of D365, most "core" entities like tasks, accounts, users, teams, etc., can be flexibly associated to each other, and work flows built around that.
Also, as a data analysis lead, having the built-in and user-configured possible associations among entities makes automating and converting the data into a more traditional relational structure much easier than having to manually code the ETL.
The metadata tables describing possible statuses, substatuses and associations with entities are very systematic-even reporting the ROLE of each side of an association. If you wanted, you could entirely automate a graph database ETL just from careful intake of the metadata tables (which would eliminate the problem reported in the "dislike" section that many entities have over 100 (mostly unused in most implementations) fields that are null if unused. Review collected by and hosted on G2.com.
What do you dislike about Dynamics 365 Field Service?
The thing that makes D365 FS (and D365 in general) is that the underlying data model is extremely hard to manage outside of the tools offered by Microsoft. It takes quite an effort to set up data duplication into a database accessible via traditional SQL (even SQL Server). Once the data is there, you are confronted with each entity having EVERY POSSIBLE field that could be used. Core entities like "account", "contact", "task", etc. have over 100 fields each. The column order is seemingly random: user-configured fields are shuffled among the built-ins. Luckily the API-available metadata is available - allowing the construction of automated conversion tools to make the extracted data contain only fields in use - sorted in a manner that is more manageable.
The above comment is applicable to ALL D365 solutions, not just FS. FS has two key concepts that are missing, which seem like they would be part of any CRM->FS solution:
1. Lack of a concept of a unified account "status" or "pipeline": in D365. "leads" which are closed create "opportunities", which in FS turn into "agreements" to which one or more "work orders" can be associated. There is not a unified place, other than back links to the previous step, to understand at what date a particular agreeement for an account (either of which may not be created until after the lead is closed) was a lead, when the lead closed and created an opportunity, which then turned into an agreement, etc. If you want to build a pipeline report (even in the built-in GUI, but also in SQL) you have to manually create joins that follow the links. It is also possible for the front end to create entities later in the process without the previous step (an agreement may exist without an opportunity which created it, for example). When used to understand close rates, cost of customer/account acquisition, lifetime value of a customer, etc., it is super challenging.
2. The FS-specific entities "agreement" and "work order" were, I believe, implemented initially by another solutions provider then purchased and added in. (They are named "msdyn_account" and "msdyn_workorder - that previx convention applies also to new entities/fields added by implementers). Thus, the "status/substatus" of these two entities are handled very differently - in all other D365 built ins, there are two metadata fields denoting entity "status": current/active, inactive, etc. and "substatus": "new", "open", "wip", "closed", etc. In agreements and workorders, those fields exist, but the actual user-configurable fields that denote the same meaning are in additional entity tables with GUIDs for keys instead of integers.
It's another thing to work around.
These two, and the absolute requirement common to all configuration or no/low code implementation environments to work within the paradigm of the tool rather than imposing your process onto it are probably the hardest things to overcome.
That being said, the fact you can DIRECTLY query for all legal associations among entities and statuses in the metadata tables makes this a tractable problem. Review collected by and hosted on G2.com.
