Process model related issue

Question

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

Mike Schmitt · Accepted Answer

Ok, so from here we can tell that pv!approvalDecision was not assigned any value in this process instance. Since the XOR gateway only goes to the 'Save Details' node if its value is TRUE, the execution in your screenshot is accurate. 
 From here you will need to check the configuration of your SAIL form and verify that the rule input associated with this value is getting set properly on-form. The screenshots you've already posted of your user input task configuration make that seem correct.

Mike Schmitt · Answer

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?

Mike Schmitt · Answer

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?

Mike Schmitt · Answer

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.

Mike Schmitt · Answer

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.

Mike Schmitt · Answer

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.

Mike Schmitt · Answer

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.

Mike Schmitt · Answer

Your pictured process flow should work correctly when a user clicks the button with a value of "Cancelled", if your desired outcome is for the task to go away for a moment but reappear on their task list when it's refreshed again. I still don't like the terminology "cancel" for this, but that's totally up to you as a design decision. 
 Is something still happening here that doesn't fit your expectations? 
 The only thing I supect might still be confusing you is, your Start Form (depending on what it does) might be redundant; if the User Input Task contains the only SAIL functionality you need, you can just route the user directly to the User Input Task upon launch of the process model instead of using a Start Form.

Mike Schmitt · Answer

faisalf0003 said: Could suggest me something better here please? 
 When implementing a button with functionality like what yours is doing, I sometimes use the label "Save and Close", or something similar depending on the particular situation, which should imply to the user that clicking this button will cause the task to go away but that it will be accessible again in their task list after that (which is the case here). 
 When doing this you should always assess whether this is actually needed, versus having the user simply navigate away from the task if they're not ready to complete it yet - for data entry, the button approach can help save user-entered data. For an approval form, though, I'm not sure what the value is in having the button for this purpose; if the user doesn't want to approve the current work item, they can simply click back to their task list or their site tab, etc. You never posted a screenshot of what your User Input Task is actually doing, so it's hard for me to tell what best approach to suggest here.

Mike Schmitt · Answer

faisalf0003 said: I want to know if we any other option are there to implement or only the loop back is the only option? 
 Sorry but I'm having a really hard time understanding what you mean. Can you simplify a bit for me? 
 
 Current Behavior, versus 
 Behavior you were expecting / hoping to achieve 
 
 Also: for your code, please look into posting your code in the Code Box ("Insert" --> "Insert Code") as this preserves formatting like indentation and keeps a long stretch of code from blowing out a single comment like has happened here. example code box

Process model related issue

Top Replies