How to raise a user friendly message when a user tries to open a task that is allocated (already opened by another user)

  • 15 February 2022
  • 2 replies
  • 46 views
A
  • Anonymous
  • 0 replies

Topic

In some cases during design of the workflow there is a need to have multiple destinations on a Task Event but once one of the destinations open the task it needs to be allocated to that user and removed from the other users worklist.

 

By default the below message will be displayed when the user tries to open the task page but there is a need to replace this message with something that makes more sense to end users.

10260iA9D3EEC96FA4AB16.png
This scenario is limited to the use of the below configuration on the Task event of the workflow
10269i0B2D2BC3D4C9021B.png

Instructions

To achieve the desired result the following configuration can be done to the form used as the TASK form in the solution.

 

1) On the form state used for the task form (Default will be Workflow Task State) add a new rule (When the Form raises an event)

10263i3659BCC04701A8E2.png

2) Add a condition to the new rule (an advanced condition is true)

10264i04F996E31EB34FAE.png

3) Configure the "an advanced condition" rule to check if the error message contains either of the following error codes with an OR statement

26031

24411

10265i86E42202F158A492.png

4)  Add an action to show a message and stop rule execution after showing the message. This message is the customized message.

10266iBBD0861FB44AA2EC.png

5) Add an ELSE condition, this is needed to complete the IF statement above and add the action "Continue to next execution" to the ELSE block

10267iC75034C749FAC5F0.png

 

Additional Information

During runtime the results will be a custom message is shown instead of the OOTB one

10268i9B51B271FD53D988.png

 

 

Related Links

 

 

2 replies

P

Hi there,


I wonder why you did not suggest to use the condition "Error occured".

From my perspective it gives you more detail and space to handle errors as well as lowering the impact of errors. 

E.g. in this case the condition could be used to give it more friendly view, but also transfer the general info into some variable and collect different errors before telling the user 1 by 1 what the encountered errors. 

Also there is one huge thing to be considered. The form event "in Error" means that the error has already happened in the past. While "occured error" condition can handle the error itself while going through the actions in the rule (e.g. calling the worklist item method to get new SN for new task, if available, or to load the form in e.g. read only state with no error message, but just info message about outdated task) 

Which does not mean I am not agreeing with you. I am just pointing on the difference between details that it could provide.



A

Hi Pavlous


 


Good question, I'm guessing you are referring to a similar setup form this article on the K2 community?


How to customize the error message when a user opens a task that has been actioned | Community (k2.com)


My initial thoughts was yes do it that way but in this specific scenario it did not fire hence the workaround above. There is a bug item logged to have this addressed in a future version. 


 


Regards


Vernon

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings