Best Practices for Offline Mode in the Field Service mobile app – Part 3

Advanced Configuration

In this final part of the Field Service Mobile offline blog series, we will discuss some of the more advanced configuration and recommendations for IT pros and partners to get the most out of their offline application. 

Learn more about the offline user experience in Part 1

Learn more about best practices and configuration in Part 2

Limit relationships to avoid slow-running data queries. 

In addition to limiting data being downloaded, it is also important to limit the complexity of expensive SQL queries that are run to fetch that data. Gains realized by reducing data can be offset by complex queries which take longer run on the server. The following best practices can be considered when defining relationships: 

• If your data model includes several levels of relationships generating multiple joins across tables, consider using simple filters like ‘all records’; it can be faster to download more data up front as part of the one-time initial sync so more frequent delta syncs will be faster without the complex queries.
• If using time-based filters to reduce records, it is recommended to use time ranges with fixed boundaries. For the most efficient sync experience, you could include fixed time window of last month, current month and next month. If requiring more dynamic time-based filtering, filter using Created on in the last N-days. Using these filtering techniques will help support downloading only recent, relevant data for the Frontline Worker. 
• Avoid using both custom data filters and selecting relationships on the same table. This will result in complex queries impacting performance.

NOTE: Be aware that using a custom filter creates an OR with relationships, and each relationship creates as an OR as well.

• Avoid self-joins, where a table is making a circular reference with the same table within customer filters. 
• If using time-based calendar items that result in downloading many related records and files, consider reducing that time window to reduce total data download

Leveraging ODATA to view Offline Profile configuration. 

Makers may be able to better evaluate joins and complexity of their offline profile by viewing those joins directly via API. The following APIs can be used to view details of the offline profile. 

OData call used to return JSON of the mobile offline profile showing profile filters.

This is the fetch xml for offline profile items for any entity within the profile. This could be used to inspect the complexity and relationships. 

NOTE: For the snippets below

• {orgurl} is your CRM organization URL 
• {profileID} is the GUID for your mobile offline profile 
• {entityname} the logical name of your entity 
• {entitysetname} is the plural name you assign for your entity (must be lower case) 
• {fetchXml}: Return value from your get filter ODATA call 

To get started you can locate your profile id leveraging:

https://{orgurl}/api/data/v9.0/mobileofflineprofiles?$select=name,mobileprofileid

To fetch the profile items and filters: 

https://{orgurl}/api/data/v9.0/mobileofflineprofileitemfilters?$filter=_mobileofflineprofileid_value eq ‘{profileID}’ and returnedtypecode eq '{entityname}' and type eq 2&$select=fetchXml,returnedtypecode 

To get the ODATA to test FetchXML for an entity you are including in your profile:

https://{orgurl}/api/data/v9.1/{entitysetname}?fetchXml={fetchXml} 

OData call to find the number of users assigned to a profile.

NOTE: This does not apply to role-based access to profile/apps

https://{orgurl}api/data/v9.0/usermobileofflineprofilememberships?$filter=_mobileofflineprofileid_value eq {profileID}&$count=true 

Understanding Application data & schema changes and their impact on Offline Sync 

The offline sync client uses Dataverse change tracking to find updated records to download. Even a minor change to one column will trigger the re-download of the entire record. Watch out for processes that automatically update many records on a frequent basis as this will lead to longer synchronization times. 

Similarly, when the schema of a data table changes, the offline sync client will re-download records in that table to ensure that no data is missed. Whenever possible, avoid schema changes to offline-enabled tables. When schema changes are required, group them together in a single release or solution update so that data is only re-downloaded for each table one time. 

Leverage “online light up” for edge cases, or scenarios that may not require offline access. 

There are some scenarios where offline access may not be necessary. An example of this may be iOT data which is only a live feed from a connected device that is only accessible online.  

In these cases, you can include that table as part of the user experience in the application, but not include it in the mobile offline profile. By doing so, the views for that table will be accessible to the Field Service Mobile users only when the network is available. 

Leveraging online light up for online-only scenarios helps to reduce data which would otherwise need to be synchronized to the device. It is a great way to meet business needs for uncommon or edge-case scenarios without having to download more data for standard business scenarios that must function offline.  

For standard out of the box forms and views this works without additional logic. When implementing customizations which are intended to be online-only, please refer to Xrm.WebApi (Client API reference) in model-driven apps – Power Apps | Microsoft Learn

Conclusion

This concludes our 3-part blog series on getting the best of your Dynamics 365 Field Service mobile application setup. If there are new enhancement suggestions, it is recommended to submit those asks via the Field Service Mobile Ideas portal: Field Service Mobile – Ideas. This will allow the product team to evaluate new requests and plan for future product release waves. 

And for more best practices, please refer to Platform Offline Best Practices for further offline guidance.