Screen flows in offline mode

You can use screen flows to perform back-to-back assignments when working in offline mode.

  • Decision shapes with Boolean expressions (no when rule) are supported.
  • Screen flows can contain only assignment, or simple questions shapes. If the flow contains any other type of shape, offline users cannot continue past the assignment that precedes the unsupported shape. In addition:
    • The only exception is a decision shape based on a simple expression that is run on the client, as well as, a decision shape as the first shape in the screen flow. Only these decision shapes work in offline mode.
    • Utility shapes can be at the end of the screen flow. The utility does not run when offline, but becomes available online when the completed assignments are synced to the server.
    • Other than the decision and utility shapes, only assignment shapes can be performed while offline. If any other shape is reached, the flow processing stops when offline.
  • Data transforms automatically run in offline mode for pre-processing and post-processing. Otherwise, you can include custom JavaScript code to execute some basic business logic before and after a flow action is rendered in offline mode. This is accomplished by adding your own JavaScript code into a custom user scripts bundle called pypega_ui_userscripts_offline. Its functions must be called within a try/catch clause. The JavaScript code to be executed before a flow action is rendered is always called after ClientCache and before the DisplayHarness is called. Pre-activities and post-activities can also run when the flow is syncing to the server.
  • Back-to-back assignments are supported, but you must use the default Back button in the screen flow harness. The Back button returns you to the previous assignment as defined in your screen flow.
  • You set a flow result by using the JavaScript pega.process.flow.setFlowEndStatus() method. This method overrides the status set using a property in the subflow's end shape. The offline process engine takes into account the likelihood setting if the flow result is conflicting or is absent, provided it is not in a subflow.
  • The completed datetime recorded in the audit trail is the datetime that the assignment completes on the server when the item is synced when back online.