Wednesday, September 25, 2019

Work Rule of Record Type: Field Service - Required Resources

If any Work Order (Parent of Service Appointment) has mentioned that list of service resource(s) is/are required (Mentioned this in “Resources Preferences” Related List of Work Order ---  preferences type as “Required”), then that resource(s) is/are respected if we use Required Resources work rule in our scheduling policy.

Note:

Once we installed FSL packaged, by default a work rule record named as “Required Service Resource“ will be created of same type (Field Service - Required Resources). For this example we will use this.

Taking our previous example (working territory). Check below screen, here we are not include “Required Resources” work rule in our Scheduling Policy.



So, here we have three resources are available for service appointment “SA-0020” (Keep in mind “Required Resources” work rule is not included yet).

Table 1:
SERVICE RESOURCE
Pam Lawison
Louise Martin
Ralph Clark

Now, open parent Work Order (00000020) of service appointment “SA-0020” and add four resources as required through “Resource Preferencesrelated list of Work Order.

Table 2:
SERVICE RESOURCE
PREFERENCE TYPE
Alan Reed
Required
Paul Morrison
Required
Ralph Clark
Required
Louise Martin
Required



Now if we include “Required Service Resource” in our scheduling policy then System will filter only those resource which are common from both table (Table 1 and Table 2).




Work Rule of Record Type: Field Service - Working Territories

One Service Resource can have multiple Service Territories (one primary and multiple secondary territories).

Now, some time it is needed that one Service Resource can work on multiple Service Territories. So, in this scenario we can leverage “Field Service - Working Territories” work rule. 

This Work Rule (Field Service - Working Territories) is only considered secondary territories. 

Now, if we want that primary territory will be considered by this Work Rule, then there is a check box field named as “Working Location Enable Primary” under this Work Rule (Field Service - Working Territories), just enabled it. [describe latter]

Note:

1.       Once we installed FSL packaged, by default a work rule record named as “Working Territories“ will be created of same type (Field Service - Working Territories). For this example we will use this.


2.       At a time, we can apply/use either “Field Service - Match Territory” or “Field Service - Working Territories” in our Scheduling Policy.

Example:

Suppose we have a service resource, named as “Ralph Clark” whose primary territory is “Delhi”, but he can also available for “Kolkata North” and “Kolkata South” (secondary territory).
This can be configured by adding 3 service territories (Delhi, Kolkata North and Kolkata South) as a RELATED LIST under service resource (Ralph Clark).



Now include “Working Territories” work rule under Scheduling Policy.



Now create service appointment (say SA-0020) for “Kolkata South” territory.


Check: 

Now if we try to check candidate(s) available for service appointment SA-0020, then Ralph Clark should be shown in DISPATCH CONSOLE.

Reason: 

Though Ralph Clark is belonging to primary territoryDelhi” but he is also available for other secondary territory territories like “Kolkata South” and “Kolkata North”.




Advance level configuration for Working Territories è

In our previous example, we have seen that System are only considering Secondary Territory.
Do not understand right? Ok, check the below screen,



Service Territory
Kolkata South
SERVICE RESOURCE
TERRITORY TYPE
Pam Lawison
Primary
Louise Martin
Primary
Ralph Clark
Secondary

The above screen/diagram indicates that two service resources (Pam Lawison, Louise Martin) are using this service territory (Kolkata South) as Primary territory and one resource (Ralph Clark) is using this service territory (Kolkata South) as Secondary territory.
So, in our above example we have seen that for service appointment (SA-0020), only Ralph Clark is shown as available resource in dispatch console. Though, service appointment SA-0020 is assigned for service territory “Kolkata South” and this territory has 3 service resources as shown in above diagram.

So, why not all three service resources are available for appointment?

Ans. In scheduling policy, we are using “Working Territories” work rule and this work rule is only considered secondary territories, not primary territories. So, Ralph Clark is the only one foo availability.

Now, if we want that System will consider both primary and secondary territory, then how can we achieve this? 

Ans: Edit work rule “Working Territories” and enabled “Working Location Enable Primary” filed.


Check: 

Now if we try to check candidate(s) available for service appointment SA-0020, then all three resources should be shown in DISPATCH CONSOLE.


Work Rule of Record Type: Field Service - Match Territory


Once we installed FSL package then we can find this type (Field Service - Match Territory) of Work Rule record is already available for use and rule name is “Match Territory”.

This work rule is responsible to filter out only the Service Resource(s) who is/are belong to the same Territory, as assigned in Service Appointment and display that filtering candidate(s) for assignment in Dispatch Console.

Example:

Lets take the example I have implemented here. I have created a Work Order (00000019) and for this Work Order, a Service Appointment (SA-0019) has been created. Here the territory assigned for Service Appointment (SA-0019) is “Delhi”.



