Flows and subprocesses

In the context of offline-enabled mobile apps, flows and subprocesses have the following features:

• You can execute flows, including flows that create cases.
• You can expand flows, and only the following shapes are supported offline:
  • Assignment shapes.
  • Question shapes.
  • Decision shapes with decision tables, when rules, decision trees, decision maps, and simple Boolean expressions that run on the client.
  • Decision shapes that are the first shapes of screen flows.
  • Utility shapes that are at the end of the screen flow. The utility does not run when offline but becomes available online when the completed assignments are sent to the server during synchronization.

  When the flow reaches any other shape when offline, the flow processing stops.

When you design applications that use subprocesses, consider the following information:

• When offline, a subprocess can run for the current work item in the following situations:
  • The subprocess is in the main flow.
  • The subprocess consists of another nested subprocess.
  • The subprocess is located next to an assignment shape.
• Offline-enabled apps support changing the path of a flow based on likelihood values for connectors that leave a subprocess. When the results of two connectors match, the offline processing engine selects the one with the highest likelihood value.

Further application design considerations:

• When you build an application on top of another application, in cases that you use in offline-enabled mobile apps, save the flows from the original application in the class of the current application, and do not reuse flows instead.
• A worklist that is displayed in an application that users access with an offline-enabled mobile app must be of the Assign-Worklist class.
• You can create work with parameters.
• The pyWorkParty page is not supported in offline mode. Modify the logic in the application to not refer to this page.
• In offline mode, data transforms run automatically for preprocessing and postprocessing. Additionally, you can include custom JavaScript code to execute basic business logic before and after a flow action is rendered, by adding the JavaScript code into a custom user scripts bundle called pypega_ui_userscripts_offline. Functions of that code must be called within a try/catch clause. The JavaScript code that you want to execute before a flow action is rendered is always called after the ClientCache activity is called and before the DisplayHarness activity is called. Preactivities and postactivities can also run when the flow is synchronized with the server.
• You can use the JavaScript pega.process.flow.setFlowEndStatus() method to set a flow result. This method overrides the status that is set with a property in the end shape of the subprocess.
• Users can route assignments to other users. The Review page is displayed for the user to confirm the operation. The assignment is actually routed to a new assignee when the flow is synchronized with the server.
• The confirmation page that is used in cases is the one that is set on the pyStartCase flow.
• The latitude and longitude coordinates are recorded for assignments that are performed in offline mode.
• Both the client and the server processing date/time stamps are recorded for each assignment that is completed in offline mode. The datetime stamp in the audit trail is populated during data synchronization with the then current server date/time value.