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

Question

Hi Appian Team, 
 We have a functionality to save the data from the interface to the database where we are not submitting it to the parent table, but a temporary table or cdt and use the same process model as the submit and add the nodes for temporarily saving feature like save as draft. 
 Basically customized "Save as draft functionality". Can anyone help us to implement this functionality , if you have come across similar features in any of your application. 
 
 Thanks 
 Sunu Sam

Mike Schmitt · Answer

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.

Mike Schmitt · Answer

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:

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

Top Replies