As we know the Microsoft Field service app has offline capability but there are few design decisions that can help you and your customers in long run.
One important aspect is to decide upon the sync filters which drive what data is available for Users while they work in offline mode.
In this post I would be focussing on Sync filter for Customer assets and it becomes even more important if your customer has a lot of Assets in the field.
Deciding upon sync filters should be a continuous improving/ agile process rather than spending time on thinking the best solution for the very first time.
Here was our Sync filter journey for Customer assets:
- We started with No sync filter. This is because we weren’t sure how many assets would the customer have/create over the period
- Next step was to at least filter out inactive assets
- Now when the asset number started growing, we deciding upon just showing the Assemblies which are nothing but Asset containers at each site. This worked for a while but then technicians had no insight when at a site that this assembly had what assets.
- We finalised upon showing all Assets (Parent/ Child) in the territories that the User works in. This was great, now the User could see every asset that he/she deals with.
- After a while this also starting blowing apart as few Users were catering to multiple territories and by default there’s a hard limit of 10000 records that you can sync for an entity in offline mode.
- The business then decided to re do their territories and create new territories for overlapping areas.
The point here is that no one solution will fit all customers and solution for today may become obsolete tomorrow.
One good thing with woodford sync filters is that we can use fetchxml to build them,
Here’s the sync filter fetch xml we finalised upon:
<?xml version="1.0" encoding="utf-8"?>
<fetch xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="1.0">
<condition attribute="statecode" operator="eq" value="0" />
<link-entity name="account" alias="L0" from="accountid" to="msdyn_account" link-type="inner">
<link-entity name="territory" alias="L1" from="territoryid" to="msdyn_serviceterritory" link-type="inner">
<link-entity name="msdyn_resourceterritory" alias="L2" from="msdyn_territory" to="territoryid" link-type="inner">
<link-entity name="bookableresource" alias="L3" from="bookableresourceid" to="msdyn_resource" link-type="inner">
<condition attribute="userid" operator="eq-userid" />