Limits of offline
Offline-enabled Cases operate under the assumption that the server is unavailable or might become unavailable at any time. In Pega Platform™, only a select subset of features are available in an offline-enabled Case to support user actions that are in this state. Accepting and working within these limits helps to ensure that your offline scenario works reliably and is easy to maintain and upgrade. Working around these limitations introduces significant risk.
Simplified user experience
Offline-enabled tasks should not ask more of the user than is necessary for them to perform their task in the field. Similarly, a Case should display only the data that is necessary to perform the task. Aim to simplify and streamline the user experience as much as possible. Before designing your offline user experience, review the Offline-supported controls that are available. Pega Platform does not support custom controls for offline. As a best practice, use design templates and more prescriptive design tools.
Limited action set
Before designing an offline-enabled Case, review the set of Offline-supported Actions as a best practice. Pega Platform supports a large set of Actions but does not support all Actions nor honor all Action configurations. Only Case Actions are recorded, persisted, and played back on the server. Other Actions do not persist their changes to the Case unless users follow up with a Case Action that commits the changes. You might also have Actions that run only on the offline mobile client or the server. Activities, for example, only ever run on the server, while certain validation or Data Transform Actions might run only on the offline mobile client.
Back-to-back Case processing
Ensure that offline-enabled Cases consist of a set of back-to-back tasks. Pega Platform supports logical branching through decisions but cannot support parallel Tasks and other Case processing features offline. Before you design the flow of an offline-enabled Case, review the Offline-supported flow processing features. Otherwise, processing features without offline support halts the offline user experience until the server can process the Action and update the client before the user resumes work on the Case.
As a best practice, avoid updating remote systems in line with your offline Case process. Either update remote systems as an asynchronous task or hold off on remote system updates until all offline portions of a Case are complete. Updating remote systems during offline Case flow often greatly compounds performance and uptime issues. The system typically replays offline Actions in bulk, and failures with updating remote systems also fail the synchronization. In this scenario, the offline client attempts to replay the same Actions until the server successfully processes them.
It is best to adjust the design of your Case to work within the limits of what is possible with Offline. Pushing those limits with excessive customization introduces a lot of risk for Offline projects. It is almost always possible to validate, correct, and propagate data outside of the Offline Task that the user in the field is trying to complete.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
Want to help us improve this content?