Now open the Service Territory (Delhi) and go to the RELATED LIST of it and check the Service Resources available for this territories. So, there are four resources available for this territory as shown below screen.



So, Service Territory “Delhi” is assigned for Service Appointment “SA-0019” and there are four Service Resources available for this Delhi territory.

Now if we include the work rule “Match Territory” under our Scheduling Policy, then as per rule, only these four Service Resources will be display as available resources. However, there are multiple service resources available under different territories.



Wednesday, September 18, 2019

Work Rule of Record Type: Field Service - Match Skills


Once we installed FSL package then we can find this type (Field Service - Match Skills) of Work Rule record is already available for use and rule name is “Match Skills”.
This rule is responsible to match skill(s) of Service Resource with Work Order’s (Parent of respective Service Appointment) skill(s).

Assuming work rule “Match Skills” is already assign in our Scheduling Policy.



Suppose we want to check available Service Resources for Service Appointment (SA-0017) in Dispatch Console. Now parent Work Order of this “SA-0017” is “00000017” and it has two skill set,

Table 1:
Service Appointment
Parent Work Order
Skills
SA-0017
WO-00000017
Software Update
SP Installation



Now if we try to check the Service Resources’ skills, then below are the skills details,

Table 2:
Service Resource
Skills
Alan Reed
Software Update
SP Installation
Martino Castanon
Software Update
SP Installation
Paul Morrison
Software Update
Ralph Clark
Software Update

So, if we compare Table 1 and Table 2, then only 2 resources match the skills. So, in dispatch console these two resources will be display.



Note:
There is one more important field in Match Skills Work Rule and i.e. “Match Skill Level”. If it is checked then if any Resource has lower Skill Level than the Skill Level defines in Work Order’s (Parent of Service Appoint) related skill, than that resource will be filtered out from availability.

Consider above table with skill level,

Table 3 :
Service Appointment
Parent Work Order
Skills (Skill Level)
SA-0017
WO-00000017
Software Update (2)
SP Installation




Table 4:
Service Resource
Skills (Skill Level)
Alan Reed
Software Update (1)
SP Installation
Martino Castanon
Software Update (3)
SP Installation






So, as per Work Rule filter criteria, onlyMartino Castanon” will be display in Dispatch Console. Because, other resource Alan Reed  has lower Skill Level than the Skill Level defines in Work Order’s (Parent of Service Appoint) related skill.



Work Rule of Record Type: Field Service - Match Fields

As per naming conversion this Match Field work rule match field value between Service Appointment and Service Resource.

If we create a Work Rule [Work Rules Tab > New] of record type “Field Service - Match Fields”, then it will open below screen with below define fields,




Field
Type
Description
Work Rule Name
Text
Name of your Work Rule.
Description
Text
Description of your Work Rule.
Service Property
Pick List
1. API name of Service Appointment’s primitive data type field.
2. We can add API name as LOV of this field (Service Property) of Work Rule Object.
Boolean Operator
Pick List
Operator like
=
<=
>=
< 
> 
Resource Property
Pick List
1. API name of Service Resource’s primitive data type field.
2. We can add API name as LOV of this field (Resource Property) of Work Rule Object.

Scenario:

Suppose we want to create a work rule which check same “Gantt Label” between Service Appointment and Service Resource and based on this work rule Resource will be available for appointment under Dispatch Console.

Solution:

Note: For this example, I will work on existing record to make this discussion to the point. Because here our aim is to check, exclude work rule behavior, but not to create a Work Order or Service Appointment or Scheduling Service Resource etc.

Initial Check è Check Service Resource(s) for Service Appointment (SA-0017) in Dispatch Console.



Check there is four Service Resources are available for appointment and they are “Alan Reed, Martino Castanon, Paul Morrison, Ralph Clark”.

Work Rule Creation è
Now check that for both Service Appointment and Service Resource have a field label as “Gantt Label” and API is “FSL__GanttLabel__c”.
Now we have to add this API as LOV for Work Rule fields named as “Service Propertyand “Resource Property”.
" So, open Work Rule object and add the LOVs as shown below,





Now, create a Work Rule named as “Check Gantt Label” as shown below,



Assigning this Work Rule in your Scheduling Policy.



Now for our Service Appointment (SA-0017) set Gantt Label value as “Installer” and for following two available resources (check Screen 2) modify same Gantt Label.









Test Resource Availability è
As per Work Rule, only two resources (Alan Reed and Ralph Clark) should be show in Dispatch Console for appointment. As other two resources (Paul Morrison and Martino Castanon) are not matching Gantt Label, so they will not available for appointment.


Work Rule of Record Type: Field Service - Match Boolean

This type of Work Rule filters Service Resources based on its Checkbox fields. Go to Work Rule tab and create a new Work Rule of record type “Field Service - Match Boolean”.



After selecting “Field Service - Match Boolean” click on “Next” button and it will open the below screen. Enter the details as shown in below screen and save it.



