In first scenario, when you manually set Status to Assigned? do you also set assignee value? The notification is probably not triggered because assignee is null.
First the user selects the status field and chooses as Assigned, saves the task. Then selects the Assignee manually and again saves the task.
But don't we think there should be a validation in the tool itself to see when the task is set to Assigned and the assignee is NULL, it should not be allowed to save the task? i agree the group is already selected for it to be in Assigned status still.
1 of 1 people found this helpful
Just like in other applications, Individual assignments aren't mandatory, however (again, just like in other applications), automatic assignment is configurable (via TMS:AssignmentConfiguration).
Was there any difference in value of Notify Assignee between those two examples?
In Scenario 1, there are two Save operations?
First status saved as assigned and second assignee set and record saved.
I am wondering is assignee is not set, why status is saved as assigned first.
2 of 2 people found this helpful
V V wrote:
Below are the 2 scenarios of task assignment.
Scenario 1: when the task status is in "Pending" and status reason is "Assignment", user opens the task and changes the status to "Assigned" and saves it.
After that user selects the assignee and saves it. During this time, the task assignee notifications are not getting triggered.
Can some one please let me know why the task assignee notifications are not getting triggered in the scenario 1?
It is because individual task assignee notification gets fired by FILTER TMS:TAS:Notification_AssignedToIndividual_CallGUIDE
with Run If Qualification:
'DB.Status' != 'Status' AND 'TR.Status' = "Assigned" AND 'Assigned To' != $NULL$ AND 'Assigned To' != $USER$ AND 'Notify Assignee' = "Yes"
This qualification failed when you select assignee and save it because database and transactional 'Status' values are not changed.(qualification part marked in bold and italic).
Thanks Ganesh makes sense