Hi,
I have a Process model for HR approval. In the form I am capturing cancel and submit button values in a text rule input (buttonValues).
But when HR is cancelling the button the flow gets completed which I do not want to happen as the task not completed.
I want the flow to stay at the same position so that approver can again complete his task.
could someone please help me here how to achieve my goal?
Thanks
Faisal
Discussion posts and replies are publicly visible
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?
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?
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.
faisalf0003 said:I changed the name of the button variable but result is same.
Based on the prior screenshot, your button variable is not considered in the XOR gateway so this would not be expected to cause any change in behavior under your current configuration.
Will this screenshot help you suggest me further?
This suggests that the value of pv!approvalDecision is probably not being changed by your User Input Task. However what I really wanted to see was the list of current Process Variable values, seen in the Properties box.
Here you will be able to see and confirm whether this PV actually contained any value in your process instance. This is the least we need to know to begin troubleshooting.
After that we will need to confirm that your user input task's interface setup (on the "Forms" tab) is actually saving the value from the form into the ACP.
This screenshots are:
Hope this time I am correct in sending all details
For your top screenshot - what I was looking for is the list of PVs from the process instance (the one where you weren't sure why the process flow routed to the end node). Instead you've shown us the list of PVs in the process model, which doesn't answer our question.
My Apologies!
Here we go.