Going back to a previous a Step based on the outcome of a flexi task


Badge +8

Hi,

Is it possible to go to a particular step based on the outcome of a flexi task? for eg: I have below workflow, where I have an "Assign Flexi-Task"  which has two outcomes. "Complete" or "Rejected". What i would like to do is, if the outcome is "Rejected", I would like to go back to the beginning of the Workflow. Is this possible? if so, how to do this using Nintex?

Untitled.png


34 replies

Userlevel 7
Badge +17

Most definitely. It is a very common process to do so based on a task. Simply use the State Machine. Have it with two branches and name them whatever is appropriate. Have it start on one side and place the task there. If the task is rejected, add a Change State action to the Same branch and it will in a way do a loop. In the Complete branch of the task you can have a Change State action that is set to end the state machine or go to the next branch for more processing. Look at this example.

172563_pastedImage_0.png

This is a State Machine for a simple leave request workflow. It starts every time in the Manager branch (the middle branch) for the approval of an Initiator created leave request list item. If the manager rejects, the state is changed to the initiator to give them a task to either change the dates of the leave request or cancel the request and quite the state machine and the workflow all together and skipping any needed approval. If the initiator changes the dates and wants to continue the complete their task and the state machine is switched to the Manager approval again. If the Manager approves then a the state changes to the HR branch and HR is provided a task to approve as well.

So we can keep this process going as long as necessary in order to get all the information so-so until final approval all thanks to the Mighty State Machine!

I hope this helps!

Badge +8

Hi Andrew,

Thank you for the detailed explanation. I will give this approach a try and let you know.

Best Regards,

Badge +8

Hi Andrew,

Here is my Business Process for which I am authoring this workflow.

  • An admin creates a list item with "Responder" people field filled out.  The person referred to in the "Responder" field will receive a notification informing him that he need to complete the list item with other fields that were left blank by the admin ( he just need to receive the link to the Edit form of the list Item).
  • Due Date is calculated based on Item created Date. It is usually 5 days from the Created date.
  • The Responder should start getting reminder emails if he did not complete the form 3 days before the due date and should continue to get the reminders until he is completed with the task.
  • The Responder or admin  should be able to delegate the task to other users.

Approach Followed (please suggest a better way to do this, if what I did below doesn't make sense).

As you suggested, I used State Machine and Change State Machine actions for what I want to achieve. Please see the swim lane below and the steps for my workflow are as follows.

1) I defined two states: "Task Assignment" and "Initiator".

2) The task is assigned in the first state of the state machine action i.e "Task Assignment".

3) There are couple of variables that are calculated prior to Assign Flexi task assignment (due Date and Assignee Display name).

4) There are two possible outcomes for the Assign Flexi Task (Complete and Rejected).

5) If the outcome is "Complete", then the status field of the list item that initiated workflow should be updated to "Complete" and send a notification to the initiator and ends the state machine followed by "End Workflow" action.

6) If the workflow outcome is "Rejected", then the status field of the list item that initiated workflow should be updated to "Rejected" and Change the state to "Initiator" (on the right side in the below swim lane).

7) once the state is changed to the initiator, a notification should be sent to the initiator that the task has been rejected.

8) Then, it should wait until an Item is updated and Status field of the list item is changed to "Not started" and then Change the state to Task Assignment and assign the task again.

Issues with above approach

1) when a task is rejected, the status of the list item that triggered workflow is not being updated,

2) It is not changing the state to "initiator" inspite of "change state" action defined and a  notification is not being sent to the initiator that the task was rejected.

3) it reassigns the task regardless of the status of the list item. We want to reassign it only when the status is reset to not started.

​Please advise,

NintexQuestion.png

Userlevel 7
Badge +17

Are you updating a list field for the status? Make sure it is its own field and not trying to update the workflow status. It is best to keep them separated. The state machine looks fine, except the End Workflow is not necessary. The wait for item update is not partial as you found. You could put a condition afterwards. If the status is what you need then switch to Task Assignment, otherwise switch to initiator and that branch will start over.

Badge +8

Hi Andrew,

Yes, am updating a list field for the status. i am not updating the workflow status.

sorry am not sure if I follow your advise regarding the condition placed afterwards. Can you please send me a swim lane so I can understand?

thank you for your help,

Userlevel 7
Badge +17

Sure, but let me back up in case I missed something. What was the specific job of the initiator if the task was rejected?

Badge +8

Hi Andrew,

