After using FieldOne Sky and Field Services for a little while, I have come to understand the inner workings for a lot of the workflows that come within the solution. One of those Workflows is Work Order Sharing/Unsharing. Knowing the details of this might save your life one day.
I sometimes get users complaining that they cannot see their jobs for the day and I never knew how to fix the issue until I did a lot of looking around. It all comes back to the Work Order Sharing/Unsharing workflow and the General Sharing functionality in CRM. Sometimes the workflow fails or even worse the Sharing functionality in CRM completely stops (Its happened in the past and neither us or Microsoft knew why Sharing stopped working. I think it just can back by itself after a couple of days) But this effects the ability for the Work Order details being shared to the Resources and if the workflow fails once it wont retry again.
Below we have an example of a Work Order Schedule which hasn’t been shared with the Resource even though there is a Resource assigned. We will click the Share Button to see if this Record has been shared correctly with the Resource.
As you can see below, this Record has not been correctly shared with the Resource. Which most likely means that the Resource wont be able to see the work order details on the FieldOne Sky Mobile App. But how to we fix this? Simply sharing this Work Order Schedule with the Resource will not work as the Resource will need access to all the other Records such as Work Order, Service Tasks & Incidents etc.
To solve the issue is knowing how to trigger the Work Order Sharing/Unsharing workflow. To trigger the workflow, we need to change the old Resource to another Resource and saving.
And then add the original Resource back again and save.
What will happen is that the Workflow will know that the Resource has been changed on the Work Order Schedule and that it needs to share the Work Order details with the new Resource ‘Rachael’ and unshare the Work Order details with the old Resource which in this case was ‘crmtestuser1’. This is to stop clashing of work orders appearing on two different Resource’s tablets. We wouldn’t want two employees to appear at the same job would we?
In the Audit History we can get a more detailed look at what happened. As you can see when the Resource got updated to ‘crmtestuser1’ and the workflow triggered afterwards and began to Share and Unshare the Record.
In the Unshare event we can see that all the Record Privileges were taken away from Rachael.
And in the Share event, the Record Privileges got added to crmtestuser1
Then next it will do the same again but will Unshare the Record Privileges with crmtestuser1
And then Shares the Record Privileges with Rachael again
This shows that the Workflow has worked correctly and that the Work Order Details have only been shared with Rachael.
You can also see more detail in the System Jobs list.
If you open up a record you can see that the Unsharing job reads a bunch of values. If you look closely you can see values such as:
- NewResourceId
- OldResourceId
- WorkorderId
As you can guess, its storing the GUID of the previous Resource and the new Resource so that it knows who to Unshare and who to Share the Work Order Details with.
And within the Sharing Job below you can see that it reads more values such as:
- f1_workorder
- f1_workorderincident
- f1_workorderservicetask
- f1_workorderresource
- account
- f1_incidenttype
These are the entities it also shares with the Resource so that the user can see the details of the Work Order and what Customer they are going to see. This supports my statement further above that just sharing the Work Order Schedule is not enough as it doesn’t share any of the entities which the Resource also needs to see. So triggering the Workflow is necessary.
And that’s it!
Its quite rare that the workflow will fail but its good to know how to trigger the workflow manually just in case this issue pops up.
I imagine that the workflow works the same in Field Service so feel free to use this guide.