Here you will find four fields and its detail is as follows,
Field
Type
Description
Work Rule Name
Text
Name of your Work Rule.
Description
Text
Description of your Work Rule.
Resource Property
Pick List
1. This is the main field for this Work Rule.
2. This is a pick list field and we can update it's LOV with Service Resource's check box API name.
3. While installing FSL package, by default a rule record named as "Active Resources" has been created whose LOV value is set as "IsActive".
Value is True
Checkbox
With this checkbox, we can set the value of the above selected LOV's (Service Resource's checkbox field) as true/false.

Note: After installing FSL managed package system will automatically create a Work Rule of Boolean type named as “Active Resources” for Service Resource’s field name “Active” (API Name: IsActive).

As noted above, similarly we can create custom Work Rule for any Service Resource’s field of checkbox type by adding its API name as LOV of “Resource Property” field.

Limitation

A scheduling policy can contain up to 10 Match Boolean work rules.

Scenario:

Create a custom checkbox field named as “Is Valuable Resource” under Service Resource Object and then create a Work Rule (Valuable Resource) of “Match Boolean” type and then put it in Scheduling Policy, so that only valuable resource(s) will show in Dispatch Console for appointment.

Solution:

Note: For this example, I will work on existing record to make this discussion to the point. Because here our aim is to check, exclude work rule behavior, but not to create a Work Order or Service Appointment or Scheduling Service Resource etc.

Initial Check è Check Service Resource(s) for Service Appointment (SA-0017).



Check there is four Service Resources are available for appointment and they are “Alan Reed, Martino Castanon, Paul Morrison, Ralph Clark”.

Record Update è
Create a custom checkbox field named as “Is Valuable Resource” under Service Resource Object.
Now update “Is Valuable Resource” field as true for Alan Reed and Martino Castanon. For other two it is set as false.



Work Rule Creation è
First, add new LOV under Work Rule’s “Resource Property” pick list and LOV value should be the API name (Is_Valuable_Resource__c) of above created field (Is Valuable Resource) under Service Resource.



Then Create a Work Rule of named as “Valuable Resource” of type “Field Service - Match Boolean” and details should be as below screen.



Assign rule to Scheduling Policy è
Assign the above-created rule to your Scheduling Policy.



Test Resource Availability è
As per Work Rule, only two resources (Alan Reed and Martino Castanon) should be show in Dispatch Console for appointment. As other two resources (Paul Morrison and Ralph Clark) are not valuable resource, so they will not available for appointment.



Note: If we want opposite rule, i.e rule for non-valuable resource, then just unchecked “Value is True” field value of work rule “Valuable Resource” and now Paul Morrison and Ralph Clark will be show in dispatch console for appointment.

Work Rule of Record Type: Field Service - Excluded Resources

Sometime Customer does not want to work with some selected Service Resource(s) due to bad feedback or bad experience. So, here we can use this “Excluded Resources” work rule to meet the requirement.

How to crate:

Go to Work Rule tab and click "New" button to create a new Work Rule. Then select record type as “Field Service - Excluded Resources” and then click “Next”. Then give the Work Rule Name and its Description.





Note: While installing FSL packaged, system will automatically provide a Work Rule record name as “Excluded Resources”. So, we can use this as well.



Note: For this example, I will work on existing record to make this discussion to the point. Because here our aim is to check, exclude work rule behaviour, but not to create a Work Order or Service Appointment or Scheduling Service Resource etc.


Now from “App Launcher“ select “Field Service” app. Now for my case I am opening Work Order (00000017). For this work order (00000017) we have already a Service Appointment (SA-0017).



Then click on “Field Service” tab, then click on “SA-0017”, and finally click on “Candidates” button.



Check there is four Service Resources are available for appointment and they are
  1. Alan Reed, 
  2. Martino Castanon, 
  3. Paul Morrison, 
  4. Ralph Clark.

Now, let say Customer doesn’t want to work with “Alan Reed”.



So, here we can use this exclude work rule to fulfil the scenario.

Go to Related section of Work Order (00000017) and click on “New” button of “Resource Preferences” and then add “Alan Reed” as “Excluded” preference type.





Now the final touch è Go to “Field Service Admin” app and click on “Filed Service Settings” > “Go to Guided Setup” > “Scheduling Policies”.

Select your Scheduling Policy and then add work rule “Excluded Resources” from Available Rule to Selected Rule.



So, we have done. It is ready for testing.

Now again click on “Field Service” tab and open dispatch console and check candidates for “SA-0017”.
So, as per expected behaviour excluded resource (Alan Reed) will not be shown in dispatch console.


LWC to LWC Communication using Lightning Messaging Service (Part - 2)

In my previous post ( previous post link ) we have learn how to create a Lightning Messaging Service with 6 steps and today we will use the ...