Save UI values and bring it back when user need that again using process model ,something similar to save as draft for save button

The most common way I've seen this done (though it does have pros and cons), is for an on-task "save and exit" button to submit the form, save the values into the process instance PVs, then go back to the same task (either chained immediately back, or with chaining specifically broken, depending on how you want it to behave in particular). 

Thus instead of relying on a "temporary table" you've just stashed your data in the process PVs "early", presumably without a WTDS having been hit yet - to allow the user to reopen the task later and pick up where they left off.

HI Mike ,

Please share with us a sample code snippets so that we will get this in full form. Your help is appreciated! Thanks A lot for suggestion 

Thanks

Sunu Sam

Honestly not that much unusual code is required - just a particular configuration.  A basic version of this form might look like the following:

a!localVariables(
  local!variable1: ri!variable1,
  
  a!formLayout(
    label: "Test Task Input",
    contents: {
      a!textField(
        label: "Variable 1 (local variable)",
        value: local!variable1,
        saveInto: local!variable1
      ),
      
      a!textfield(
        label: "Variable 2 (rule input)",
        value: ri!variable2,
        saveInto: ri!variable2
      )
    },
    buttons: a!buttonLayout(
      primaryButtons: {
        a!buttonWidget(
          label: "Save and Close",
          value: "SaveAndCloseButton",
          icon: "save",
          tooltip: "Data currently entered into the form will be saved and the task will be returned to your task list.",
          submit: true(),
          saveInto: {
            ri!buttonClicked,
            a!save(
              ri!variable1,
              local!variable1
            )
          }
        ),

        a!buttonWidget(
          label: "Submit",
          value: "SubmitButton",
          style: "PRIMARY",
          submit: true(),
          saveInto: {
            ri!buttonClicked,
            a!save(
              ri!variable1,
              local!variable1
            )
          }
        )
      }
    )
  )
)

Note that in this example I've included an instance where an input is based on, and saves directly back into, a local variable.  Upon submit / save button clicks, the button itself would need to specifically save the value currently held in the local variable back into a Rule Input.  The one extra addition needed here which might not be needed for forms without a "save and close" style button, is that when the rule input is initialized, instead of leaving it null, we instead initialize it to whatever value (if any) is currently in the Rule Input, presuming that such has been passed back from the process.

Following the task, pretty much immediately, the process flow would pass through an XOR gateway, which would check the value passed out into a PV which in this example could be named "buttonClicked" - and if the value was "SaveAndCloseButton", it would route the process straight back to the form (but with activity chaining intentionally broken, if needed, so that the user's experience is that the task "closes").  That process flow could look something like this:

Honestly not that much unusual code is required - just a particular configuration.  A basic version of this form might look like the following:

a!localVariables(
  local!variable1: ri!variable1,
  
  a!formLayout(
    label: "Test Task Input",
    contents: {
      a!textField(
        label: "Variable 1 (local variable)",
        value: local!variable1,
        saveInto: local!variable1
      ),
      
      a!textfield(
        label: "Variable 2 (rule input)",
        value: ri!variable2,
        saveInto: ri!variable2
      )
    },
    buttons: a!buttonLayout(
      primaryButtons: {
        a!buttonWidget(
          label: "Save and Close",
          value: "SaveAndCloseButton",
          icon: "save",
          tooltip: "Data currently entered into the form will be saved and the task will be returned to your task list.",
          submit: true(),
          saveInto: {
            ri!buttonClicked,
            a!save(
              ri!variable1,
              local!variable1
            )
          }
        ),

        a!buttonWidget(
          label: "Submit",
          value: "SubmitButton",
          style: "PRIMARY",
          submit: true(),
          saveInto: {
            ri!buttonClicked,
            a!save(
              ri!variable1,
              local!variable1
            )
          }
        )
      }
    )
  )
)

Note that in this example I've included an instance where an input is based on, and saves directly back into, a local variable.  Upon submit / save button clicks, the button itself would need to specifically save the value currently held in the local variable back into a Rule Input.  The one extra addition needed here which might not be needed for forms without a "save and close" style button, is that when the rule input is initialized, instead of leaving it null, we instead initialize it to whatever value (if any) is currently in the Rule Input, presuming that such has been passed back from the process.

Following the task, pretty much immediately, the process flow would pass through an XOR gateway, which would check the value passed out into a PV which in this example could be named "buttonClicked" - and if the value was "SaveAndCloseButton", it would route the process straight back to the form (but with activity chaining intentionally broken, if needed, so that the user's experience is that the task "closes").  That process flow could look something like this: