How To Synchronize With A Cwr Mobile Crm 2011 Data Management System

Synchronization Best Practices 2 Table of Contents Synchronization Overview...3 Step 1: Mobile Data Changes are Replicated to the Server... 3 Step 2: Profile Changes are Replicated to the Device... 4 Step 3: CRM Data is Replicated to the Device... 4 Deployment Best Practices...5 Start Simple... 5 Test Connectivity Prior to Configuring Mobile Devices... 6 Perform the Initial Device Synchronization Over WiFi... 6 Configuration Best Practices...6 Remove Unused Entities... 7 Verify Each Entity Has At Least One Sync Filter... 7 Keep Synchronization Filters Simple... 7 Index Your CRM Tables... 8 Schedule Major CRM Schema Changes... 9 Summary...9

Synchronization Best Practices 3 Synchronization Overview CWR Mobile CRM provides your field sales, service and marketing teams offline access to their Microsoft Dynamics CRM 2011 data. The synchronization process is an integral part of that solution. This process involves pushing data that has changed on the mobile device to the CRM server, pulling metadata and configuration changes made in CRM to the mobile device and, finally, replicating CRM data to the mobile device. Synchronization is always initiated by the mobile device and involves resources on the mobile device, the mobile server and the CRM server. CWR Mobile CRM includes a Mobile Configurator that provides the tools that you need to manage and fine tune the synchronization process. Managed entirely from within Dynamics CRM, the Mobile Configurator s point-and-click interface makes it easy to manage this process. Understanding how this works will enable you to make the best decisions regarding the synchronization process. This whitepaper describes the steps of the synchronization process along with the key issues for you to consider during each step. The best practices detailed later in this document can be used to reduce or eliminate the likelihood of these issues occurring. Please note that even though mobile network connectivity errors are not listed they can occur during each step and should be considered in your planning. Step 1: Mobile Data Changes are Replicated to the Server During this step of the synchronization process, data that has been updated on the CWR Mobile CRM enabled device (the client) while offline is transmitted to the CWR Mobile CRM Server (mobile server) which updates the Microsoft Dynamics CRM (CRM) database. Issues that can occur during this step of the synchronization include privilege related errors, data related errors and metadata related errors.

Synchronization Best Practices 4 Privilege errors occur when the user no longer has the needed permissions in CRM to perform the data operation that occurred offline. This can happen when CRM security roles are changed or an updated record is reassigned while the user is offline and no longer has access or update rights. Data related errors occur when CRM records are deleted or changed to a state that is no longer compatible with the change made on the client while offline. Some examples of this include closing an activity that has already been closed or updating a contact that has been deleted by an online user. Data errors may also be generated by custom CRM plug-ins that execute when the offline changes are applied giving the appearance of synchronization errors. Errors will occur if client data is synchronized with a CRM database where the entities, attributes, or option set values have been deleted. Deprecation of CRM database schema elements should be implemented after all mobile datasets are synchronized. Step 2: Profile Changes are Replicated to the Device During synchronization, changes made to the user s mobile device profile are applied. These changes include adding & deleting fields, updating option sets, modifying relationships and relationship mappings as well as the addition & modification of entities, mobile views, forms, site map and client options sections of the mobile profile. Lengthy mobile device processing times may occur when CRM metadata changes are made to large data entities, for example, deleting attributes. Step 3: CRM Data is Replicated to the Device After synchronizing the metadata with the client device, the mobile server compresses and transfers required CRM data to the client device. Synchronization filters, the mobile user s CRM privileges, and record status are used to determine the exact dataset to process. CRM records created, updated, or deleted by CRM users, workflows, and data integration utilities are queried for synchronization. Synchronization filter changes and entities added, removed, or marked for resynchronization are also queried for synchronization. Issues that can occur during this stage of the process include SQL server timeouts and lengthy mobile processing times. Server timeouts can occur whenever the CRM web service does not respond to the mobile server in a timely manner. Causes include network issues behind the firewall, an overworked (temporarily or otherwise) SQL Server, and complex synchronization filters.

Synchronization Best Practices 5 Lengthy mobile processing times usually occur when there is a large amount of data that needs to be inserted or updated on the mobile device. Some examples of where this can happen include initial data loads, entity resynchronization or when a lot of data has change on the CRM server perhaps as the result of a data integration job. Deployment Best Practices Mobile devices and mobile technology have come a long way in the last couple of years. Given 4G networks, abundant and free Wi-Fi access and dual and quad core tablets with 32 to 64 GB of storage space, customers are demanding more from their mobile infrastructure. However, as far as these devices have come, 4G and fast reliable 3G networks are not as ubiquitous, and many devices typically have 256 to 512 MB of RAM and come equipped with flash drives that write or commit data at a much slower rate than they read. The following is a collection of best practices that we have developed while working with partners and customers implementing CWR Mobile CRM. It is a set of guide lines that will help minimize deployment and operational issues and improve user adoption and effectiveness. Start Simple Crawl, Walk and then Run. Insure that the base installation works before expanding the number of users or complexity of the process. This is a simple adage that applies to many different areas and stages of our lives. It applies equally as well when rolling out a mobile enterprise solution; there are a lot of moving parts, some of which you can control (e.g. mobile devices, server hardware) and some of which you cannot control (e.g. connectivity). We encourage you to take this crawl-walk-run approach as you roll out CWR Mobile CRM. Start from a known base, make incremental changes and test at every step of the way. For example: Identify a couple of users with whom you can test (a pilot group) and create a profile that includes a few core base entities like Account and Contacts. Make sure that you can synchronize the required data for those users and then start adding additional entities to the profile, testing with those users as you go. Roll the solution out to the wider user base only after you have demonstrated that everything is working well with the pilot group with regard to the availability of data, synchronization times and usability.

Synchronization Best Practices 6 Test Connectivity Prior to Configuring Mobile Devices Reduce the connectivity errors that you control such as specifying the wrong port or protocol, not opening the custom port on the firewall or not registering the DNS name or alias. While this may sound like simple advice, it is an important first step in ensuring a successful deployment and is, unfortunately, a step that is often overlooked. Make sure that the URL that the mobile device will use to communicate with the mobile server actually works. Remember to test with the right protocol (e.g. http vs. https) and the right port (e.g. 80, 5556, 443, 444, etc.). Test the URL from the mobile device browser in addition to a desktop or laptop browser. Perform the Initial Device Synchronization Over WiFi Ensure your users gain a good first impression of the system by minimizing errors and delays during the initial device synchronization. The initial device synchronization involves the setup of the offline database and the replication of the complete initial dataset for that device which can be time consuming. Replacing the slower cellular network with a faster WiFi connection will go a long way towards ensuring that your users have a good first impression of the system. It is said that a person needs to hear or read something at least three times in order for that person to retain the knowledge. Well, with respect to initial mobile device synchronization, here goes: 1. Perform the initial device synchronization over WiFi. 2. Perform the initial device synchronization over WiFi. 3. Perform the initial device synchronization over WiFi. This best practice cannot be emphasized enough. As a matter of fact, consider it a requirement. Configuration Best Practices A key consideration when you are implementing CWR Mobile CRM is identifying the required CRM data to synchronize with the mobile devices. Customers who want all of their CRM

Synchronization Best Practices 7 data on the mobile device may be challenged by the longer synchronization times or the performance of the device. Determining the specific data required to support your mobile user s business processes is a key planning consideration. Remove Unused Entities Reduce potential server timeouts and lengthy mobile processing times by making sure that you are processing data for the required entities. CRM entities are used in mobile synchronization filters, mobile views and mobile forms. Every entity included in a profile consumes resources on the mobile server as well as the mobile device, regardless of whether it is exposed through the site map, views or forms. Often the default profiles Sales and Service are used to configure the base CWR Mobile CRM system. These profiles configure several CRM out-of-the-box entities to help users get up and running quickly. These profiles should be modified before deploying as the basis for your production mobile profiles. Remove unused entities to minimize the bandwidth and time costs incurred during synchronization. For example, if you do not use Leads or Opportunities then remove these entities from your profile. Verify Each Entity Has At Least One Sync Filter Reduce potential server timeouts and lengthy mobile processing times by making sure that you are processing the right amount of data. Synchronization Filters determine which records are synchronized with the mobile device. This powerful tool works in conjunction with CRM security settings to deliver specific records to the mobile device. Entities can have zero, one or multiple filters. In the absence of a Synchronization Filter for an entity, all records of that entity type for which the mobile user has access will be synchronized down to the mobile device. Ensure that each entity has at least one Synchronization Filter, even for entities where are records will be synchronized. This makes it easier to troubleshoot synchronization issues and ensures that each entity s data requirements have been evaluated. This best practice can help reduce potential server timeouts and lengthy mobile processing times by making sure that you are processing the right amount of data. Keep Synchronization Filters Simple Reduce potential server timeouts by ensuring that synchronization filters can run quickly and efficiently.

