You can design specific user input tasks and actions to be available offline to the users of the Appian for Mobile Devices application. This allows users to complete stand-alone input tasks or start processes when they are offline, and automatically submit them when their devices regain a connection. Offline tasks and actions are in Tempo for both iOS and Android.
Offline tasks are available in Sites for both iOS and Android. Offline actions for Sites are only available on iOS at this time.
The sections below describe how to design user input tasks and actions for offline mobile use.
Offline Mobile must be enabled within the Appian Administration Console.
The first step to designing for offline mobile use is creating an interface that will be used as the form for an input task or as the start form for an action. The interface must be offline enabled in order for the input task or the action to be available offline.
To make an interface available offline, open the Interface Properties dialog in the interface object from the settings menu and select the Make Available Offline checkbox. Learn about setting interface properties.
When this checkbox is selected, an offline indicator appears in the interface object's header.
Currently, only static behavior is supported in offline forms. Thus, when designing an interface that will be used offline, the key thing to remember is that the interface should not rely on any dynamic behavior that requires an internet connection. Dynamic behavior only functions as expected when users are online and may cause confusion to users when they don't function as expected offline.
Dynamic behavior includes but is not limited to showWhen, validations (except requiredness), smart service functions, database calls, and conditional values.
Avoid using the following components when designing interfaces for offline use:
|Links||Links render when offline, but users can only interact with document download links. Interaction with any other links will result in network error. Start process links will also not function while the user is online on the mobile application if the interface is configured to be offline enabled.|
|Browsers||Browsers will render offline, but users cannot interact with them. For example, a document browser will render, but tapping on a folder does not display its contents and tapping on a file does not download it.|
|Org Chart||User photos in the org chart do not render when offline. Tapping on a user does not make them the focus of the org chart.|
|Pickers||Pickers do not provide suggestions as the user types in the field and therefore the user cannot select a value. Tapping on a selected item does not remove it.|
|Tags||Tags will not render and display only the tag label.|
|Billboards||Billboards will show an error message.|
|Gauges||Gauges will display as progress bars.|
Use of the following component when designing interfaces for offline use should be limited and carefully considered because its functionality is limited when offline.
|Read-Only Grid||The grid renders, but paging and sorting do not function when offline.|
Follow these additional guidelines when designing interfaces for offline use:
today()functions are often used as a default value in the
a!dateFieldcomponent, but won't appear as expected when viewed offline because evaluating the functions requires a server connection.
The best way to test offline interfaces is to do so directly on a mobile device that is offline. Once you have defined a user input form with an offline-enabled interface, take the following steps to test your interface:
Follow these steps to test an action start form with an offline-enabled interface:
Since users who do much of their work offline will often be without an Internet connection, it is possible for an interface they are working with to change while they are offline. If a form that a user is working with changes while they are offline, the change will be brought to their attention when they are back online and they will be given an opportunity to review and modify their form before submitting it. However, this should be avoided if possible in order to provide the best experience for users and to avoid unnecessary delays in submitting users' forms.
Make changes to forms seamless to users by deploying changes when the majority of users are not working offline and when they are likely to receive the changes before going offline again. This might be during night or weekends, but will differ depending on your organization and your use cases.
To make a user input task or an action available to users for offline use, the following must be true:
On This Page