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

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

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.

Unknown said:

But, a task in a process flow itself cannot be cancelled.

You should be more specific when you say this, because I immediately think of all the use cases where this is very untrue.  I know you're thinking of cases where a process is started by user A and eventually assigned to user B for approval / data input / etc, and therefore we shouldn't allow user B to cancel.  But the way you've written it, implies that we also shouldn't include "cancel" buttons in instances where user A starts a process, gets a few steps in, and then they realize the process is not needed.  Any such step could (and should) include "Cancel" functionality, or else there will be abandoned instances to the moon and back.

The clarification seems to be, the submitting user can always Cancel on any of their submit steps (which ends the process and does not submit for approval/processing).  In any situation I have where the approvers or anyone downstream needs the ability to end the process negatively, this is Denied.  On a user input task where the user is saving for later, not yet submitting but leaving the task available for themselves, I typically use Save for Later.

In the end-negatively situations, I do most often suggest using Reject to the submitting user instead (or at least have this available along with Denied), where they can resubmit with any changes, or at this point the submitter can also use their Cancel functionality if they are not resubmitting.  I only include a Deny option when explicitly required, and it is not often.

Interesting philosophical rabbit hole ...

Let's see. What does "Cancel" mean? At start form level it means "Sorry, clicked wrong button". At task level, inside process flow, it means refusal to work. At business process level it means "we do not accept your request for loan".

This is how I think about it in general with only some rare exceptions.

I do almost never implement a "Save&Close" as this is too similar to "Save Draft".

When my task is "Approve Request", then I have some controls allowing the user to select the outcome and a single submit button to complete the approval.

Unknown said:

I do almost never implement a "Save&Close" as this is too similar to "Save Draft".

I've run into a lot of instances in the past where "Save Draft" is insufficient.  Mainly because when Appian created it, they didn't seem to think we needed any control over what the button does - it can't execute external saves, it can't kick off process instances (or do anything within the current process instance), and can't even force local variables to be saved into Rule Input values.

Unknown said:

At start form level it means "Sorry, clicked wrong button"

I guess my main point here was just that (especially as the initial user) this concept can extend many steps into the process flow, so isn't exclusively relevant to "Start Form" level.  I rarely (intentionally) use actual start forms due to flexibility reasons, preferring instead to set up an initial task as the obligate "start form", and always at least configure "cancel button" functionality here, but also extend that to any initial steps the initiating user does prior to any point-of-no-return (assigned tasks being kicked off, important DB entries being created, etc).