Throughout my 7 years of working within the Field Service Product, a feature called Relevance Groups, which has basically been around since the beginning, still comes as a surprise to many folks I speak to in the ecosystem. The easiest way to describe the feature is a way to apply certain Work Rules and Objectives within a Scheduling Policy to certain groups of Service Resources and / or a certain group of Service Appointments, through the use of Boolean Fields on either the Service Territory Member record or the Service Appointment record respectively. Throughout this article I’ll discuss the importance of using Relevance Groups, a specific use case for them plus supporting configuration, and some considerations to keep in mind as you investigate the feature on your own.

Importance of Relevance Groups

The primary reason, in my opinion, for using Relevance Groups is that they give Customers the ability to further extend the use of the Scheduling Logic to meet their specific business needs. I’ve had Customers in the past get frustrated that they can’t just create their own, custom Work Rule or Service Objective Record Types to be utilized within the Scheduling and Optimization Logic. However, through the use of Relevance Groups, I can confidently say I’ve been able to design a solution for around 90% of those same Customer’s requirements, eliminating the initial frustration as well as instilling confidence that they made the right choice in selecting the Salesforce Field Service Product.

Use Case Example + Configuration

The Salesforce Help Documentation outlines an example of utilizing the Max Travel From Home Work Rule, to define different Max Travel values for Full Time Employees vs Part Time Employees. Based on that I’m going to outline an example utilizing another Work Rule, the Count Rule specifically, and how Relevance Groups can be utilized.

Let’s say a Customer has two groups of Resources, Senior Technicians and Junior Technicians. They want to limit the number of jobs per day that Senior Technicians can be scheduled for, as they need a good portion of their day available to work on returned Assets that are being brought in by Junior Technicians. As such, Junior Technicians need to be scheduled to as many jobs as their availability allows, with no restrictions. I inform the Customer that Salesforce Field Service can definitely solve that, which they are super excited about, and I’m going to walk you through how I would go about configuring that below. Let’s dive in!

Since this particular use case aligns to different groups of Resources, I know that we are going to be working with a Boolean Field on the Service Territory Member record to differentiate the groups, as that is what Relevance Groups considers when scheduling. Now, as a personal preference, I like to create Formula Fields on the Service Territory Member, which will be influenced by another Field on the Service Resource record directly. I usually set it up this way because it then alleviates the need to manually check boxes on the Service Territory Member record (as those can change more regularly than Service Resources) and allows me to keep a Service Resource attribute (which is really what we are configuring) where it belongs, on the Service Resource.

So the first thing I’m going to do is to create a Picklist Field on the Service Resource, and call it Seniority. The Picklist will have two values, Junior and Senior, as those are the two groups I’m looking to differentiate between. So I’ll navigate to Setup > Object Manager > Service Resource > Fields and Relationships > New

Next, I’m going to create a Formula Field, of type Boolean, on the Service Territory Member record, and call it Senior Technician. The Boolean will be marked True if the value on the related Service Resource Seniority Field is marked as ‘Senior’, otherwise the Boolean will be marked False. So I’ll navigate to Setup > Object Manager > Service Territory Member > Fields and Relationships > New

Next, I’ll go and mark some of my test Technicians as Senior and Junior on their applicable Service Resource records, and validate that the newly created Formula Boolean Field is marked as True or False as expected on the applicable Service Territory Member record. So I’ll navigate to the Service Resource Tab to make the updates.

Now, this next step is one that I find a lot of folks are missing and usually is the culprit when someone reports they cannot select the applicable Field on the Work Rule to enforce the Relevance Group.

I need to go to Setup > Object Manager > Work Rule Object > Fields and Relationships and select the field labeled ‘Resource Property’. Within that Field I’m going to add the API Name of the Formula Boolean Field I created, on the Service Territory Member record, as a Picklist value within that ‘Resource Property’ Field. This will be an important step as I look to finalize the Work Rule Relevance Group configuration, which I will cover a bit later.

*NOTE* – There is also a ‘Service Property’ Field on the Work Rule Object where I would go and add the API name of a newly created Boolean Field on the Service Appointment, if I was enforcing on a certain group of Appointments vs a group of Resources.

*NOTE* – You’ll also need to make sure to select the applicable Work Rule Record Types that the Picklist value you add is going to be relevant for, which could be multiple depending on the use case and scenario that you are configuring for.

Next, I’ll navigate to the applicable Scheduling Policy to finish the configuration (Scheduling Policy Tab). Now, in this particular instance I added the Count Rule previously to my Customer First Policy, so it shows as one of the Rules to select.

