Working With Field Service Mobile Customizations 

Field Service Mobile is a Dynamics Power Platform Model Driven Application. This offers several advantages to the mobile application, including re-use of forms and views and consistency of user experience while accessing on the web, mobile, or tablet.  

The Power Platform also offers significant customization opportunities, both when customizing forms, adding business logic or integrations with other Power Platform capabilities like Power Automate, Canvas, or PCF Controls.  These capabilities make the Field Service Mobile application uniquely positioned to streamline your workflows, improve data quality and enhance your user experience.  

Customization Best Practices 

Customizing the Field Service Mobile application is a balance of enabling an ideal workflow for your business and providing the best possible user experience for your Frontline Workers. This balance must consider data availability of the mobile workforce, along with application performance and the overall user experience.  

In this blog post we’ll share some of the key best practices when evaluating and implementing customizations. 

1. Use the default Field Service Mobile app module. The out-of-the-box Field Service Mobile app module has all the basic features and functionality your frontline workers require to get started with Field Service. Custom app modules can be used with the Field Service Mobile application but will not include some of the internal business logic such as Travel Calculations. Another advantage of using the default app module is that it will automatically receive product updates over time, while additional effort would be required to merge the same enhancements into a custom app module.  
2. Avoid using HTML Web Resources.  Web Resources have many limitations on a mobile application when working with offline mode. It is highly recommended to use PowerApps Component Framework (PCF) controls, which are a better option for a more consistent cross-platform experience without the same limitations. 
   • Tip: If your situation necessitates the use of custom web resources, use code splitting and check code coverage in a browser to ensure only the minimum amount of code is loaded. Package shared code in their own shared web resource library instead of duplicating in each consuming resource. 
   • Tip: Be sure to define a unique namespace for custom JavaScript libraries to avoid having functions overwritten by other functions in another library. Learn how to write your first client script in model-driven apps. 
   • Tip: If using Offline mode, be sure to test your customizations on the mobile device in Airplane mode and variable cellular network conditions.  
3. Handle errors properly and present the right message to end users. When implementing customizations, it is very important to handle edge-cases and errors in a way that provides a positive experience for your end users. This is especially true for async calls and network errors, where the Frontline Worker may have different results depending on devices network state.  
4. Use XRM Web APIs instead of XHR/Fetch calls directly to the server.  XRM Web ApIs will route correctly to the local offline database or server based on offline configuration and network state of the app. 
   • Making direct server calls from the mobile application is not recommended as they can be unreliable and fail unexpectedly with poor network conditions.  By ensuring that all dependencies are in the offline data store by configuring the Mobile Offline profile with the correct data necessary for your user scenarios.   
   • If server calls are necessary, build an appropriate user experience to handle cases when the call may fail, or response is slow to return from the server. Making the network calls trigger based on explicit user actions, with a interface giving visual cues that a network call is happening and a response will be needed, will provide a better experience for the Frontline Worker.  
   • If using onload/onchange/command handlers and fetching data using XRM WebAPis, make sure you test the impact of those calls on application performance while in various network conditions. 
5. Optimized resources for bandwidth. If adding custom JavaScript or images, be sure to optimize files which are downloaded to the device. We recommend to always trim and compress your JavaScript files and using SVG images instead of PNG to save bandwidth.  
6. Declare solution dependencies between commands, web resources, and strings. Dependencies must be used to make a Web Resource available offline. For example, when an entity/form is enabled for offline usage, the JavaScript which is attached to the form for onload/onsave, would also be available offline.  For other files such as localization XML files, they need to be added as a dependency to your JavaScript so these XML files will also be available offline. Learn more about web resource dependencies. 
7. Be aware of timing issues or race conditions. This is especially relevant when dealing with async calls. Test by adding network latency and CPU throttling to ensure a positive experience in real-world conditions. 
8. Use Business Rules as first choice over custom client-side JavaScript. Business rules provide a mechanism to implement business logic with some guardrails to avoid some of the complexity that comes with custom JavaScript code. Please be aware there are some limitations with business rules, such as cases when OnChange events are required.  It is good to evaluate your business scenarios and choose the best path for your organization. 
   • Tip: If using JavaScript-based business logic, make sure you fetch minimal data and avoid joins/sorting if not needed.  
9. Leverage out of box controls. As much as possible use out of the box controls, such as the Booking Calendar Control, which will be easier to support and receive product enhancements over time. 
10. When enabling offline mode, make sure forms and views are aligned with configuration of the mobile offline profile. The individual configuring the forms and views should work closely with the person who will configure the mobile offline profile to ensure tables which are enabled on views will be available while running in offline mode. Be sure to include error handling if there are instances when an entity will not be available while offline.  
11. Leverage tools to debug customizations. Debugging is important when introducing JavaScript customizations to your experience. Debugging a mobile app has unique challenges versus a web browser. This is especially true with capabilities like Offline mode are enabled on the mobile app. To meet this need, leverage debugging tools shipped with the Android and Windows model driven apps. Detailed steps to debug are found in Power Apps documentation.  

Customizing a model driven application can be a powerful way to enhance the user experience and functionality of your solution. However, it also requires careful planning and testing to ensure optimal performance, usability, and compatibility. In this blog post, we have shared some best practices and tips on how to customize your model driven application effectively. We hope you have found this information useful and that you will apply it to your own projects. Thank you for reading and happy customizing! 

Additional Resources 

• Customization best practices – Dynamics 365 Field Service | Microsoft Learn 
• Customize commands and the ribbon (model-driven apps) – Power Apps | Microsoft Learn 
• Example: Create and customize a model-driven app form – Power Apps | Microsoft Learn 
• Get started with model-driven apps customization using code – Power Apps | Microsoft Learn 

The post Working With Field Service Mobile Customizations  appeared first on Microsoft Dynamics 365 Blog.