Microsoft Dynamics 365 Field Service and Project Service working together: that “Ah-ha” moment

I had seen and configured each component separately, but this was the first time we had configured them to work together.

Microsoft Dynamics 365 Field Service and Project Service are natural bedfellows. Often a business will create a project and the project itself will spawn multiple work orders. In order to really understand the complexities of anything, you often need to dig in and have a look at the lower level processes and detail, and view the whole process with real data.

Take for example an imaginary project that has been set up to replace all the old street lamps in a city precinct with a new range of eco-friendly lights.

The whole scope of work would be deemed a project. However the implementations through the various streets and shorelines would each be easily considered work orders or specific pieces of work to be undertaken by various teams or be termed a work breakdown structure.

Therefore there is a natural overlap between the field service component – i.e. the staff who will be on the ground physically removing the old lamp posts and replacing them with new ones – and the overall project, the project budget and the project service level agreement and reporting on progress so far.

There are natural dependencies, in that the team who remove the existing lamp poles needs to be followed quite closely by the new team who are replacing these lights, and each of these teams may have separate reporting lines.

An electrician probably needs to be first on the scene to switch off the power or to ensure that the power has been isolated safely and the electrician may ultimately be a member of a different project team to the team performing the physical work as they all have different tasks.

However all the personnel will be responsible for capturing their time on a regular basis. The electrician probably of a shorter duration and the removal and excavation team considerably more. This also applies to the new light pole implementation team and then the electrician returning to the new installation to connect up the power and switch it back on.

There will need to be some element of health and safety and/or traffic management to keep the team safe, as well as protecting the members of the public from possible falling lamp posts. This all needs to be planned, then recorded, and should there be a mishap, adequate capabilities in place to remediate such eventualities.

‍

‍

This scenario depicted above, although very simple, has a large number of working parts and components that are all tied up with the joint concept of field service and project service, this needs to extend to the mobile application used by the teams.

Obviously this example can be likened to many businesses performing various project tasks. Consider that for each of the items on this simple flowchart, it could be necessary to change a status, update a time spent, make notes about what was right or wrong. Then from a reporting perspective, the completion of this Work Order for the lights in this precinct would show as complete, but would only show as a task completed on the overall project.

The different components, activities and collected data all form a malleable information source that can be reported upon and ideally shown in some form of business intelligence dashboard with highlights and indicators to ensure that corrective actions can be undertaken if things are getting off track.

When you see all of this working together harmoniously within the one system, like me you may also experience the “Ah-ha” moment.