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

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.

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.

You never posted a screenshot of what your User Input Task is actually doing

The only difference between my Start form and Approval is that they differ by Approve and Reject Radio Buttons and values are saved in a boolean rule input.

1. The button values are saved in a text rule input.

Thanks

Faisal

I guess I was imagining you might post a screenshot of your actual interface (in the interface designer, and including an example of the user selection(s) being populated and including the rule inputs to confirm that the value is being correctly saved).  Though I'm not sure if this is still necessary after the prior shots you've provided.

I'm still unclear though - is something still not working as you were hoping?

Only loop back option is working Mike. I was given such requirement to implement where we have a cancel button and flow in approval form should not end if user cancels it. I want to know if we any other option are there to implement or only the loop back is the only option? I am happy the functionality is working fine if in case only loop back is a solution for this.

Here are the screen shots from UI

a!formLayout(
label: "HR Approval Form",
contents: {
a!columnsLayout(
columns: {
a!columnLayout(
contents: {
a!textField(
label: "First Name",
labelPosition: "ABOVE",
value: ri!empCollectDetails.firstName,
saveInto: ri!empCollectDetails.firstName,
refreshAfter: "UNFOCUS",
validations: {}
),
a!textField(
label: "Gender",
labelPosition: "ABOVE",
value: ri!empCollectDetails.gender,
saveInto: ri!empCollectDetails.gender,
refreshAfter: "UNFOCUS",
validations: {}
),
a!textField(
label: "Employee Type",
labelPosition: "ABOVE",
value: ri!empCollectDetails.empType,
saveInto: ri!empCollectDetails.empType,
refreshAfter: "UNFOCUS",
validations: {}
)
}
),
a!columnLayout(
contents: {
a!textField(
label: "Last Name",
labelPosition: "ABOVE",
value: ri!empCollectDetails.lastName,
saveInto: ri!empCollectDetails.lastName,
refreshAfter: "UNFOCUS",
validations: {}
),
a!textField(
label: "Phone Number",
labelPosition: "ABOVE",
value: ri!empCollectDetails.phoneNumber,
saveInto: ri!empCollectDetails.phoneNumber,
refreshAfter: "UNFOCUS",
validations: {}
),
a!textField(
label: "Sub Employee Types",
labelPosition: "ABOVE",
value: ri!empCollectDetails.empSubType,
saveInto: ri!empCollectDetails.empSubType,
refreshAfter: "UNFOCUS",
validations: {}
)
}
)
}
),
a!boxLayout(
label: "Box",
contents: {
a!radioButtonField(
label: "",
labelPosition: "ABOVE",
choiceLabels: { "Approve", "Deny" },
choiceValues: { true(), false() },
value: ri!approvalDecision,
saveInto: ri!approvalDecision,
choiceLayout: "STACKED",
validations: {}
)
},
style: "STANDARD",
marginBelow: "STANDARD"
)
},
buttons: a!buttonLayout(
primaryButtons: {
a!buttonWidget(
label: "Submit",
value: "Submitted",
saveInto: ri!buttonValue,
submit: if(isnull(ri!approvalDecision), {}, true()),
style: "PRIMARY"/*loadingIndicator: true*/

)
},
secondaryButtons: {
a!buttonWidget(
label: "Cancel",
submit: true(),
value: "Cancelled",
saveInto: ri!buttonValue,
style: "NORMAL",
validate: false
)
}
)
)

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