Cases, jobs and work orders in Microsoft CRM & FieldOne Sky

Right from the start, Microsoft Dynamics CRM has had a service module. It had basic case management and a knowledge base, in recent years this has been with the introduction of SLAs entitlements, routing rules and case creation automation, and an overhaul to the knowledge base.

Case management is the natural pre cursor to service management, for example a customer calls in with a problem, a case is raised and thereafter a technician is despatched to resolve the issue. They are in effect complementary activities when looked at from the overall service perspective.

Case management can stand on its own, and the Unified Service Desk offering within Microsoft CRM may be all that some companies require where the case creates a simple job which may be handled by a service team. A good example of this is where every job is exactly the same and there is no need to specifically schedule the work. This could relate to someone who just has to read a meter at various locations during the day.

FieldOne Sky however is predicated on the notion of a Job or Work Order which is spawned by a case. There are obvious exceptions to this rule, however most of the scenarios outlined in the previous blog all could be linked to a case record. From the local government official sent out to inspect and report on compliance to the delivery person scheduled to deliver a new fridge, all of these work order records could be created from a case or incident record.

There is something that needs to be done, information about the work is recorded and the person undertaking the work will be obliged to update this information and probably indicate a time of arrival and departure in order to facilitate billing. This is what a work order is all about.

Let us look at two of the many fields that are found on a Work Order to explore the scale of the application.

Primary Incident Type

An Incident or Case can have a type for example “broken stove”, this incident type will have a number of characteristics associated with the type. These include the Default Work Order Type, the Duration and whether this incident must inherit data from agreements or contracts.

What this means is that just by creating a case of a particular type, the resultant Work Order is going to be populated with data that has been set up in the background.

The type of work order will be used to determine the specific resources that are required in order to complete the work, and are available to be scheduled based on current availability. The reality for many field service managers is that “everything is urgent” and a lot of flexibility is often required to manipulate the schedules to see that everyone ends up happy. Therefore the scheduling engine needs to be sophisticated enough to deal with this reality.

In order to highlight the deep drill down complexities of the FieldOne Sky application let us look at another field on the work order that drills down to other records which in turn drills down to more records.

Primary Incident Customer Asset

Another capability of the system revolves around the identification and intelligent recording of customer assets. The Asset record in CRM is the repository for data about a specific asset as can be seen below. Therefore a case and the resultant work order can be related to an asset.

Assets can have parent records and even be linked to a “Master Asset” and have “Sub Asset” levels to allow for granular componentry. Leveraging the standard CRM product module an asset can even be known and discovered with a price, unit of measure, and be linked to relevant price lists.

‍

‍

The preferred resource can be set on an asset. When you drill down to resource you are able to discern that it contains all the information relating to the capabilities, skills, rates, locations etc. of the resource to be used in the algorithm for scheduling. The preferred resource could be a vehicle with an inventory of spares, which could be classified as a warehouse from a system perspective.

Once configured correctly, a work order created as an outcome of a case has all of the metadata required in order to provide the person attending the call with all of the relevant information to perform the work, and report back, effectively closing the case once complete.

Therefore as can be seen, just looking at a small sample of the fields in this module of Microsoft Dynamics CRM there are deep functional capabilities that are available which will be able to address Field Service requirements for most applications.

However as is the case with the introduction of any new system, good analysis up front is never wasted and once the requirements and specific nuances and operational methodologies of the business are understood the configuration of the system can be planned and effectively implemented.

In my next post I will look at the scheduling aspects of this application.