What Data Have Your Mobile Users got on Their Devices?

Visibility is key. When building, testing, and beyond into production, just having insight into what is going on with mobile users who may be thousand of miles away in different time zones, or developers working under pressure to strict deadlines, understanding the actual data which is being processed can be a lifesaver.

For every user/device (or emulated ‘devices’ for developers or testers using a CodeFlow Emulator or a Platform Emulator), you can see exactly what data was requested by each synchronisation, either at a table-by-table or record-by-record level.

To do this, navigate to the Connection Session tab and locate the Connection Session record which pertains to your user/device and for the Mobile Table you want to inspect.

Refresh ID List

Once located, open the Connection Session and look at the related lists. Locate ‘Attachments’ and in the list you’ll find an attachment called ‘idLists.txt’.

When you view this attachment, you can then see a JSON representation of how the sync engine handled the request in terms of the records that were queried, added, removed, updated, and those which had not changed and remain on the device.

As many of you will know, our pace of delivery has a good cadence. But we also have a substantial backlog to work through too! We have on roadmap a way to see these records as easily as we can see Updates (records which have been submitted to the platform from the device). For now though, the best way is to copy and paste the text from the attachment and use the JSON view found here.

Let’s talk through what we can see:

{

 ”ds” : { ‘ds’ – the delete set

   ”oq” : [ ], ‘oq’ – out of query id list

   ”sd” : [ ], ‘sd’ –  soft deleted id list

   ”hd” : [ ], ‘hd’ – hard deleted id list

   ”sh” : [ ] ‘sh’ – shared away id list

 },

 ”snm” : [ ], ‘snm’ – submitted records that have changed on immediate requery

 ”smt” : [ ], ‘smt’ – submitted recs that did not change on immediate requery

 ”rs” : { ‘rs’ – the refresh set.

   ”ns” : [ ], ‘ns’ – not sent to the device – they are already there and up to date

   ”st” : [ ] ‘st’ – sent to the device – new or updated records

 },

 ”rsdttm” : 1437224726738 ‘rsdttm’ – the epoch time of the platform’s query

}

Records being sent or already on a users device

To start simply, the best set to look at is the “rs” or Refresh Set. After a successful sync, these are the IDs of the Salesforce records we would expect to find on the user’s device.

This set is made up of two separate lists. “ns” – this set is records that are in query but have not altered (either through a modstamp change or a value change in a mobilised formula value). So these are not ‘sent’ but remain on the device.

The “st” are new records that are new ‘in query’ and have now been transferred to the device.

‘Within Query’ is the restriction on the Mobile Table. This is either a basic restriction using user and checkbox criteria, or advanced where we can use an interfaced Apex class.

Records requested to be removed from a user’s device

Finally we have records that are requested to be removed and these can be found in the parent set “ds”. The importance here is ‘requested’. Records will be removed by the device, but only if they haven’t been updated by the user or process. In other words, the update of a record on device moves it to a protected state, which until the Submit process has completed, means that values cannot be overwritten by a refresh of data from the platform.

The “ds” sets are fairly straightforward. “oq” means that current query (set either by configuration of a basic user/formula restriction on the mobile table or a platform class) was on the device and is now out of query, so should be removed.

“sd” means that the record is on the device but has now been deleted and moved to the recycle bin on the platform. “hd” is a hard delete, the record is no longer available on the platform at all.

“sh” – the record was initially available to the user on a previous refresh/read, however, the user now no longer has visibility as set by the org’s sharing rules.

Conclusion

From initial development, through to QA and UAT, understanding the data flow and data on each device, as well as data requested to be removed, is a massive benefit. Then once the app is deployed into production for troubleshooting and support, the same process can be used to diagnose at a user/device/record level. To see and learn more of the monitoring and visibility can bring to your mobile apps and projects contact us to request a Monitoring and Support Orientation Workshop.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to Top