Working on mobile devices is supposed to be fast and handy, so there is nothing worse than stumbling upon a broken form with the evil spinning timer on it. You check the Wi-Fi, you check the local network, everything works, your phone is connected, the SN app logs you in as usual and also loads the navigation menu, but your incident form is lost in hyperspace. This can happen on any task-extended form that uses the activity formatter.
How to avoid broken forms on a mobile device
The scope of this post is not to troubleshoot the app connectivity or database issues on the server side. Once we have ruled out problems on the back end, we must know that the app is failing to render just the form, because it is looping or stuck on specific elements of the form layout.
Since the introduction of UI16 and recent plugins like Presence, the incident management engine has changed considerably, and the Incident form loads in the background the Activity Stream in order to handle real-time updates on the activity log journal, as well as to enable the stream feed quickly enough on the Mobile UI.
It is possible to disable UI16 from System Configuration > UI Properties, but definitely not recommended, as the application would lose most of the advanced features in incident management.
For platform performance and architecture design reasons, the journal log of an Incident or other Task record is obviously not stored in the [task] table itself, but in [sys_history_line] and [sys_audit] partitioned table shards. These are not accessible directly, but linked to the task record through its sys_ID, and retrieved temporarily while accessing the task record. The retrieved activity history is placed into the buffer table [sys_history_set], as described in the History Sets product documentation.
All this background activity happens on the server side, and an Incident form with the activity log properly loaded on mobile view should look like this:
The form loads the main elements first, like Incident Number, Company, Priority, and then loops through the history audit data to build and render the activity log entries. Once the queries are completed on the server, if the form fails to transpose the activity log into its elements, we experience the empty sinister form with the endless spinning circle.
Why is the form failing to load?
There could be several factors causing the form to struggle loading. For example, there could be a large amount of CMDB data for the particular configuration item related to the incident. Other reasons could be a reference field to a large table taking time to populate the drop-down list, or particularly rich content in an HTML field.
The mobile interface tends to hide standard error messages that would otherwise display on the standard UI. This is due mainly to avoid to overpopulating the screen and, unfortunately, can be frustrating and misleading for the mobile user. However, the loading would eventually time out in such a circumstance. Whilst the main cause for the blank form stuck in endless loading on mobile is a wrong configuration of the Activities (filtered) element, this should always be placed in block with the Additional comments (Customer Visible) and the Work notes elements.
For example, a correct form configuration in the Notes section would show like this:
If the Additional comments are split from the Work notes in your layout configuration, the issue will occur in your mobile view.
A typically incorrect configuration in a form section, for example, with the Work notes alone added in the bottom, would display as the following:
After saving such a configuration in the standard (not mobile) UI, the form layout will still render, but will omit the Work notes. When switching or accessing in Mobile UI, the rest of the form layout will not be loaded, showing the spinning circle.
As we see, the Mobile UI is generally less robust than the standard UI. Keeping the mobile view of any form light and with less elements than the default desktop form is always good practice. If you run into the issue of a task form containing the activity log journal failing to load, check the layout configuration and make sure the Additional Comments, Work Notes, and Activities (filtered) elements have not been split from each other. These will need to be displayed together within the same form section.
