Workaround way to track if a user has done a Configuration Sync:
1) Pick a process that is completed on a frequent basis on Mobile Device (Ex: Closing a work order)
2) Add a "Config Sync Mapping" text field to the target object (Ex: Work Order object)
3) Within the chosen SFM process, add in this field to the "Mapping(s)" with a FIXED value.
Examples: Map fixed value "2/6/15 - 9am" to the new field "Config Sync Mapping" within the "Close Work Order" SFM Transaction
4) Wait a few days, and update this "fixed" mapping to "2/9/15 - 8am"
***This updated mapping will only populate if they have done a CONFIG SYNC after the update was made!
Update this mapping every few days to a new, unique FIXED value (Ex: today's date)
While this does not give EXACT sync times, you can still pinpoint between two "mapping updates" - time window depends on frequency of update!
5) Build a simple report that shows User/Technician and the associated "Config Sync Mapping" value
Basically gives you a date/time of "Last Confirmed Config Sync"
*Relies on this process actually being COMPLETED by the Tech (i.e. no closing calls = no mapping the config date)
This has helped us tremendously - I know that tech's doing regular config syncs is a reoccurring issue so I wanted to share to the Community.
(Shoutout to Stephen Lortscher for helping build this magnificent tool!)
If my explanation was not clear, or you have questions or IMPROVEMENTS, please let me know!!
I have done the same thing using the "ServiceMax Job Logs" object:
From this I can easily see when and how often each Technician has successfully completed a Config Sync in the last 30 days.
What I do not yet understand, is why my iPad users have 24 records created for each Config Sync, and my MFL users have 29..? From the above graph though, it is easy to see that Tech 2 (Green) did one Config Sync on the 22nd and 2 on the 25th.
If you add "Network Latency contains ." (a full stop) to the filter, you get an accurate sync count:
keep in mind that this requires sync logging to be turned on
For our org, this was not possible without significantly affecting sync times
(large global org, many sfdc users, 240 concurrent mobile svmx users ==> tons of concurrent requests to modify the same "job log" table at once, increased overall API consumption ==> higher sync times)
For the quantity question - although this is with respect to "Sync Request" and "Sync Request Record" object types, i believe that is what drives the sync job log object type:
Each sync "batch" will have one header, along with a collection of "Child" records
Header = "Sync Request" object type
Child = "Sync Request Record" object type
Those child records will be in two categories:
1) "static" - child records that pass user information needed for sync logic: sync type, profile ID, mobile config profile ID, last sync time, sync settings, userID, etc.
(will be the same number of records for every sync - but values within can change between users)
2) "dynamic" - child records that indicate actual record UPDATES or INSERTS since the last successful sync - will contain the changed/inserted record's field contents (in a pipe delimited format i believe)
*dynamic child records are only in the DATA SYNC batch - CONFIG SYNC batch will just have user information and should be the same size