It’s 9:00 am in the morning here and I have cracked open my customary Coke for the day. Yes I need that kick to get me going, hopefully I can get this monkey off my back but for now I and knee deep in my morning rituals. Among the rituals is reading the most current blogs and news to keep up with ‘”what’s new” and what I should keep my eyes on. With so much information it is sometimes hard to figure out which way is up. I think its pretty much the same when it comes with SalesLogix mobile synchronization and determining what the rules for synchronization are, and then being able to determine the best practices for an organization to enact to get the most of their mobile environment.

Over the last weeks I have been working with a Business Partner and their end customer, providing mobile customizations and support in getting the system up and running on an as needed basis. When on the phone with the end customer the discussion of how mobile synchronization works, and also how it relates to standard SalesLogix synchronization. We also discussed mobile subscriptions and how the terminology may easily be confused with SalesLogix remote subscription rules. So this post will try to break down the mobile synchronization process, hopefully in easily digestible pieces.

1. Mobile sync does not use standard SalesLogix remote synchronization

There is no direct relationship between the rules that are setup in the SalesLogix administrator remote synchronization. Mobile is a completely different animal and there is a true disconnect between these methods. Mobile synchronization does not consume TEF files or use any of the core SalesLogix sync infrastructure. In fact mobile synchronization is done based on a group query (more later) and a list of records that is already on the device.

2. Mobile sync uses standard SalesLogix security

The records that are available in the LAN client to the users are the same ones that are available to the mobile user. The same security constraints are applied to any of the queries that are executed through the sync. This includes the augmentation of the query to include user/team record reductions.

3. Only one group can be assigned for a user

In the mobile administrator a sync group is assigned for each user. This group can be any ad-hoc or dynamic group (the ones you can see in SLX LAN or Web) or the administrator can create one for you in the mobile admin. I actually rarely see the Admin created group being used in production but it is a nice feature to have. I do see that many times the group that is selected is the ‘All Accounts’ group is selected. I believe that this is not the best practice as it is possible to have tens of thousands of records to be synced which may cause some syncing pain.

4. Additional filtering is available on synced mobile items

Even though there is top level queries that determine what accounts/contacts should be synced the each table to be synced can even further be reduced by utilizing optional clauses, or for more advanced functionality “Sync Rules”. Optional clauses are used often, just look at History, or Activity in the Server2Client maps to see an example. I have not seen sync rules utilized in production as of yet and that could be due to the lack of documentation on the feature.

5. Mobile Synchronization rules are determined by the Client System

When determining the tables to be synced there are 2 map plug-ins (Server2Client and Client2Server) and any affiliated functions. Each user is assigned to a client system that determines the client functionality as well as the sync functionality. If you need special sync rules for a given user you either have to have a custom Client System or resort to sync rules (see above for lack of documentation)

6. Syncing “All Accounts” not really the best practice

When initially setting up the mobile system the focus should be on testing basic sync and ensuring that data is successfully sent to the device. If the initial sync group is “All Accounts” the sync process can be a considerable time to complete and to verify. I suggest setting up an “Mobile” ad-hoc group and add a few accounts. This way you can test the device communication to the server and ensure that the connector is running correctly with as little impact as possible.

7. Subscription comes to the rescue

Introduced in 5.0 was mobile subscription. With this feature a mobile user can choose the accounts that they want, while in the field and then sync them down to their device. With this feature you can avoid the “All Accounts”  issue completely, opting to get only the relevant records for the time.


I hope that this gives a little insight into mobile sync.


Leave a Reply