Auto Submit Form

Certified Associate Developer

I have one interface with few questions on it, i want to set the timer as if user not completing this form in particular time period  it will get auto submitted or else he can attempt all the questions and submit the form in time on clicking submit button.

or without clicking on submit button how can we submit the form after particular time.

Thanks in Advance.

  Discussion posts and replies are publicly visible

Parents
  • You can use the exception time on that node but just to make it clear, it won't have any visual impact for the user who has that form open on his screen until an action has been taken. 

    You can configure the UIT to auto submit using exceptions and when the user attempts to submit it, they will see an error - "Task already submitted" 

    Also, with this approach, I don't think you will be able to extract any data from the interface while the user in middle of filling it. 

  • 0
    Certified Associate Developer
    in reply to Harshit Bumb (Appyzie)

    Thanks for the reply harshit... That is my concern actually iam not able to auto save this answer s in db... User will have to perform atleast single action on the form.

  • 0
    Certified Associate Developer
    in reply to priyankam1705

    Or can I do something like after given time can I skip the remaining question s and show "close" button to user.

  • 0
    Certified Lead Developer
    in reply to priyankam1705
    something like after given time can I skip the remaining question s and show "close" button to user

    this is the one thing that would be possible.  basically you could store the original time the interface was loaded (for any given instance of it being viewed), and use auto-refreshing variables to determine after a certain amount of time has elapsed, that the rest of the form is now un-fillable and the user gets a different target button to choose from.

    Note that this method would rely *either* on the time the form is loaded by the user (and reset if they close it and reload it again from their task list), or the time the task is assigned to the user (meaning time could potentially run out before they ever open it), but not both.

  • If you are trying to implement something like a timed quiz, where users will always be active when the form ends automatically, you may want to look into a!writeToDataStoreEntiy() and would have to implement on each field (or a helper rule which takes in the entire current CDT value and persists to the DB), called from each saveInto.  This would of course, log any answers as they are selected vs common UX which logs on submit instead typically.

    In which case you would likely want the timer value as an input to the interface, which determines if the questions should still be shown or a "Entry period has ended" type message with a Close/Exit button that does not perform any further saves.  You can also include a longer exception timer on the task (for process cleanup), to allow this message/button to show after "completion" for say, 24 hours (will be negated if they use the Close/Exit button).

  • 0
    Certified Associate Developer
    in reply to Chris

    Thanks Chris,

    hitting database on each field may be not a good practice where there are more than 20 questions, but will give a try. 

Reply Children
  • 0
    Certified Lead Developer
    in reply to priyankam1705
    hitting database on each field may be not a good practice where there are more than 20 questions

    presumably (when set up correctly) this should only be writing one row at a time to the DB for each individual question, so very minimal load overhead.  it would be different if there were hundreds of questions and it was causing a DB write to all of them for every single form interaction.

  • Thanks Chris,

    hitting database on each field may be not a good practice where there are more than 20 questions, but will give a try. 

    Agree with Mike, I would consider 20 questions with single DB writes on each answer very very low load, I can't even think of an amount of simultaneous users that I would consider high load using that setup - 10,000?

    More I see DB interactions causing notable performance when loading/reading a larger amount of data, especially if it is done frequently such as on form refreshes, etc.

    To note, I was recently running a load testing exercise and firing 6,000 light DB interactions in under 2 seconds without issues, Appian handled it just fine.