By selecting the Work Rule I notice there is no place for me to indicate that I only want this Work Rule enforced for the Customer’s Senior Technicians. The reason I don’t see it is because there is a dedicated Managed Package VisualForce page specific to Relevance Groups, that needs to be added to the applicable Page Layout. Since there are a number of Record Types / Page Layouts configured for the Work Rule Object, I’m going to select Setup > Edit Page so I can validate which Page Layout needs to be updated and open the Page Layout from there.

After selecting the page Layout, I add the applicable Visualforce Page, size it appropriately, save the Page Layout, and navigate back to the Work Rule I was reviewing earlier.

Once there I now see the two dropdown lists, one for Service Territory Members and one for Service Appointments. As this particular use case is specific to differentiating between Resources, I select the Service Territory Member dropdown. There I can see the newly created Boolean Field (Senior Technician) that I created earlier as an option, so I select it and hit save.

*NOTE* – I always do a quick refresh just to make sure the value I just selected remains and does not revert back to a blank value. If you don’t see the ability to save, it means that the Visualforce Page on the applicable Page Layout needs to be sized a bit bigger.

That should do it and I’m now ready to go test to ensure that I configured everything properly. I created some Work Orders / Service Appointments ahead of time so I’m going to test directly from the Gantt by scheduling multiple Appointments to both a Resource I’ve identified as Senior, as well as one I’ve identified as a Junior, so I can see the limit enforced for the Senior Technician.

So I’ll schedule a couple of Service Appointments to Alan Reed, who I identified as a Senior Technician. However, once I go to schedule a third Service Appointment, Alan Reed no longer shows as available on the same day, as the Count Rule is being enforced, limiting him to only two Appointments a day.

Now, I’ll schedule the rest of the Appointments to Alexander, who I’ve identified as a Junior Technician. The Scheduling Logic allows me to schedule more than two Appointments to Alexander, as the Count Rule is not being enforced for him as I identified him as a Junior Technician.

*NOTE* – I can also double check that the Relevance Groups are working by dragging / dropping an Appointment from Alexander to Alan. As I do that, all of Alan’s Appointments now show in Violation, and by hovering over one of them I can see it is due to the Violation of the Count Rule.

It looks like everything is working as expected and I’ve now been able to align to the Customer’s specific requirements by using the out of the box Scheduling Logic, combined with the use of Relevance Groups to differentiate the application of that Logic across different groups of Resources.

Considerations

In the Related Links section below, I’ll insert the direct links to the Help Documentation on Relevance Groups as well as the Help Documentation on the Work Rules and Objectives. So I won’t list every consideration in detail here, however I did want to outline the three biggest ones I’ve encountered.

The first one being specific to the Resource Availability Work Rule. You need to make sure that you have a Work Rule to cover ALL Resources, otherwise you’ll run into issues. What that means, is if you were to take my example above (Senior and Junior Technicians), and wanted to say apply different duration Breaks across both of those groups of Resources, you would actually need two separate Boolean Fields on the Service Territory Member Record. One for Senior Technicians AND one for Junior Technicians. Then you would need to have 2 variations of the Resource Availability Work Rule in your Scheduling Policy, one applying to Senior Technicians and one applying to Junior Technicians, through the same Relevance Group configuration I outlined above.

The second one, is more of a general consideration, but that is that certain Rules and Objectives can only be applied to either one group or the other (Service Territory Members or Service Appointments), where other Rules and Objectives can be applied to both. So make sure that you read through the Documentation provided, including the description on each Work Rule and Objective, to see where those restrictions may apply.

The third one, again is more of a general consideration, and that is that Relevance Groups can be applied to Primary or Relocation Service Territory Memberships but CANNOT be applied to Secondary Territory Memberships.

Summary

Although the above is a fairly simplistic example, I’ve utilized Relevance Groups to solve for both simple and complex Scheduling Requirements across a number of Field Service Customers. The feature itself can be utilized to differentiate Groups of Resources or Appointments that the Rules / Objectives within Field Service apply to, as long as the key considerations outlined in the Salesforce Help Documentation are adhered to. It is a great feature to be familiar with, and to be able to utilize, to ensure a Customer’s success / satisfaction in their selection of Salesforce Field Service.

Related Links

• https://help.salesforce.com/s/articleView?id=sf.pfs_relevance_groups.htm&type=5
• https://help.salesforce.com/s/articleView?id=sf.pfs_scheduling.htm&type=5
• https://help.salesforce.com/s/articleView?id=sf.pfs_optimization_theory_work_rules.htm&type=5
• https://help.salesforce.com/s/articleView?id=sf.pfs_optimization_theory_service_objectives.htm&type=5