Form inputs disappearing

If what you're saying is that the inputs apparently work in Interface Designer, but have the "disappearing" issue when running from within a Process Model, then I'm 99% sure it's because you didn't map the Rule Inputs for the interface to ACP variables in the User Input Task. 

When in a running process, the rule inputs for the interface merely act as a bridge to the *actual* storage location for the on-form values, which would be the ACP variables.  So if there's no mapping, you can imagine that the on-form saves are saving into a nonexistent "vessel", and just go away.

Mike,
Really appreciate your answer. Is there any documentation that documents this process? All the training I have seen they are missing that important step... I am brand new to the platform so my apologies if some of my questions might sound a bit dumb.
Thanks again for the help.

I'm curious, does pressing Cancel do anything?

Can you give a little more description as to how you're currently kicking off the process instance and then accessing the form for said instance?

I am using the Interface Preview to fill out the form and click the submit button. Nothing happens with either cancel or submit.

I assume you're referring to the "preview" pane in the Interface designer, in which case we wouldn't expect anything to happen when clicking any button (other than executing any saveIntos set in the button definitions).  The "submitting" action of any button only takes effect when used from a live process instance, and will cause the process instance to proceed along its process flow lines from the node where the interface was housed, with one of two outcomes:

1. if there is no chaining or no subsequent User Input Tasks with an interface, the user will be taken back to the Site or Tempo tab from where they began the process flow;
2. if there is a subsequent task and activity chaining is enabled between the two, then the next form will load for the user pretty much immediately.

So my guess here is you're not actually using your process model yet.  The quick and easy way to experience essentially what a user would experience from your interface is, from the Process Model Editor, press CTRL+D (or, File -> Start Process for Debugging).  If you have a start form or activity chaining leading to an initial User Input Task, then you should immediately be shown a pop-up window with that interface loaded; otherwise you might need to right-click on the User Input Task (which would show up as green once the process flow reaches it), and click "View Form".  From here, pressing your "submit" buttons should take effect essentially the same way that they would for an end-user accessing the process in one of the normal ways.

a!localVariables(
  local!readOnly: ri!step="APPROVAL",
  local!labelPosition: if(local!readOnly, "ADJACENT", "ABOVE"),
  a!formLayout(
    label: if(local!readOnly, "Approve Expense Report", "Submit Expense Report"),
    contents: {
      a!columnsLayout(
        columns: {
          a!columnLayout(
            contents: {
              a!textField(
                label: "First Name",
                labelPosition: "ABOVE",
                value: ri!firstName,
                saveInto: ri!firstName,
                refreshAfter: "UNFOCUS",
                required: true,
                validations: {}
              )
            }
          ),
          a!columnLayout(
            contents: {
              a!textField(
                label: "Last Name",
                labelPosition: "ABOVE",
                value: ri!lastName,
                saveInto: ri!lastName,
                refreshAfter: "UNFOCUS",
                required: true,
                validations: {}
              )
            }
          )
        }
      ),
      a!textField(
        label: "Expense Item",
        labelPosition: local!labelPosition,
        value: ri!expenseItem,
        saveInto: ri!expenseItem,
        refreshAfter: "UNFOCUS",
        required: not(local!readOnly),
        readOnly: local!readOnly,
        validations: {},
        align: "LEFT"
      ),
      a!columnsLayout(
        columns: {
          a!columnLayout(
            contents: {
              a!dateField(
                label: "Expense Date",
                labelPosition: local!labelPosition,
                value: ri!expenseDate,
                saveInto: ri!expenseDate,
                required: not(local!readOnly),
                readOnly: local!readOnly,
                validations: {},
                align: "LEFT"
              )
            }
          ),
          a!columnLayout(
            contents: {
              a!floatingPointField(
                label: "Expense Amount",
                labelPosition: local!labelPosition,
                value: ri!expenseAmount,
                saveInto: ri!expenseAmount,
                refreshAfter: "UNFOCUS",
                required: not(local!readOnly),
                readOnly: local!readOnly,
                validations: {},
                align: "LEFT"
              )
            }
          ),
          a!columnLayout(
            contents: {
              a!fileUploadField(
                label: "Receipt Upload (up to 5 files)",
                labelPosition: "ABOVE",
                target: cons!tst_expenseReceipt,
                value: ri!receiptUpload,
                saveInto: ri!receiptUpload,
                validations: if(length(fv!files) > 5, "Only 5 attachments are allowed", "")
              )
            }
          )
        }
      ),
      rule!TST_enterComments(
        showWhen: ri!expenseAmount > 100,
        labelPosition: local!labelPosition,
        readOnly: local!readOnly,
        required: not(local!readOnly),
        commentValue: ri!comments,
        commentSaveInto: ri!comments
      ),
      a!radioButtonField(
        labelPosition: "COLLAPSED",
        choiceLabels: {"Approve", "Reject"},
        choiceValues: {true, false},
        value: ri!approve,
        saveInto: ri!approve,
        showWhen: local!readOnly,
        required: true
      )
    },
    buttons: a!buttonLayout(
      primaryButtons: {
        a!buttonWidget(
          label: "Submit",
          submit: true,
          style: "PRIMARY"
        )
      },
      secondarybuttons: {
        a!buttonWidget(
          label: "Cancel",
          value: true,
          saveInto: ri!cancel,
          submit: true,
          style: "SECONDARY",
          showWhen: not(local!readOnly),
          validate: false
        )
      }
    )
  )
)