if the task is rejected by the assignee, the a notification must be sent to the initiator that the task was rejected. We could either automatically update the list field status to "rejected" and then once the initiator decides  To reassign , he needs to update the status field to "Reassigned" and the. Task assignment state is executed.

let me know if this makes sense--or if you think of a better way to do this based on business problem I described above, I will be happy to try it out.

thank you,

Userlevel 7
Badge +17

That seems fine. You can have the Status field as a choice field too helping the user to only pick the right values. Then in the initiator branch, after the wait, use a Set a Condition action to see if they updated it to the value you need. The workflow can keep in the same branch is the status is not what you are looking for and even send another email to the initiator.

Badge +8

Hi Andrew,

I followed your suggestion and below is my swim lane:

The issues am having with this approach is:

  • When an Assignee selects the "Rejected" outcome of the task, the list item's status field is not updated to "Rejected".
  • The entire logic below Rejected Outcome from Flexi Task is being ignored which means "change state to initiator" is also being ignored.

Please advise why this is happening.

NintexQuestion.png

Userlevel 7
Badge +17

I'm not sure why it's not happening. Can you show a screen shot of the workflow history that includes the nintex status that is yellow and green showing the progress?

Badge +11

The state machine is great for when you want the workflow to move backwards or skip processes.

Badge +8

Hi Andrew,

Attached is the workflow History for the following sequence of user interaction.

1) A new item is created by the initiator.

2) The Assignee selects the "Task Outcome" as "Rejected"  in the email notification that he receives.

Issues

1) Once a task is rejected, according to the workflow logic under "Rejected" outcome, the List item field status should be updated to 'rejected" and the state should be changed to "Initiator"  and send a reject notification to the initiator. The entire logic under "Rejected" outcome is being ignored.

2) workflow works only if I select the task outcome as "Completed" .

NintexQuestion.png

Userlevel 5
Badge +12

Totally agree! State Machines can be used to build some powerful logical flows.

Badge +8

Hi Andrew,

I provided the information you requested. Please let me know if you need more information.

Thank you.

Badge +8

Hello,

I am still struggling with this issue. please advise. Is this a bug in Nintex or something not correct on my end? Nintex does not have a support call number to reach to. Community seems to be the only way to get a question answered.

Any suggestions are welcome to implement this.

Regards,

-Chaithanya.

Userlevel 6
Badge +12

Have you resolved this yet?

If not, try putting in a 'Log to history' action just before the 'Change State' action to see if it is going down that path as well as at the beginning of the other state (to ensure the change occurred). Also, you may need to add a 'commit pending changes' action when updating the status before jumping to a new state to ensure that your changes are posted back.

Hope this helps.

Badge +8

Hi Jesse,

I haven't resolved this yet. I will try your approach and also get the workflow history swimlane.

Thanks,

-Chaithanya.

Badge +8

Hi Jesse,

I tried this approach and the issue still persists: Below are the workflow history swim lanes for the two possible outcomes. when the Outcome is completed, the workflow path executes in the right direction. However, when the outcome is rejected, the entire logic under the "Rejected" outcome is ignored and the Task is being re-assigned without updating the field to "Rejected" followed by a reject notification to the initiator.

Outcome: Completed

completed.png

Outcome: Rejected

Rejected.png

Userlevel 7
Badge +17

So it seems that nothing is wrong with the state machine, but the task must be misconfigured or corrupted. Can you show the configurations of the task?

Userlevel 7
Badge +17

Maybe its the task. But can we see the end of the state machine? I want to make sure there are not other change state actions below the task. The last screen shot doesn't show the end of the workflow.

If you have two change state actions in the same path, the last one will be used, the first will be ignored

Userlevel 6
Badge +12

I was thinking something along the same lines. You may have to recreate the task action and then once configured, move the other actions into the proper line.

I had a similar issue before where I had a task action that I removed the default choices and supplied my own. When the workflow executed it would go down the wrong path. I ultimately had to recreate the task and move the actions into the proper paths.

Badge +8

Hi Andrew,

Below is my task configuration.

176189_pastedImage_1.png

176190_pastedImage_2.png

Badge +8

Hi Andrew,

Below is the end of the state machine Swimlane:

176191_pastedImage_0.png

Thank you.

Badge +8

Hi Jesse,

I tried this several times, however, I will give another try.

Thank you,

Badge +8

Hi Sally,

Thank you for your response. I will give this a try and let you know how it goes.

Thank you.

Reply