Dynamics 365 Field Service Integrations, Part 5 of 5: Application Integration with Microsoft Flow

In Part 1 of this series, we made the distinction between data integration and application integration. Part 3 and Part 4 of this series showed how the Common Data Service (CDS) Data Integrator can be used to perform data integrations and transformations on a recurring, automated basis.

This final part of the series will look at how Microsoft Flow can enable near real-time application integrations. For this example, we will have Field Service technicians submit purchase requests via their mobile devices for review and approval in Field Service, and then automatically route that request to Dynamics 365 Finance and Operations (F&O) for processing.

Microsoft Flow uses Connections like the ones we set up in Part 1 of this series to interact with a very large and rapidly growing catalog of SaaS-enabled software, even including many competitors to Microsoft. Each Connector allows for controlled access to the software to handle events or perform actions just as you might using APIs and programming, except without having to write a single line of code. For the latest list, navigate to https://flow.microsoft.com/connectors/.

For our example, we will make use of the Dynamics 365 Customer Engagement and Dynamics 365 for Finance and Operations Connectors we set up in Part 2 of the series.

The User Experience

Let’s first review what the users will see in this example solution, and then unpack the MS Flow created to enable it. We begin with the tech out in the field working on his mobile device.

1. The Field Services technician is completing a Work Order and finds that some parts are needed. He completes a requisition on the mobile and submits it for approval and processing.

Note: For this example, I am using the Purchase Order (PO) entity for simplicity. However, since the relationship between a requisition and purchase order is not always 1-to-1, for a production solution we would more likely create a purchase requisition entity in Field Service so that we can use the standard PO entity for tracking resulting POs.

2. The technician supervisor receives an alert for the submitted purchase request and notes it on her dashboard. She reviews the request and then approves it for routing to Procurement.
   
3. In the meantime, the field technician reviews his requisition and can see that it has been approved for Procurement.

4. An automated Microsoft Flow process detects that the request is ready for processing, and then creates the formal purchase request in F&O.
   
   
5. Procurement reviews the submitted purchase requisition and sets up the necessary purchase orders.

Flow Data Integration Configuration

As you can see, this is a pretty simple process for the technician as well as for the back-office workers. Let’s take a close look at the MS Flow automation that makes this possible, which I called “Submit Field Purchase Request.”

All automated MS Flows begin with a triggering event. In this case, the creation or update of the Dynamics 365 Field Service “Purchase Order” entity in the Contoso instance of Field Service. This event—and therefore this Flow—will fire every time a Purchase Order (PO) record is created or updated, so we need to determine if the process should continue by adding a Condition check. Here, we are checking to see if the Field Service PO has been approved, and that it has not yet been written to F&O.

For this example, a field was added to the Field Service PO entity to hold the F&O PO number. As we will see later, this value is updated when the F&O PO is created and allows for this condition check to work.

If the check finds that there is no need to create the F&O PO—either because it has already been done or because the Field Service PO is not yet approved—the Flow ends via the “If no” branch of the Flow. Otherwise, the check finds that the F&O PO is to be created and the Flow enters the “If yes” branch.

Before we create the F&O PO, we first pull the complete Work Order and Warehouse records for the Work Order and Warehouse associated with the purchase order. This is done to get extended details about these items so we can use them when we create the F&O PO record.

With information about the Field Service PO, Work Order, and Warehouse, we can now create the F&O PO record.

We will use the F&O instance Connection we set up in Part 2 and target the PurchaseRequisitionHeaders entity. There are several fields available to us, but we will populate just a few, including PO Name, Details, Requested date, and Preparer. The Details field will provide Procurement with the related Work Order and the Ship-to Warehouse.

In my example, I entered the Worker number for my D365 F&O user so the request would show as submitted by me in F&O. Note that for a production solution, additional steps would be needed to retrieve the user’s F&O Worker ID. This value might be maintained in Field Service using a separate integration, or it may be retrieved from F&O as part of this and other Flows. For our example, I manually keyed it.

The final step is to update the Field Service PO with the F&O PO number so that it can be referenced by Field Service users, and so our Flow knows it has already been submitted to F&O.

The Procurement department, working exclusively in F&O, can now process the purchase requisition!

This is one simple example of what can be done using Microsoft Flow. There are many more scenarios where Flow is a great fit. The power and flexibility of the tool enables a wide range of solutions to be built, and to do so very quickly and easy, most often without any added licensing cost.

In this series, we discussed data vs application integration concepts, reviewed how to set up for an integration project, dove into the use of Common Data Service (CDS) Data Integrator for data integrations, and finished up with a review of Microsoft Flow to manage application integrations. I hope you have found this series to be helpful as you look to tackle your data and application integration challenges!