1:00:27 Min. From Microsoft Business Applications Summit 2019.
The main process for Field Service spans the following entities, more or less also in this order:
- Work Order
- Work Order Incidents
- Customer Assets
- Resource Requirements
- Resource Bookings
There are over a hundred other entities around that involved in the core Field Service processes which provide additional functionality.
AddOns and extensibility solutions for D365 Field Service
Also there are plenty of Add Ons available that can extend the core Field Service functionality, like:
- Field Service Mobile
- Connected Field Service (now part of the core Field Service Solution)
- Field Service (Partner) Portal
- Data Integrator Templates
- Microsoft Forms Pro
- Azure IoT Hub
- Azure IoT Central
- Azure Stream Analytics
- Azure Machine Learning
- Azure Digital Twins
- Dynamics 365 Remote Assist (for Hololens and Andoid Mobile Phone)
- Microsoft Hololens
- Dynamics 365 Product Visualize
- Dynamics 365 Guides (3D instructions for Field Service Engineers)
- Dynamics 365 Layout
- Microsoft Intune (Mobile Device Management / Mobile Application Management)
If you’re going to enable another (custom or OOB) entity for scheduling there is a great blog series from Sara Lagerquist (see links below) which has some good tips. Based on these tips I’m listing up some of the most valuable insights when it comes to extend URS functionality when you Enable Resource Scheduling for Entities.
- don’t create new relationships from within the “Enable Scheduling” setup wizard as they won’t contain your custom prefix in their technical relationship names
- think about doing a more sophisticated field mapping by Workflow instead of only using the static field mapping from the wizard
- also take into account to leverage the standard field mappings for the newly created relationships to pass on additional parameters which are not exposed as fields in the wizard
- don’t forget to maybe auto create Resource Requirements by another Workflow
- also you maybe want to auto-populate Resource Requirement Skills / Characteristics for your new Resource Requirements
- for only a limited number of Characteristics you might want to create several new Lookup fields on your newly schedulable entity to the Characteristic entity
- for a larger number of Characteristics you could use Microsoft Flow to populate them into your Requirement Characteristic entity. Source for this Characteristics list to be picked up by Flow could be a new sub-entity from your newly schedulable entity (NewSchedulableEntity 1:n NewSchedulableEntity.Characteristics). If you want to make Service Tasks schedulable you could alternatively use the Service Task Type and place a new Subgrid “Service Task Type Caracteristics” there.
Sources & more information:
Find and use pictures also for commercial use and without the need to mention the source:
Create Artificial Intelligence solutions without developer know how.
Introducing AI Builder for Power Platform (by Charles Lamanna)
- leverage AI and machine learning
- supports PowerApps and Flow
- can be extended by professional developers (pro devs)
Capabilities & use cases:
- form processing
- object detection
- text and binary classification
- analyze and automatically respond to customer feedback
- business card reader
Inspired by this blog article from Karuna Karan I activated the new auto numbering for field service in a new trial organisation.
This is done by going to Field Service Settings and than click a ribbon button “Opt-In to Auto-Numbering”:
You than are than getting this warning dialog from Microsoft:
Opt-In to Auto-Numbering
By proceeding you will be opting-in to an improved implementation of Auto-Numbering utilized by several Field Service entities.
- Guaranteed unique record naming.
- Fewer gaps in the names of affected entities since the name of the record is not generated until after a user creates it.
- Starting number for names can be changed to a smaller number should the maximum number be reached.
- Number length for names can be specified on a per entity basis.
- The Auto-Number name will only be assigned after the record is saved.
- Configuring each name’s format will be managed in a dialog.
- When importing an entity as a separate solution from one organization to another, the Auto-Numbering format definition for the entity will be carried across as part of the solution.
- Once opted-in, reverting back to the legacy implementation of Auto-Numbering is not possible.
- While opting-in, creation of new records may fail. It is highly advised that opting-in take place while there is no activity on the organization. The process will take a few moments to complete.
After you confirm this warning to proceed, the former button turns into this one:
When using that new ribbon button a dialog opens:
and you can choose there between those entities for which you could already decide about auto number format before:
Yes, an easy way to exactly archive what Microsoft mentions in the confirmation dialog:
- guaranteed unique (biggest enhancement)
- fewer gaps between the numbers
- number length can be specified
- usage of not utilized numbers when switching to smaller starting position
So thank you Microsoft for that.
- as Karuna Karan mentioned in his blog, it is still difficult to reset the already used numbers
- it still has other format than the “old” auto numbers:
- we do already have other means by using web.powerapps.com to create auto numbers OOB in a much more flexible way and add them into our solution files:
- and we also have the XRMToolbox utility Auto Number Manager by Jonas Rapp for that (basically doing the same as the CDS field definition) already since 2017:
So you’re asking yourself a bit why for Field Service OOB auto numbers there seem to be only some “minor” enhancements whereas the overall auto numbering has made such huge progress.
Plugins vs. Workflows
Must read here: