Going Offline/Synchronizing

As mentioned previously, CRMSO users are taking a copy of their CRM data offline to work with it and later synchronize it back to the main corporate CRM database. By the very nature of this process there are always issues and challenges. Principally, some of the major challenges involved in working with offline data sets are

• Amount of data to take offline

• Data Conflicts

• Recovery from dropped connections or hardware failure

• Scalability

Each of these challenges is examined in detail in the following sections.

Amount of Data to Take Offline

The rule of thumb on the amount of data to take offline is simple—the less the better. Obviously, from a functional perspective, we want as much data as possible. However, from a technical perspective the challenges of slow connections, dropped connections, and data collisions make smaller data sets more attractive.

Figure 8.15 shows the screen the user sees each time she synchronizes data. The checkbox at the top of the screen enables the user to decide whether downloading attachments is important and worth the trade-off in synchronization time. This refers to all attachments, except Sales Literature. Attachments can account for a lot of data and can really extend the synchronization process.

NOTE In addition the Go Offline/Online button on the CRM toolbar, there is also a synchronize option under the CRM Tools menu. The purpose of this option is to allow a user to synchronize data without changing his current offline/online status. However, as of this writing, this feature does not work as designed and always takes the user offline. The recommended workaround is to use the “Go Offline/Online” buttons exclusively until this bug is fixed in a service pack.

The second checkbox in Figure 8.15 enables the user to synchronize only data from their business unit. Again, the records that are synchronized by default are all records to which the user has access. In other words, if the user can see it in the web client, she can synch it. Deselecting the “only synchronize data from my business unit” option is generally not recommended, as it can substantially increase the amount of data that would be synchronized.

The Sales Literature box lists all Sales Literature items that have not previously been downloaded. The user can be more specific with Sales Literature, deciding to take certain pieces and leave others.

Data Conflicts

Data conflicts are part of offline data sets. They are caused because when a user takes a copy of a record offline, the record is still available online for editing by other users. If the offline user and an online user both update the same field to different values, a data conflict occurs when the offline user synchronizes his data.

Microsoft CRM handles data conflicts by saving the last value to update the field in question. Consider the following sequence of events:

• Bill, a user working offline, changes a Contact's mobile phone number on Wednesday

• Karyn, a user working online changes the same field on Thursday

• Bill performs synchronization on Friday

• Bill's change overwrites Karyn's change even though Karyn's change is technically newer

In our example, an older piece of data beats a newer piece of data. Why? Microsoft CRM cannot trust the date/time that the user's computer said the data was changed; it has no control over the time and date settings on the offline user's computer. If it trusted the offline user's local date and time setting, the offline user could change these settings to artificially alter the sequence of events. The best way to avoid data conflicts is through frequent synchronization of data.

Let's take a look at another example:

• Bill, again working offline, updates a Contact's postal code on Monday

• Karyn, again working online, updates the same Contact's title on Tuesday

• Bill performs synchronization on Wednesday

• Both changes are written to the master Contact record because two separate fields were updated

Micrososft CRM's synchronization looks at each field individually when determining what data to update.

Another type of data conflict may occur when, for example, a user takes a record offline and the record is subsequently deleted from the online database. Alternatively, a user may receive a data synchronization error if one of his or her offline records has changed business units or he or she has lost permissions to the record. Figure 8.16 shows the screen the user will see when trying to go back online under these circumstances

Microsoft CRM provides three options for dealing with this type of data synchronization error. These are

• Proceed with going online, but save the data changes offline for next time you synchronize— This option allows the user to get any changes that have been made online, but not synchronize their offline changes back to the online environment. This is a good alternative if you want your data now and prefer to deal with the error later. In fact, sometimes data synchronization errors will be thrown for no reason and choosing this option followed by an immediate re-synchronization will reveal that there really is no issue.

• Stay offline and try and fix the errors so all the data will synchronize— This option can be chosen if you feel you can fix the error by making changes to your offline database before going back online. If you do so and then re-synchronize, you theoretically will not receive the error again.

• Finish going online and do not save the data changes made offline— This is similar to the first option except the online changes will not be made to your offline database.

We anticipate that Microsoft will continue to build more error trapping and intelligence into the synchronization process so that data errors will be either avoided or handled. For example, as we said earlier, currently it is possible for an online user to delete a record that another user has taken offline. Clearly, there is room for improvement in this scenario.

Recovery from Dropped Connections or Hardware Failure

Being prepared for the worst is an important characteristic of a solution where data synchronization is required. Inevitably, users will be sailing along synchronizing their data when out of nowhere a line goes down, and they lose their connection. How gracefully the system recovers from this type of occurrence determines how well the data stays intact. If the recovery mechanism is poor, the data integrity suffers and changes that were made offline will be lost and/or records will become corrupt.

The Microsoft CRM offline database keeps a running list of the CRM records the user has modified since taking those records offline.

NOTE The offline MSCRM database has a table called OfflineQueue that keeps a list of all records to be updated.

When the user goes back online, her database automatically begins a synchronization process with the master CRM database and each record is updated as an individual transaction. If one of the computers crashes for any reason or if the connection is dropped, whatever transaction is being performed at the time is rolled back and performed during the next synchronization. The bottom line is that if you lose your connection during a synchronization, some of your data will likely have been synchronized and other data will not have made it. Regain your connection, resynchronize again, and you should be back to normal. More on the mechanics of Microsoft CRM synchronization will be covered shortly.

Using CRMSO In order to use the Microsoft CRM Sales for Outlook (CRMSO) client in online mode the user must be connected to their domain and have access to the Microsoft CRM and SQL Servers. Unlike the web browser client, CRMSO will not sense whether the user is on the domain and provide a login screen if they are not. Also, unlike Microsoft Outlook, CRMSO has no pop-up screen to ask the user whether they want to work in online or offline mode. This means that in order to use CRMSO while away from the office, a Virtual Private Network (VPN), Remote Access Server (RAS), or other connection method (which allows the user to access the domain) must be enabled. CRMSO will always open in the same mode as it was last used. For example, if you last used CRMSO in online mode, when you next open the application it will open in online mode. The mode only changes when the user clicks the “Go Online” or “Go Offline” buttons. Because of this, it will be important to provide training on the proper use of CRMSO with respect to connection modes. Difficulties will be encountered if, for example, a user disconnects her laptops to catch an airplane only to find out that she was last connected in online mode and now cannot access her data remotely. In fact, in this situation, it really does make sense that the user should have clicked “Go Offline” before leaving for the airport. Doing so would have performed data synchronization and put the application in the correct mode. Regardless of the processes that should be followed, any administrator worth their salt will know that users frequently venture outside of standard processes. When this happens, it is helpful to know that there is a registry key that keeps track of CRMSO's last connection mode. The key is labeled RCOffline and can be found on the CRMSO machine under HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSCRM. A value of “1” means CRMSO is working in offline mode and a value of “0” corresponds to online mode.

Scalability

Scalability with respect to offline data synchronization refers to the capability to support a large number of users. As you can imagine, the process of synchronizing a data set is very resource intensive, both in terms of the processing happening on the CRM server and in the demand on network bandwidth.

The best advice is to always perform your initial synchronization while connected directly to your corporate network, preferably in the same location as your CRM server is housed. What you are going for here is the best connection you can get while your computer is initially loading your data set. From there on, all your synchronizations will be incremental.

TIP Think twice about implementation strategies that will require users to synchronize data over a dial-up connection. Microsoft CRM synchronization, like most disconnected solutions, does not perform well over dial-up connections.

The next best piece of advice is to synchronize often and to be frugal about the amount of data you take offline. By synchronizing often, you are minimizing the amount of data that needs to be shuttled between your computer and the CRM server. Furthermore, you are decreasing the probability of data conflicts. If you wait a long time between synchronizations, you will have more data to move, resulting in a higher probability that the records you have changed have also been modified by online users. Limiting what you synchronize is also extremely important, especially when it comes to file attachments. Because Microsoft CRM stores file attachments in the database, the size of your CRM records can be very large. This is why the go offline button gives you several options allowing you to filter attachments.

Database Overview Up to this point, we have referred to either the main CRM database or the user's local CRM database. In reality, Microsoft CRM installs four databases on the server and two on the user's local machine. These databases are described in Table 8.5.

Table 8.5. CRM Databases

Database	Location	Description
*MSCRM	Server	The central database that holds all transactional CRM information including Leads, Accounts, Contacts, Opportunities, and so on.
*METABASE	Server	The central database that holds all data that describes the transactional CRM data. This includes field names, pick list values, workflow rules, configuration settings, and so on.
*CRMCRYSTAL	Server	The central database that holds data used by the Crystal Reports engine in generating reports. This database does not hold a copy of transactional CRM information for reporting. Rather, it holds a list of Crystal objects needed by Crystal in report generation.
*MSCRMDistribution	Server	The central database used by SQL Server replication to track the status of replication.
mscrm_msde	Client	The user's local database of transactional CRM information.
metabase	Client	The user's local database of meta data. This database is analogous to the METABASE database on the CRM server.

NOTE All server database names are prefixed with the Organization name that was entered during the Microsoft CRM server installation. For example, if you enter c360 Solutions as your Organization Name, your transactional database will be named c360_Solutions_MSCRM. This design will be effective when multiple CRM databases are housed on a single server for hosting purposes. Having four separate databases makes more sense when you realize that all transactional information is stored in the central MSCRM database. Looking at it this way, you can really think of it as two main CRM databases: MSCRM and METABASE. CRMCRYSTAL is solely for use by the Crystal Reports engine and MSCRMDistribution is created by SQL Server when you set up replication.