Using Requirement Groups is one way to achieve efficiencies in scheduling and delivery fulfillment. You can set up complex scenarios and be assured that the field technicians who arrive onsite will have the proper certifications, access, and oversight necessary to achieve a one-visit solution. In this three-part blog series, we’ll dig deep into Requirement Groups through the lens of service companies with complex staffing needs for which traditional resource models often don’t work. Dynamics 365 for Field Service allows us to use multi-level, multi-requirement groupings to ensure that all the various ways of meeting requirements are considered and optimized. Part 1 describes Requirement Groups in detail. Part 2 will be all about creating Requirement Groups; Part 3 covers complex scheduling examples. Enjoy!

Note: This instructional blog assumes the reader has a properly configured Dynamics 365 for Field Service system with Characteristics and Resources already defined.

PART 1 – WHAT ARE REQUIREMENT GROUPS?

Being able to schedule multiple resources in the most efficient way possible is one of the best uses of Dynamics 365 for Field Service. Ensuring that all requirements are met by the fewest number of resources helps to decrease overhead costs while improving first-time fix rates. And the key to scheduling multiple resources efficiently is the use of Requirement Groups. But what are Requirement Groups?

Requirement Groups are, literally, groups of requirements that work together. They give us the ability to use flexible staffing parameters to meet a wide variety of needs. A great way to illustrate this is with candy. After all, if you’ve ever promised a 5-year-old that they can pick out candy at a store, you have probably participated in flexible negotiations with requirement groups.

• YOU: Okay, pick out the candy you want.
• KID: Can I have 2?
• YOU: Well, if you take a candy bar, you can only have one. But if you choose gum, you can have 2.
• KID: Can I have a gum and a candy bar?
• YOU: No, but you can have a gum and a sucker.

Believe it or not, that conversation is a perfect example of how you can use Requirement Groups. Here’s what that would look like as a Requirement Group template in Dynamics 365 for Field Service.

• Root, Any
  • Option 1, All
    • Candy Bar, 1
  • Option 2, All
    • Gum, 2
  • Option 3, All
    • Gum, 1
    • Sucker, 1

This Requirement Group gives us 3 different options:

• 1 candy bar, OR
• 2 packs of gum, OR
• 1 pack of gum and one sucker

Sure, the kid would prefer to eat all the candy, but we’ve created a Requirement Group that forces them to choose only one of the options (by using ANY as our constraint).

When applied to Field Service, this same sort of requirement grouping might look like this:

• Root, Any
  • Option 1, All
    • Expert Technician, 1
  • Option 2, All
    • Novice Technicians, 2
  • Option 3, All
    • Apprentice Technician, 1
    • Trainer, 1

To fulfill this Requirement Group, we would book only ONE of these staffing options:

• 1 Expert Technician
  • Many years of knowledge, able to work on their own, OR
• 2 Novice Technicians
  • They have a little experience, not able to work on their own, but don’t need a supervisor, OR
• 1 Apprentice Technician and 1 Trainer
  • The Apprentice doesn’t have all the knowledge needed, so they are accompanied by a Trainer

Makes sense, right? So, how are Requirement Groups actually used?

Requirement Groups are either applied to Incidents or to individual Work Orders. Basically, anywhere you would put a characteristic, you could use a Requirement Group instead.

When Requirement Groups are paired with Incidents, the two tools together become a powerful iterative business model. As an example, let’s talk about Heater Installation work. In order to install a heater, you need a couple things:

• A certified Installation Technician (or an Apprentice and a Trainer)
• Truck with appropriate tools
• Heater to be installed
• List of steps to be completed

Assuming this is a part of our business that gets scheduled repeatedly, we would want to set up our system to allow us to schedule heater installations as efficiently as possible. Here’s how:

• Heater Installation Incident Type (added to a Work Order)
  • Heater (product, set up to create a Customer Asset upon installation)
  • Installation (service)
  • Service Tasks (such as “Collect Model # and Serial #”)

• Requirement Group (attached to Heater Installation Incident)
  • Root, All
    • Option 1, Any
      • Expert Installation Technician
      • Apprentice/Trainer Crew
    • Option 2, Any
      • Truck 1
      • Truck 2

With your system set up like this, you can be assured that….

• The Dispatcher will only see options that meet the job’s requirements.
• When the technician arrives onsite, they’ll have everything they need to do the job.
• When the installation job is complete, the Heater will be listed as a Customer Asset automatically.
• The next time you have a heater installation project, all your setup work is already done!

Now that you know the basics of what Requirement Groups are and how they work, you’re ready for PART 2 – CREATING REQUIREMENT GROUPS.

Don't forget to subscribe to our blog and as always, happy Dynamics 365’ing!