Synchronization Best Practices 8 Keep synchronization filters as simple as possible. Filters are converted to SQL queries on the CRM database. Avoid large, complicated filters that try to grab all of the data for an entity with a single query. Complex filters translate to complex SQL queries which increases the workload on the SQL Server and affect performance adversely for CRM, the mobile server and other applications that use the SQL Server. So, keep your synchronization filters as simple as possible break complex filters into several simpler filters. Contact your CRM and SQL Server administrators if you suspect that your filters are becoming too complex. They have administrative tools at their disposal with the ability to tune filters and the resulting queries. They can profile the SQL Server database and recommend changes to the filter if needed. CRM workflows and integration tools can be leveraged to simplify filter requirements. For example, to synchronize all of your accounts that have had an order within the last six months, you would have to build a filter that links the Account and Order tables together and then restricts the Order based on Date and, possibly, Status. The alternative to this would be to create a custom field on the Account entity called Last Order Date and use a CRM workflow to update this field as attached Order records are created or use a data integration tool to update the field nightly. This simplifies the filter to a single table query based on a field that can be indexed if needed (please see the next section about adding indexes to the CRM database). Plus it gives online CRM users the ability to search and filter by this value as well. This best practice primarily helps to reduce potential server timeouts by ensuring that synchronization filters can run quickly and efficiently. Index Your CRM Tables Reduce potential server timeouts by ensuring that SQL queries run quickly and efficiently. To increase SQL query performance, ensure that CRM fields used by synchronization filters are indexed. Primary key, primary field, foreign keys and system fields like Owner, Status and Created On are indexed by default. Including other fields from custom entities in synchronization filters may trigger full table scans in order to return a few rows. While this may not be an issue for entities with a small number of records, it will certainly affect performance on larger tables and could result in server side timeouts among other issues. System tables like Accounts or Contacts have additional out of the box attributes indexed by default. However custom attributes added to system entities are not indexed unless they are foreign keys.

Synchronization Best Practices 9 Adding indexes to your Dynamics CRM 2011 On Premise tables is a supported customization when done according the guidelines in the Microsoft Dynamics CRM 2011 Implementation Guide (http://msdn.microsoft.com/en-us/library/gg328350.aspx). Your CRM or SQL Server administrator can profile the SQL Server database and build the appropriate indexes to improve SQL query performance. This best practice primarily helps to reduce potential server timeouts by ensuring that synchronization filters can run quickly and efficiently. Schedule Major CRM Schema Changes Reduce privilege and metadata errors by ensuring that mobile users have their CRM data synchronized before database schema changes go into effect. Alleviate potential user perception problems with lengthy mobile processing times that may occur as a result of these changes. Errors may occur if mobile data is synchronized with a CRM schema that has deprecated entities or attributes. Remove these entities and attributes from the profiles and synchronize all mobile devices before implementing these CRM database schema changes. Adding or removing attributes used by mobile entities will cause additional processing to take place on the mobile device during synchronization. Tables within the mobile database need to be altered when attributes are added and rebuilt when attributes are deleted. Schedule these changes when possible and let your users know in advance so that they can anticipate the additional synchronization time. This best practice can help reduce errors by ensuring that mobile users have their data synchronized before schema changes go into effect. It will also alleviate potential perception problems with lengthy mobile processing times that may occur as a result of these changes. Summary CWR Mobile CRM is a powerful mobile enterprise solution that provides your field personnel access to their Microsoft Dynamics CRM 2011 data when they need it and where they need it. Knowledge of how this process works and the best practices outlined in this whitepaper, will help to ensure smooth deployment & operation of CWR Mobile CRM.

Synchronization Best Practices 10 Send Us Feedback On This Document We listen closely to feedback from our customers and partners, and we d like to know how well this document met your needs as well as any ways that you would like to see it improved. You can quickly and easily provide this feedback via our website at www.cwrmobility.com/feedback. This document is for informational purposes only. CWR Mobility BV MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Copyright 2007-2012 CWR Mobility BV. All rights reserved. The Power of Close is a registered trademark of CWR Mobility BV. Microsoft, Windows and Microsoft Dynamics are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Apple, iphone and ipad are trademarks of Apple Inc., registered in the U.S. and other countries. The Trademark BlackBerry is owned by Research In Motion Limited and is registered in the United States and may be pending or registered in other countries. CWR Mobility BV is not endorsed, sponsored, affiliated with or otherwise authorized by Research In Motion Limited. Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions. Other trademarks held by their respective owners and/or its suppliers.