Product documentation
In this topic the basic setup for Dynamics Advanced Field Service will be explained. In the Advanced Field Service app, the area Settings is available. Via this menu it is possible to access the different setup entities that are part of the Dynamics Advanced Field Service solution.
In the next paragraphs the Settings entities are described.
Advanced Field Service > Settings > General Settings
The parameters of Dynamics Advanced Field Service are explained here.
Microsoft Dynamics 365 Field Service Incident Types act as service templates that allow users to quickly create work orders for the most common types of jobs that an organization performs. Adding an incident type to a work order can provide details like duration, work order service tasks, products, services, and characteristics (skills). This means incident types effectively serve as work order templates that prepopulate information, which can be manually edited as needed.
However, an Incident Type in Microsoft Dynamics 365 Field Service is a generic setup entity and is not specifically related to the type of a customer asset which is linked to a work order. For example, if incident type Repair is being defined in the setup it will be impossible to specify defaults for all types of customer assets in this single incident type. Assume an organization services both copiers as well as airconditioning units then specific defaults such as spareparts or skills for both types in a single incident type will not be the best approach. The organization will most likely decide to define two incident types: one for Repair Copier and for Repair Airco each of them having their own specific defaults. Using this approach this might eventually even blow up the setup entity Incident Types, which might result in users getting confused and making more erros when trying to select the correct incident type.
In order to overcome this situation, Dynamics Advanced Field Service contains the functionality Customer Asset Type Dependent Incident Type Defaults. This functionality is based on entity Customer Asset Type which is is part of our solution as well and can be used to categorize customer assets. As in our example, above both customer asset type Copier as well as Airco could be the categorization of these type of customer assets.
In the standard entity Incident Types we have enabled the possibility to connect customer asset types to an incident type:
Once a customer asset type is linked to an incident type, the additional defaults can be defined specifically for the customer asset type by opening the details. This include defaults of products, services, service tasks and characteristics. Note that the estimated duration field works similar as in standard Field Service and is defaulted with the sum of the service tasks if they are present. If not, the estimated duration field can be filled in manually.
The functional purpose of Customer Asset Type Dependent Incident Type Defaults is explained here.
Advanced Field Service > Settings > Case Settings
The entities Complaint Code, Cause Code and Solution Code can be used in cases in order to identify a problem and its cause. When a case is resolved the solution for the problem can be entered.
The entity Service Category is intended to be used specifically for the case to work order integration. In standard Microsoft Dynamics 365 for Field Service this integration is limited to the field Incident Type.
A service category allows you to differentiate cases into different types as a preparation to convert a case to a work order. It is for example also possible to configure Business Process Flows that are related and triggered based on the selected service category of the case (i.e. if service category ‘Corrective Service’ is selected, it may trigger a different BPF as when ‘Installation’ is selected). Service categories can be linked to case incident types, which will be described in the next paragraph.
The entity Case Incident Type is intended to be used specifically for the case to work order integration. Via Service Category Case Incident Type, it is possible to define case incident types for a specific service category.
The intention of the entity Service Category Case Incident Type is the ability to default the standard field Incident Type on tab Field Service in the case form. Further, by using service categories and case incident types, users can not select incorrect incident types anymore. For example, it is not possible to select incident type ‘preventive maintenance’ if the service category is indicating a ‘corrective’ process. That is the reason why the lookup field for case incident type in the case form is depending on the selected service category. In the example below for the service category ‘Corrective Service’, two case incident types are allowed to be used in the case.
If the combination ‘Corrective Service’ and ‘Breakdown’ is selected in the case, two possible standard Field Service incident types may be used, of which incident type ‘Breakdown’ will be defaulted in the case.
In the case form in Dynamics Advanced Field Service, the standard Field Service Incident Type field is being defaulted via the selected service category and case incident type combination.
Advanced Field Service > Settings > Customer Asset Settings
The entity Customer Asset Group can be used to differentiate customer asset families, which is one level above customer asset types. For example, the group ‘Engines’ can be a relevant group level while the specific type of engine is a more detailed level and can be saved as a customer asset type. There are numerous purposes for using customer asset groups such as being able to report in Power BI for example which group of assets are having most repairs in a certain period.
Note
The entity Customer Asset Type can be used to differentiate specific customer assets defined in one customer asset group. For example, the type ‘Turbo Engine type X’ can be a relevant type to differentiate the group ‘Engines’ one level deeper than the group.
Note it is not mandatory to link a number sequence to a customer asset type. If left empty, the number sequence will fall back to the customer asset group number sequence.
There are numerous purposes for using customer asset types such as being able to report in Power BI for example which type of customer assets are costing more money while repairing then others of the same customer asset group.
The entity Customer Asset Status can be used to define your own statuses for a customer asset. The field has been added to the customer asset form and can be used for several purposes. There is no application logic connected to this field, it is purely for information purposes.
The entity Customer Asset Structure Template can be used to create pre-defined templates for customer asset structures that can be used in the customer asset structure designer.
The templates can be created and updated in a template designer via a drag & drop mechanism. Note that there is no history or version control on templates, once saved the change is effective immediately.
Active customer asset structure templates can be used in the customer asset structure designer. By dragging the template to the left section, the complete template structure will be exploded in the customer asset designer.
Entity to specify manufacturers that can be linked to customer asset types.
The entity Property Option Set can be used to create pre-defined option sets. An option set can be used for attribute values that are used more often. A good example is color values.
When the property option set itself is defined, it is also necessary to define the values of the property option set as well:
The entity Property Settings can be used to create pre-defined properties that can be linked to customer assets (and types). It is possible to define as many as properties as you like and there are seven different property types available:
In the entity Customer Asset Type a new sub grid Properties has been added. In this sub grid you can define which property settings are allowed to be used in a customer asset of that type.
The value Required results in the property being created automatically for the customer asset once the customer asset is created based on that type. Properties where this value is set to No are not created automatically but can be selected in the customer asset manually. Properties settings which are not linked to a customer asset type, cannot be selected in a customer asset. It is further possible to define a default value, which will be loaded to the customer asset property value as well.
In the details form of the property setting it is also possible to link the customer asset types for which this property is applicable:
The entity Warranty Category is required to define warranty terms. A warranty category can be linked to a product or service and is ‘Field Service Product Type’ dependent.
Further, the warranty category is used in the definition of the general customer warranty terms which are eventually loaded into the specific customer asset warranty terms.
Customer Warranty Terms is a setup entity where you can define your companies generic warranty terms. By using this entity there is no need to define customer asset warranty terms every time you create a customer asset. The generic setup entity can be used to load the terms into the specific customer asset warranty terms.
Via the Asset Selection field, terms can be defined for all customer assets, a specific customer asset type or a unique customer asset. Warranty Category, Warranty Period and Warranty Period Type need to be specified in order to define the length of the term and it is possible to set a valid from and valid to date. Via the field Warranty Discount % it is possible to define if a customer gets full warranty (100% discount) or less.
The fields Expected Life Period and Expected Life Period Type are for information purposes only.
Advanced Field Service > Settings > Agreement Settings
Entity Agreement Type can be used to define different types of agreements in order to categorize your agreements. The entity is further used as a possible selection field in the setup of coverage terms.
The entity Indexation Months is used while processing agreement indexations. Once an indexation month is created and processed, it automatically creates a 'same month next year' record.
The entity Coverage Category is required to define coverage terms. A coverage category can be linked to a product or service and is ‘Field Service Product Type’ dependent.
Further, the coverage category is used in the definition of the general coverage terms which are eventually loaded into the specific agreement coverage terms.
Coverage Terms is a setup entity where you can define your company’s generic coverage terms. By using this entity there is no need to define agreement coverage terms every time you create an agreement. The generic setup entity can be used to load the terms into the specific agreement terms.
Via the Agreement Selection field, terms can be defined for all agreements, a specific agreement type or a unique agreement. Coverage Category, Coverage Period and Coverage Period Type need to be specified in order to define the term and it is possible to set a valid from and valid to date. Via the field Coverage Discount % it is possible to define if a customer gets full coverage (100% discount) or less.
Advanced Field Service > Settings > Work Order Settings
The entity Invoice Schedules can be used to define your templates for invoice schedules that are used for work order fixed price invoicing.
After saving the invoice schedule record you need to define invoice schedule lines.
For an invoice schedule line, a percentage need to be defined in order to calculate the amount of the work order invoice schedule line (based on the work order fixed price sum). The number of days specified on the invoice schedule line is used to calculate the invoice date of the work order invoice schedule line based on the invoice reference date of the work order (i.e. current day, after 60 days, after 90 days).
A check is available to prevent that the total invoice schedule sum does not to exceed 100%. Note there is no check to prevent the sum to be less than 100%.
