Prevent "Save Draft" button from closing task on mobile

Certified Associate Developer

I have an app for site surveying equipment that produces a task which is going to be completed primarily on mobile, often offline. Since the task could take multiple days to complete I added the 'Save Draft' button to the interface from the process model. On desktop it works as expected, I can hit the save draft button, exit the task, then go back in and pick up where I left off with all the previous data still there. However, on the mobile Appian app, when I hit this button the data is saved properly, but the task then closes. Since I experience the occasional app crash with the Appian mobile app, I would like to be able to save my work periodically without having to exit the task each time.

Is there a way to prevent the 'Save Draft' button from closing the task in the mobile app?

Thanks in advance!

  Discussion posts and replies are publicly visible

Parents
  • 0
    Certified Lead Developer

    If your "save draft" button is configured to submit the form then loop back to the same task with activity chaining (such that the user thinks they haven't actually left the form) - then the behavior should work essentially the same on mobile (IIRC) as it does in a browser.  There could be something else going wrong causing the task to close for the user, but troubleshooting this would require a lot more detail.  When you test it from mobile, but monitoring it from the process instance monitor, is the subsequent task instance reached instantaneously and with no errors?  Is chaining consistently enabled through all intermediary steps?  Can you switch back and forth between browser and mobile and the behavior always follows that it works as expected in the browser and not in mobile, even within the same process instance?

  • 0
    Certified Associate Developer
    in reply to Mike Schmitt

    Mike,

    I am currently just using the built-in save as draft functionality that Appian provides by checking the box shown in the attached image. So it is not an actual button that I added to the interface and configured, and I have not implemented any loop in the process model for this. I have used this in previous applications and it works fine, but this is my first attempt to use it on a mobile app.

  • 0
    Certified Lead Developer
    in reply to Jack Ferguson

    Ah, sorry for misunderstanding then - I'm personally unfamiliar with the expected behavior of the OOTB "save draft" functionality when used in a mobile app.  If the behavior seems inconsistent in a way that you believe represents an error, you might raise the issue with Appian via a support case (but I assume some others here might have more insight as well, once more people see this thread).

  • 0
    Certified Associate Developer
    in reply to Mike Schmitt

    Alright, thank you. Worst case scenario, I can just create a button myself with the loop you described earlier.

  • 0
    Certified Lead Developer
    in reply to Jack Ferguson

    In the past I've found that I have to resort to that method more often than not.  Unfortunately since we have absolutely no control over what happens when the OOTB button is pressed, implementing your own is the only way to have real control over things like in-process behavior (particularly as it allows the data to be populated to the process instance, and when needed, saved to the DB). 

    The main caveat to this method is I assume the OOTB button is optimized to also work off-line, while the process loop behavior probably would not do so whatsoever.  Luckily so far I haven't had to deal with enabling offline mobile stuff, so that hasn't been an issue so far.

Reply
  • 0
    Certified Lead Developer
    in reply to Jack Ferguson

    In the past I've found that I have to resort to that method more often than not.  Unfortunately since we have absolutely no control over what happens when the OOTB button is pressed, implementing your own is the only way to have real control over things like in-process behavior (particularly as it allows the data to be populated to the process instance, and when needed, saved to the DB). 

    The main caveat to this method is I assume the OOTB button is optimized to also work off-line, while the process loop behavior probably would not do so whatsoever.  Luckily so far I haven't had to deal with enabling offline mobile stuff, so that hasn't been an issue so far.

Children
No Data