We have a screen flow which has 4 assignments in it. This flow is configured as a sub flow from a flow which is the first process in the first stage of a case. The case type has "Enable Offline" checked and also the access group has "Enable offline support" checked.
Now we create the case and then the application goes to offline mode. By this time the case has reached the first assignment of the screen flow. Now keeping the browser/application in offline mode when we try to proceed to the next assignment of the screen flow the system/application hangs and no processing is done. The actions buttons that are been used are the Pega OOTB buttons which have "Finish Assignment" configured by default.
Nothing is configured in the pre and post data transform or activity and neither any validations are present in any of the flow actions. We are using Pega 7.3.0. Also we are trying it through desktop browser.
***Edited by Moderator Marissa to update categories***
First of all, testing 'offline' on a desktop browser is invalid. This needs to be tested on a custom mobile app.
Second, not sure what you mean by "Now we create the case and then the application goes to offline mode. "
When you mark a case as offline, then even if you are 'online' meaning you have server connectivity through a mobile app, the device will still behave as though your are 'offline'. You do not need to specifically 'go' into an offline mode to invoke offline capabilities(as long as case is offline and accessgroup is marked offline).
So test your screenflow on a mobile client first, if you still witness the problem, you should share a demo app in a demo ruleset, so that we can test it locally as well and give you more specific feedback on your setup and confirm if there is a product bug that needs to be addressed.
I agree with Sunny's direction as your best first step action. The debugging that will follow in regards to the mobile device behavior will focus on what action appears to "hang". We can discuss general offline case behavior and possible culprits but having tangible failure point will be very helpful.
Having a demo app and demo ruleset will be critical to look at things such as server timestamps, work party classes and perform harnesses in play.