<< Click to Display Table of Contents >>
Navigation: Bizagi Studio > Process wizard > Performers > Work allocation components >
Details on assignment to Everyone
In Bizagi Studio, a developer of a process configures the performers of each task in order to assign the activity to a specific set of users according to the rules defined. There is a special case of this assignment, the Everyone method. Such option marks everyone (who matches the preconditions) as a possible performer for the task.
There are important topics when using this assignment method, which will be addressed in detail across this article along with important considerations of its use. Those topics include:
•Behavior of assignment.
•Ownership of the task.
Assign to everyone - Unassigned
When this assignment method is chosen, whenever the task is reached in the execution flow of the process, the Inbox of each user that matches the preconditions configured on the task will show the activity as available. Initially the task will not have a performer assigned, thus the assigned user will be labeled as Unassigned.
In the next section of the article you can find information related to the assigned performer once someone opens the task or marks himself as assigned, that is, after taking ownership of the task.
Assigned performer - Take Ownership
As previously mentioned, when the Everyone assignment method is selected for a task, all users will have the activity available on their Inbox but no one will be actually assigned as responsible. Then, who is it assigned to?
By default Bizagi is configured to assign the task to the first user who opens it (or click the Work on it option. There is an additional option to this behavior known as the Read Only View.
When enabled, if a user clicks the Work on it option or enters the activity, he/she can review the forms and the actions that need to be performed, but the task will not be assigned to him/her. In order for a person to effectively be assigned to the task, he/she will have to access the Read Only View and then click on the button displayed on the upper right corner of the task, labeled as "Take ownership".
Once the task is assigned to a user, the behavior of the activity is as expected: it will no longer be available in the Inbox of the other users, thus, they will not have the option to work on it.
The Authorized Request task has been configured with the Everyone method and to every user whose Office is configured as Azca:
When a case comes in its workflow execution to that task, it will be marked as unassigned and available for all matching users, who will have to Take ownership of it to be able to perform the activity.
Enable read-only view
To enable the Read Only View, you need to explicitly enable the option, which is available in the configuration tab, under the advanced options of the business configurations. Notice that initially and by default the option is not ticked.
When enabled, the option Always enable Release button on read-only mode appears. Select its check-box for the release button to appear in the Work Portal of the user who takes the activity ownership
When enabled, each user that matches the task allocation preconditions (when the assignment method Everyone is enabled) can open the activity on the Work Portal and visualize it in read-only mode. The user doesn't take the ownership of the activity when opening it, to do so, the user must select the button named Take ownership on the top right of the window, otherwise the activity becomes available for each user that matches the task allocation preconditions and for delegated user, and they keep visualizing the activity in read-only mode each time they open it.
Keep in mind if there's a delegated user, the Take Ownership button also appears on his Work Portal.
For instance, suppose the user David Johnson matches the task allocation preconditions for the activity Approve vacation leave request of the Vacation Leave Request process. The activity appears on the Work Portal's in-box of all users who accomplish the allocation preconditions including David. If David had a delegated user, that user also visualizes the take ownership button on his Work Portal.
When David Johnson opens the activity visualizes it in read-only mode. David Jhonson must click the Take ownership button on the top right of the screen to work on the activity.
Now, David can either work on the activity and advance it, or since the Always enable Release button on read-only mode was enabled, he can select the Release button.
If the Always enable Release button on read-only mode was not enabled, the Release button does not appear and David must complete and advance the case.
If David selects the Release button, the activity becomes unassigned and available for all users that match its preconditions, including him.
A person that has a task assigned, may not be able to perform it or for any other reason, might want someone else to be accountable for it. Thus, Bizagi provides the Release functionality.
When a person is already assigned to a task, when he/she enters to work on it, on the upper right corner of the activity a Release button will be available.
When such button is clicked, the task will go back to everyone's Inbox, by running assignment rules again. This means that if the assignment method of the task is Everyone, it will be unassigned and available for all users that match its preconditions, including the user that just released the task.
Keep in mind, if the user who took the ownership of the activity was a delegated user, this user will also be available to Release the activity for the task to go back to every user who accomplishes the allocation rules including him.
View assignees when a Task is Unassigned
When a task is Unassigned, there are two ways in which you can review the users that are eligible and have the pending activity in their Inbox.
One, by accessing the Timeline of the case. The Unassigned task has a link to the available users.
The second option is by opening the Summary Form (lens icon on the task). This forms shows all current Assignees to all tasks, including those allocated to the unassigned one.
View both images below.
The following are some important situations that should be considered:
•The behavior of this assignment method remains the same regardless of the number of users who meet the conditions. If only one user meets the allocation rules, this user needs to enter the case and take ownership of the task.
If the task is released, and the same user is the only one who complies with the conditions, they will be on the list of available users again.
•Read only mode is enabled at runtime for end users when the task has been allocated to more than one user, AND the Everyone allocation method is present in at least one of the preconditions to assign the task's performers.
•When a case has not been assigned, namely no one has taken its ownership (or no one has opened the task if the read only view is disabled), reassigning the task will only add the selected user to the list of users who can take the task's ownership, this action will not assign the task to the selected user.
•The Take ownership/Release capabilities are available for delegated users. This means that if a user who has a task available due to a delegation and he opens it, that user can take ownership of the task.
•When searching cases, you can use the unassigned text to find all those cases which are not already assigned to a user.
•In Queries you will also find the unassigned tasks, this also applies when exporting those query results to Excel.
•In the Cases Management option in the Work Portal, the unassigned status will also be reflected.
•In the case list of the BAM and when exporting it to Excel, unassigned tasks will display an assigned user. In other words, this tasks will not be displayed as unassigned.
•When the Read Only View is enabled, the Work on it option will not assigned the user who clicked it to the task.
•Plans on the task, will only be available when it is assigned to a user.
•Only when a task is created or released the allocation rules are executed. As such, when your users' properties change, the pool of possible users for the unassigned tasks will not change, even if new users meet the criteria or the previous user can no longer fulfill it.