Yep, that works great. Thanks again. With said 3 fields with data are empty when I view the task in Tempo - the first and last name and file uploaded...
Mike do you have any ideas why? I do get an error when I submit the form (see attached) and see the code attached as well.

antoniom0004 said:

With said 3 fields with data are empty when I view the task in Tempo - the first and last name and file uploaded...

Are you expecting something other than these fields being empty when the process is first initiated?

antoniom0004 said:

I do get an error when I submit the form (see attached)

I'm a bit stuck on this one - I might be able to help if I saw more detail as to your current process setup, testing steps, etc, but nothing immediately comes to mind.

I was expecting First and Last Name to be in the results...

This was just a test form Mike. Let's not spin out wheels here right now. I am building a form that will be part of a workflow testing and I will be using that formula you sent me to display other fields. I will be posting a few more questions on that.

Cool, hope things go well for you with that effort.

I think what's confusing is that when you design an Interface you define the rule inputs and they hold the values as they're set in the Interface Designer, which lulls you into the false security that they are in fact variables. But in reality they;'re not, they're references (pointers) to variables in the actual implementation. So when you type in a value in the Interface in a User Input Task the values have to be stored somewhere and that somewhere are what's called 'Activity Class' variables (effectively private variables defined in the 'Data' tab of the User Input Task.) And even then they won't end up in Process Variables sunless you map them from the ACs to the PVs.

I use the following diagram to try to illustrate the relationships between process variables, activity class variables and rule inputs:

Stewart,
I understand what you are saying and see a screenshot of the 'Data' tab you were referring to. I noticed that the first and last name 'value' field were blank, now when I try to save it I get An unknown error has occurred while saving the process model

Hi @antonium0004,

I had the same issue. Not sure if you have it solved.

Notice the value. (ri! can be rule input or a local variable)

a!textField(
label: "ID",
labelPosition: "ABOVE",
value: ri!ID,
saveInto: ri!ID,
refreshAfter: "UNFOCUS",
validations: {}
)

Hi @antonium0004,

I had the same issue. Not sure if you have it solved.

Notice the value. (ri! can be rule input or a local variable)

a!textField(
label: "ID",
labelPosition: "ABOVE",
value: ri!ID,
saveInto: ri!ID,
refreshAfter: "UNFOCUS",
validations: {}
)