Process model related issue

Hi Faisal

When you select any button in a user interface you should pass a value related to the button selected from the interface into the Process Model. Immediately after the process model you should have an XOR gateway that tests that value and decides where the flow is routed to next.

The functionality you're describing above is not the expected behavior of a "Cancel" button.  If I as a user launch an action or a related action, the first form would usually have a "Cancel" button which, when clicked, I would expect to end the process with no changes made.

In your process, if one user clicks "Cancel" and ends the process, why wouldn't the expectation be that a different user can launch that action?  If it's something else, why do you have a "Cancel" button at all?

Hi Mike/Stewart,

May be I could not tell my issue in a proper way. 

I am here describing full issues with the screen shots with comments and doubts. Could you help me?

I have attached the same.Issue with Form Cancel button.docx

To add, there is no reason to Cancel a start form since no process has been created yet.  Remove that button and the user can navigate away if they do not wish to proceed.  "Cancel" is just a label for your buttonWidget which is submitting the form.

For your XOR, if you do not want the path to change (always save data), why does the XOR exist?

FYI you can just post screenshots (preferably small ones, like the ones in your doc) directly into comments here.  That makes parsing issues a little easier when a screenshot is required.

For your first screenshot: if a Start Form has a Cancel button, then the expectation is that the process instance will be started when the user clicks the Cancel button.  This is just how Start Forms work.  To enable "Cancel" functionality, you simply need to place an XOR node before your first User Input Task, which will check whether the user input was "Cancel", and if so, exit the process prior to doing any other processing.  Instead, you have the start form lead directly to a subsequent task, which I believe is causing behavior that goes against your expectations.

In cases like this, it might actually be easier to not use a Start Form, and instead have all activity contained in the first User Input Task (of course this depends on details of the use case that you may not have included).

For your second screenshot: the behavior for the XOR node pictured in your process flow seems to be 100% dependent on the value of "pv!approvalDecision".  If this PV has a value of TRUE, the process will flow on to the "Save Employee Details" node.  With any other value, it will flow straight to the End node.  What is the value of this PV in your pictured process instance?  Is your User Input Task configured to save a value into this PV depending on user input?

1. A Start Form will always start the process. So you don't need a 'Cancel' button the Start Form. Only have the button to submit the form. Your User can always navigate away from the form. If you want to allow the User to refresh/clear the form (i.e. clear the data they've entered) then have another button that sets all of the values the user has entered to null/empty/zero or whatever default values you want them to have, without having submit=true on that button.
2. Have you examined the value of pv!approvalDecision in the running instance of your process model to see what value it actually has? If it doesn't contain the value you expect it's likely that it's not making its way from the User Interface and into the pv! This can be caused by:
   1. not passing it from the form to the rule input
   2. not mapping the rule input to a User Input Task (UIT) activity class (AC) variable
   3. not mapping the UIT AC variable to the pv! variable

Hi Mike,

I will follow what u have suggested for screenshots .

When you suggest   "To enable "Cancel" functionality, you simply need to place an XOR node before your first User Input Task, which will check whether the user input was "Cancel", and if so, exit the process prior to doing any other processing."  I infer that upon cancelling XOR gate should take the flow to a terminate node? Correct me please if my understanding is wrong.

For your second question for second screenshot.

To All,

I think I realised I am using the same variable buttonValue for both Start Form and User Input Form.

could you suggest if this could be reason?

Thanks

Faisal

I changed the name of the button variable but result is same.

faisalf0003 said:

I infer that upon cancelling XOR gate should take the flow to a terminate node?

Yes - in this case End and Terminate configured nodes would function the same.

faisalf0003 said:

For your second question for second screenshot.

I was really asking what the current value of pv!approvalDecision is in the process instance in your second screenshot.  That would tell us whether it should have gone to the terminate node after the XOR gateway.  The screenshot you provided of the task configuration does verify that the ACP value is being saved into the PV, but that 1) doesn't tell us what the PV's actual value was in the process instance, and 2) doesn't confirm whether the interface Rule Input is correctly saving into the ACP.