Process model related issue

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.

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.

Hi Mike,

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 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.

Hi Mike,

My Apologies!

Here we go.

Thanks

Faisal

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.

Hi Mike,

One of your old replies I saw for the similar issue where you had suggested for loop back.

Appian Community

I have implemented the same. I need your view if it is correct or not?

My observation:

I noticed that the approval form opened in action tab due to activity chaining but when I cancelled the form it went to Task tab and opened again and cancelled and it remained there until I submitted with some values.

To me it seemed that it had worked.

Could you please suggest if this is a correct behaviour?

Thanks

Faisal

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.

The start form is used to collect the information and ideally I should have kept the 2nd Form which is an Approval Form as read only.

You mentioned "I still don't like the terminology "cancel" for this, but that's totally up to you as a design decision. "

Could suggest me something better here please?

Currently, I am working on some kind of assignments. I have definitely some bandwidth to include the changes.

Thanks

Faisal

To add my 2 cents to this story, a task in a process should never have a cancel button. At least not in terms of that it stops the functional process. Each task must have some business value as outcome. If the business process includes a "non-happy" ending, then this must be implemented.

But, a task in a process flow itself cannot be cancelled. This would be the same as a refusal to work!

Regarding start forms, I always include a cancel button (and the xor in process). In my experience this "just navigate away" pattern is not understood by many people.

Yes Stefan,

I have implemented the logic for Start form as you have suggested.

Thank you and Mike and everyone here. I had a nice experience for this issue.

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.