The power of the Power Platform: Extending Field Service with Flow and PSA

Tested on:
Dynamics 365 version 9.1, Field Service solution version 8.2, PSA solution version 3.2, Unified Interface, Microsoft Flow

Enabling field technicians to generate additional sales on their service calls is one of the many selling points of Dynamics 365 for Field Service. When Microsoft’s Global Field Service Director Ben Vollmer gave a presentation on Field Service at the D365UG Virtual Summer Camp, one of his points was that businesses want field technicians to generate additional sales while on service calls. In Field Service we have several ways of accomplishing that.

This blog post describes an approach to logging additional sales with a focus on mobility. The assumption is that a field technician uses a mobile device for updating the progress of service tasks. When a customer asks if a field technician can do something extra, all that is required is a new Work Order Service Task. Let’s consider the following scenario: You’re moving a customer from floor a to floor b and the customer asks you to do some additional work by moving some equipment to floor c. This isn’t in the original scope of your Work Order so it’s additional work. You have an agreement that additional work is priced at X dollars per hour. You move the equipment and log the work by creating an additional Work Order Service Task on your mobile.

As employee time tracking is in many cases needed for employees, it’s a pretty logical choice to use Time Entries for this. In addition to employee time tracking, using Time Entries allows you to verify what has been done by approving submitted Time Entries. Approved entries can then be invoiced from the customer at a predefined rate. As your field technician will in any case very likely use Work Order Service Tasks to update work progress, familiar functionality can be leveraged.

The goal and prerequisites

Recording additional sales by field technicians is the goal. To achieve that, a new Work Order Service Tasks crates a Time Entry, which is then approved and eventually invoiced. To create Time Entries in Field Service we need to have PSA’s elements in place as that application has the Time Entry entity:

1. All the relevant PSA settings and parameters must be in place. You can find my blog post about those here and video guides here.
2. An Order (Project Contract) and a Project are needed for Time Entries when we want to invoice them. I wrote a post a few weeks back about using Flow to enable Time Entries in Field Service. That post is a prerequisite to get the functionality described in this blog post working. The previous post can be found here.

The process

This example consists of a Flow, two Business Rules and custom fields. The example is partly based on an actual functional requirement by a customer so it includes some granular details. Feel free to make the process more straightforward by removing some of the conditions I have set. The Flows and a managed solution for D365 CE can be downloaded from the Those Dynamics Guys PowerApps Bank here. On a high level, the process is:

1. Create a new Service Task and fill required fields.
2. Set Submit? to Yes on the Service Task to create Time Entries. The task must be 100 % complete and Extra Work? must be set to Yes.
3. A Flow will create a Time Entry and another one will sets Status Reason to Submitted.
4. A Business Rule will prevent users from submitting the Work Order Service Task again to avoid duplicate Time Entries.
5. The Time Entry can be approved and invoiced. This scenario is not covered on this blog post.

1. Custom fields on Work Order Service Task

I have added several custom fields on Work Order Service Task so that tasks would easily turn into Time Entries by using the Flow described in chapter 3. To make life easier, a calculated field can be used to calculate the difference between the Start Time and End Time fields. In this example I have used the OOTB field Actual Duration as a placeholder for the value that is pushed to Time Entries.

2. The Business Rule that sets fields as Business Required

To make sure all relevant fields hold values, this Business Rule sets all relevant fields as Business Required when Extra Work? is set to Yes.

3. The Time Entry Flow

The image below outlines the Flow’s different steps. I have included annotations to clarify certain fields. Time Entries are created when a task is Extra Work, 100 % complete and submitted.

4. Updating the Work Order Service Task

Update the Status Reason of the Work Order Service Task to Submitted by adding an action after the one that creates a Time Entry. A Business Rule then picks up the logic from there. The purpose of setting the Status Reason to Submitted is to prevent a user from re-submitting a task when the Business Rule described in the next chapter locks the Submit? field. The Status Reason can be seen at the very bottom of the image below.

5. The Business Rule that prevents duplicate Time Entries

This Business Rule works in conjunction with the Flow from the previous chapter. As the Submit? field is locked, the Flow that creates Time Entries won’t create a new Time Entry record. The Flow will be displayed as being successfully run but all its steps won’t be completed. For the sake of example I’ve left a backdoor in the Business Rule that allows a user to unlock the Submit? field.

Setting Submit to “Locked” will cause the Time Entry Flow to fail if the Flow executes after the Business Rule. The Set Field value: Set Submit to Locked Action in the Business Rule should be removed.

Summary

This example leverages Field Service, PSA and Flow to allow field technicians to easily create relevant entries for extra work sold during service calls. Prerequisites include PSA and a Flow which creates the necessary PSA records when a Work Order is created. A blog post about that can be found here. Feel free to adjust this concept to fit your specific business requirements. A download link to the Flows and a D365 CE managed solution that includes the custom fields and Business Rules is here.

Disclaimer:
This blog posts reflect my personal opinions and findings unless otherwise stated.