Requirement Group – purpose, anatomy and example

This post is a part of a “Field Service for Citizen Developers” series. Click here to see other posts.

Requirement Group’ is one of the recent enhancements to the Dynamics 365 Field Service app. To understand whys and hows of it, let’s consider the following statements for booking resources on a maintenance work order:

1. Book Susan tomorrow at 10 am
2. Book any resource with ‘heavy machinery operating license’ at 10 am tomorrow
3. Book either a resource with expert-level proficiency in operating machinery or two mid-level proficient resources
4. Preferably book a resource from the local team, but if not available, then book a resource from a team in other cities

Did you see the pattern here? The first two statements are definitive on resource’s identification – it talks about resources (or crew/pool/equipment) with specific criteria (skills, territory etc). The last two statements, however, talks about multiple resource options with different criterion. Consider the third point for example, where you, as a scheduler, may want to allocate a senior resource for your premium customer but if senior resources are all busy, you may want to allocate two mid-level expertise resources. Or imagine you have teams of field technicians in two cities and you would want to allocate local resources to do the work, but if they are all tied up, then you may have a resource fly over from the other city to do the work within committed SLAs. These kinds of scenario are very common in field services planning and execution and were unfortunately not possible in Dynamics 365 field service until the introduction of ‘Requirement Group’.

Anatomy of the Requirement Group
Essentially Requirement Group is, as the name implies, a group of ‘Resource Requirement’ records. This group (as a template) gets linked to Incident Type so that Work Order with specific incident types could have multiple scheduling options per related Requirement Group.

The Requirement Group can be created from the navigation menu under Field Service -> Service. Each Requirement Group has two parts: header and group of requirements. The header essentially has two meaningful elements only: record’s name and a boolean to identify where the record is a template? If it is not, it lets you select a template requirement group. I would recommend creating a template first and then linking with incident type to see the magic.

Save the record and move to the section below in the form. This section essentially has a grid (table) with a lot of information. To decipher this, we will look into various columns and actions in three parts:

1. The first column:

The name column lets you create a group of requirements. In our example, we created two groups – one for senior and another one for a junior quality team. Under each group, we then mentioned resource requirement record names. The idea here was to create two options for booking a resource – either book a senior resource or book two junior resources, therefore 1 resource requirement under Group 1 and two resource requirement under Group 2. It is pertinent to mention here the fluidity of user experience as the screen is designed for quick data entry and you mention group names, resource requirement record names and the entire hierarchy without clicking on any ‘new’ button or going away from the screen. Very cool!

2. Rest of the columns

The purpose of the rest of the columns is to mention (refer to annotations – 1, 2 and 3 on the image above):
(1) High-level overall specifics of requirement group,
(2) specifics of individual groups, and
(3) individual resource requirements

The first level: At the top level, those specifics are mentioned which are going to remain the same across multiple requirement groups. This particularly includes duration and fulfilment preferences. In other words, the requirement group can have multiple resource requirement options but their duration should be the same and if there are any fulfilment preferences, they should also stay the same. In our example, we set a duration as 4 hours and selected a pre-setup fulfilment preference record. The Select field has two options – Any and All. Any literally tells the system to find resource even if ‘any’ requirement is met, while All tells the system to find resources if ‘all’ requirements are met. We set it to Any at the top level to tell the system to find resources which meet the requirement of Group 1 (Senior quality team) or Group 2 (Junior quality team). The ‘Part of same’ field has three options: Organisation Unit, Resource tree and location. This field helps in specifying requirements for the system to suggest ‘only’ those resources who belong to the same organisation unit, or part of the same resource hierarchy or are on the same location. For our purpose, we left this as a blank.

The second level: In this level, we can set the specifics of individual resource requirement option – junior and seniors teams, in our case. In our example, we set the Select field as All, which means the system should only suggest resources which meets all the requirements in the group.

The third level: At this level, the specifics of an individual resource requirement record can be set. This could either be done in the table or ‘Open Form’ action can be chosen (from the actions bar on the top of the table) to open Resource Requirement record in a new window. Following are notable fields here:

• Organisational unit: Individual organisation units can be specified here, per resource requirements. We set two different organisational units in our example for senior vs juniors teams.
• Resource categories: The resource categories for individual resource requirement records can be specified here. In our instance, we asked the system to suggest senior resource who falls under ‘lead’ category, while junior resources could be technicians.
• Resource characteristics: This is where the distinction between senior and junior can be specifics. In our example, we set the proficiency level as ‘expert’ for ‘seniors’ and ‘good’ for ‘juniors’ in multiple characteristic types.
• Preferred resource: As the name implies, a preferred resource can be mentioned here
• Sort option: Four options here are None, Randomized, Most busy and Least busy. This tells the system to sort a list of resources in Schedule Assistant per this sort option

3. Actions on the top

Following buttons are available on the top of table:

• Refresh: refreshes the table from the last saved version
• Open Form: opens a new window of Resource Requirement record
• Duplicate Requirement: It is a very useful button that lets you duplicate a requirement row in the table and then change any specifics for that row only
• Delete: Deletes the resource requirement row from the table
• Move Up and Move Down: changes the sequence of requirements in the group

Link to Incident Type and the Magic
The next step after creation of a resource requirement is to link that with an incident type record.

Now as a Work Order is created with same Incident Type selected as ‘Primary Incident Type’ on the work order record, system automatically creates a Requirement Group record with the same specifics as set in the template.

If you now click on ‘Book’ button on the Work Order or on the Requirement Group, system automatically looks for and then suggests list of resources in accordance with multiple resourcing options (groups and requirement records) as specified in the requirement group record:

As we can see, Schedule assistant first suggested few senior resource slots and then showed multiple junior resource combination (two resources) options. Magic, isn’t it!

Hope it helped as a quick primer to Requirement Group functionality. Feel free to try this on your environment, read more and share if you have any questions. Thanks for reading!