Overview

You can design specific actions to be available to users of the Appian for Mobile Devices application when they are not connected to the Internet. This allows users to start processes when they are offline and queue them for automatic submission when their devices regain a connection. Offline actions can be made available in Tempo for iOS and Android.

The sections below describe how to design actions for offline mobile use. Before you get started, make sure that offline mobile is enabled on the environment in the Appian Administration Console.

Making Interfaces Available Offline

The first step to designing an action for offline mobile use is to create an interface that will be used as the start form for the action. The interface must be designated to be available for offline in order for the action to be available offline.

To make an interface available offline, open the Interface Properties dialog in the interface object 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.

You may also start with the Example Offline Form template. Learn more about starting with a template.

Designing Interfaces for Offline Use

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 on interfaces only functions as expected when users are online and may cause confusion when they don't function as expected when users are offline.

Avoid using the following components when designing interfaces for offline use.

Component	Offline Behavior
Image	Images do not render when offline.
Links	Links render when offline, but users cannot interact with them. 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.

Use of the following component when designing interfaces for offline use should be limited and carefully considered because its functionality is limited when offline.

Component	Offline Behavior
Paging Grid	The grid renders, but paging and sorting do not function when offline. Images in the grid do not render when offline.

Follow these additional guidelines when designing interfaces for offline use:

• Limit the use of validations. Validating user input on forms requires a connection, so users will not see any validation messages until they regain a connection. The exception to this is validating for required fields. Requiredness validations do not require a connection unless the validation is in a validation group.
• Avoid dynamic behavior based on user input. Dynamically populating an initial interface is fine because the initial interface will be evaluated and cached on users' mobile devices before they go offline. However, avoid triggering dynamic behavior based on user input because that dynamic functionality requires an Internet connection. The following examples are some dynamic design patterns to avoid:
  • Using cascading dropdowns
  • Making a component required based on a user's selection
  • Setting the default value based on a user's input
  • Adding multiple components dynamically
  • Showing or hiding a column or section dynamically
  • Adding or removing rows from an editable grid
  • Drilling down from a chart to a grid
  • Filtering data in a grid
• Limit the use of dynamic initial values. If initial values for fields are populated dynamically (e.g., by a query) and change often, users' forms may become outdated if they are offline when the values change. If highly dynamic initial values are an essential part of the form, then the form may not be a good candidate for offline use.

Testing Offline Interfaces

Testing of offline interfaces is best done directly on a mobile device that is offline. Once you have defined an action start form with an offline-enabled interface, take the following steps to test your interface:

1. Install the iOS or Android Appian for Mobile Devices application on your mobile device.
2. Add an account connecting to the appropriate server containing the offline action.
3. Tap Actions in the app.
4. Put your device in Airplane Mode and disable Wi-Fi.
   • The Offline banner displays.
5. Tap the action that you want to test.
6. Fill out and submit the form to queue it for submission.
7. Turn Airplane Mode off.
   The action submits automatically unless there are validation errors that require further attention.

Change Management

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.

Configuring a Start Form for Offline Use

To make an action available to users when they are offline, the following must be true:

• Only the parent rule used in the form expression needs to be configured to be available offline. The interface rule that is used to define the form expression may contain nested rules that are not configured to be available offline.
• The form expression must be configured using Interface Designer. If the action or task is called from the "Write an Expression" option in the process modeler, the expression must contain a single interface rule that is configured to be available offline. If the expression contains a non-interface rule, multiple rules, or an interface created directly in that editor, it will not be available offline. If you need to use a rule to query data to provide as a rule input to the start form interface, define a process variable with the rule as the definition in order to avoid having multiple rules in the form definition.