Process model related issue

RE: Process model related issue

Mike Schmitt — Fri, 02 Jul 2021 19:39:05 GMT

[quote userid="62125" url="~/discussions/f/new-to-appian/21328/process-model-related-issue/83342#83342"]I want to know if we any other option are there to implement or only the loop back is the only option?[/quote]

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

RE: Process model related issue

faisalf0003 — Fri, 02 Jul 2021 19:33:48 GMT

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
)
}
)
)

RE: Process model related issue

Mike Schmitt — Fri, 02 Jul 2021 15:46:52 GMT

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?

RE: Process model related issue

Mike Schmitt — Fri, 02 Jul 2021 15:42:57 GMT

[quote userid="59361" url="~/discussions/f/new-to-appian/21328/process-model-related-issue/83330#83330"]I do almost never implement a "Save&Close" as this is too similar to "Save Draft".[/quote]

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.

[quote userid="59361" url="~/discussions/f/new-to-appian/21328/process-model-related-issue/83330#83330"]At start form level it means "Sorry, clicked wrong button"[/quote]

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

RE: Process model related issue

Stefan Helzle — Fri, 02 Jul 2021 15:31:10 GMT

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.

RE: Process model related issue

faisalf0003 — Fri, 02 Jul 2021 15:23:15 GMT

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.

The button values are saved in a text rule input.

Thanks

Faisal

RE: Process model related issue

Chris — Fri, 02 Jul 2021 15:02:13 GMT

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.

RE: Process model related issue

Mike Schmitt — Fri, 02 Jul 2021 13:49:39 GMT

[quote userid="59361" url="~/discussions/f/new-to-appian/21328/process-model-related-issue/83297#83297"]But, a task in a process flow itself cannot be cancelled. [/quote]

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.

RE: Process model related issue

Mike Schmitt — Fri, 02 Jul 2021 13:45:48 GMT

[quote userid="62125" url="~/discussions/f/new-to-appian/21328/process-model-related-issue/83290#83290"]Could suggest me something better here please?[/quote]

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.

RE: Process model related issue

faisalf0003 — Fri, 02 Jul 2021 09:39:04 GMT

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.

RE: Process model related issue

Stefan Helzle — Fri, 02 Jul 2021 06:11:24 GMT

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.

RE: Process model related issue

faisalf0003 — Fri, 02 Jul 2021 05:46:43 GMT

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

RE: Process model related issue

Mike Schmitt — Thu, 01 Jul 2021 20:55:56 GMT

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.

RE: Process model related issue

faisalf0003 — Thu, 01 Jul 2021 19:25:54 GMT

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

RE: Process model related issue

Mike Schmitt — Wed, 30 Jun 2021 18:44:50 GMT

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.

RE: Process model related issue

faisalf0003 — Wed, 30 Jun 2021 18:27:39 GMT

Hi Mike,

My Apologies!

Here we go.

Thanks

Faisal

RE: Process model related issue

Mike Schmitt — Wed, 30 Jun 2021 17:43:30 GMT

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.

RE: Process model related issue

faisalf0003 — Wed, 30 Jun 2021 17:18:49 GMT

This screenshots are:

Hope this time I am correct in sending all details

RE: Process model related issue

Mike Schmitt — Wed, 30 Jun 2021 17:07:57 GMT

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.

RE: Process model related issue

faisalf0003 — Wed, 30 Jun 2021 16:53:11 GMT

Hi Mike,

Will this screenshot help you suggest me further?

RE: Process model related issue

Mike Schmitt — Wed, 30 Jun 2021 16:47:39 GMT

[quote userid="62125" url="~/discussions/f/new-to-appian/21328/process-model-related-issue/83174#83174"]I changed the name of the button variable but result is same.[/quote]

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.

RE: Process model related issue

Mike Schmitt — Wed, 30 Jun 2021 16:36:37 GMT

[quote userid="62125" url="~/discussions/f/new-to-appian/21328/process-model-related-issue/83172#83172"] I infer that upon cancelling XOR gate should take the flow to a terminate node?[/quote]

Yes - in this case End and Terminate configured nodes would function the same.

[quote userid="62125" url="~/discussions/f/new-to-appian/21328/process-model-related-issue/83172#83172"]For your second question for second screenshot.[/quote]

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.

RE: Process model related issue

faisalf0003 — Wed, 30 Jun 2021 16:35:54 GMT

I changed the name of the button variable but result is same.

RE: Process model related issue

faisalf0003 — Wed, 30 Jun 2021 16:30:42 GMT

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

RE: Process model related issue

faisalf0003 — Wed, 30 Jun 2021 16:19:49 GMT

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.