Verification of task response (Acceptance, Rejection, Return)

Description of functions

The system offers a possibility to order a task to a user in a mode with the acceptance of results (i.e. it is required to check the answers given and change the status of the task to one of the statuses ending e.g. the task accepted) or without acceptance (parameter configuration here), where the tasks performed by the users (their answers given) receive automatically the status accepted, which is the status ending the task (there is no possibility to change this status to another in the main application flow, from which exceptions may appear in processes dedicated to particular instances). The task executed in the accepted mode, after its execution it receives the status "for verification", tasks with this status are visible in the task verification view (screens in the section How to use the function), where they are presented in the form of a scoreboard, which has the ability to sort and filter data. The evaluating user has a possibility to review the given answers (one answer at a time, for one location, by one user) and evaluate the whole task or particular commands within this task.

State of play

The task to be verified, after evaluation by the user of the evaluator can accept the states:
  • Accepted - State ending for the result, no further paths.
  • Rejected - State ending for the result, no further paths. The answer has not been accepted, it has a rejected state, i.e. the user has completed the task but not the right one.
  • Accepted with comment - The state in which the task will be returned to the user in order to familiarize him/her with the comments added by the assessor user, and when the user reads the comments (finish the task), none of the tasks has the state accepted. (end of process). Business example: A user has completed a task in the form of placing products on a shelf, which he documented with a photo, the assessor wants to accept the task because it was generally done well, but he wants to pass the comment to the assessor so that he can remember about the last shelf in the future. In such a case, the user performing the task is returned to the task, but in this case the user only has to accept reading the comment given by the assessor and then the process ends (there is no way to answer the assessor).
  • Returned to the user (task to be corrected) - The state in which the task is returned to the user to correct the answers given. A task may be returned whole or in part (return of single commands and/or whole groups of commands if the commands were grouped or part of a subprocess where it is not possible to return a single answer in such a case). The user, which task was returned, sees in the mobile application the previously given answers and is obliged to edit this answer (he cannot go through the step if he does not make any changes in the answer). The assessor user has the possibility to add a comment to the whole task (main reason for rejection) and/or to individual rejected commands/command groups. The user improving the results, has no possibility to add a comment from himself to the given answers if the task process did not provide a field for additional comment within the command. A task performed again by a mobile user goes to re-evaluation, where the evaluating user can accept e.g. 2 out of 3 commands, and 1 command can be returned to the task performer again. The transfer between the user performing and the assessor lasts until the whole task reaches its final state (task accepted, task rejected, task aborted). NOTE - the task to be improved is a continuation of the task originally addressed to the user (it is not a separate/independent task "improve task"), this causes that when the user sees the task to be improved, it is not possible within this task to start the task again/from a new one in the same location or in a different location even though, for example, within the task a cycle has been set and there is another cycle to perform the task. The user is obliged to improve the results and send it, then he will be able to start the task e.g. in another location or within the next cycle.
  • Interrupted task returned (task to be improved which has been interrupted) - State ending in which the user has completed the task, but it has been returned to him/her by the assessor in whole or in part, and the user obliged to improve the task, does not perform this action and interrupts the task with the Interrupt button. The task process in this case ends.

How to go to the task verification view

In order to move to the task verification view, press one of the icons/contacts shown in the picture below:
  • The "Verify" button on the orange bar indicates that new tasks have appeared for evaluation in all visible tasks on this screen. The counter in the content shows the total number of answers to be checked/evaluated (from all tasks). Pressing the verify button will take you to the verification view where you will see the answers from all the tasks with the status "to verify". (default filter is a filter that can be removed)
  • A button with an orange background marked with a star visible to a single task indicates that there are unrated tasks in this task. The counter next to the star shows the number of new results to be assessed. Pressing the verify button will take you to the verification view where you can see the answers from this particular assignment with the status "to verify". (default filter is a filter that can be removed)
  • The gray icon with a "pipe" will move to the verification view where the answers from this particular task with each status will be visible (will not be limited to the status "for verification").

The task verification view shown on the screen below contains two views: Tasks to verify and Photos to verify.

View of the photo for verification

A view used to preview photos taken within a task/tasks for which a filter has been submitted within this view. The view does not have the possibility of evaluating the tasks performed, only their wholesale viewing with the possibility of exporting the photos (mass download of the photos).

Task view for verification

A tabular view with the possibility of filtering, presenting the results of performed tasks. In order to go to the details of the task, click the grey icon with a "pipe".

View of details of answers given

The view contains information about the title of the command, description of the command, pictures of hints or other elements embedded within the commands and the answers given.

Collapse and expand command

When there is a large number of commands in a task, collapsing and expanding the answers in verification is helpful when you want to check the answers of a particular command. During task verification it is possible to collapse and expand command for clarity of task verification. This is done with Expand/Collapse block and up/down arrows next to particular command. When the block is grayed out it means that the answers are collapsed and you can't see them in the verification. Only the task commands are visible. When you click on a block, the answers become visible, they are expanded, which is indicated by the blue color of the block. In this case you will see the word "Collapse" next to the block. After clicking on the block again the answers will be collapsed again, which means they will not be visible during the verification. 

It is possible to expand the answers from a specific command while not seeing the rest of the answers from other commands. Click on the arrow next to the title of the command. The upward arrow means you can collapse the answer, the downward arrow means you can expand the answer only from the command you clicked. Below is the view when all answers have been collapsed. One of the commands (answers) has been expanded (Open command option 3) by clicking on the arrow. The command response is visible during verification. The arrow has changed its direction to allow the response to be rolled back up. The rest of the commands are still collapsed.

Please note that when "all collapsed" is set, if at least one command is expanded, the block on the top in the verification changes and shows the possibility to collapse again. In the opposite situation, when you expand all the answers and collapse at least one of them with the help of the arrow, the block will show the possibility to collapse all the answers again. After clicking on the block, the answer to the command which we collapsed earlier by means of the arrow will be expanded.

Mechanics of task evaluation

To evaluate tasks, use the Accept/Remove buttons visible under each command and visible at the top of the task details view. General rules:
  • An accepted command may have a comment but does not have to.
  • An accepted command can be returned to the task's executor only if it has a comment (returning to the task's executor to read the comment) and the parameter "Accepted tasks return for improvement" is active in advanced settings. 
  • The rejected command must always have a comment (the user performing the task should be able to get information why the task has this state)
  • The rejected command can be returned for correction if the parameter "Rejected tasks return for correction" is active in the advanced task settings.

Behavioural scenarios

We distinguish between the following evaluation scenarios for the task, when we enter a new task (not previously evaluated), and the parameters: "Rejected tasks return for improvement" and "Accepted tasks return for improvement" are inactive:
  1. the user presses: Accept the whole task - Pressing the button at the top of the view will immediately accept the whole task and return to the list of all tasks for verification. The task will receive the state: Task accepted. The process ends.
  2. the user presses: Reject the whole task - Pressing the button at the top of the view will reject the whole task, but before returning to the list of all tasks to be verified a window will appear with the possibility of adding a main comment to be rejected. The comment will be visible in the verification details of the task (under the name of the task, in place of the assessment buttons). The task will be given the state: task rejected. The process ends.
  3. user presses: Accept on one of the answers (any), there is space for adding a comment, after pressing Accept this command is accepted. The user now has possible scenarios:
  • It will make manual acceptance Accepting the remaining answers (i.e. pressing the Accept button under each command) - in this case the whole task will receive the state of the task accepted with a comment and when evaluating the last command, a popup will appear, allowing you to add the main comment to the task. The task will be returned to the user to see the comments added to individual commands and/or the main comment.
  • The task will be manually rejected by rejecting the remaining answers (i.e. pressing the reject button under each and/or selected command) - in this case the whole task will be given a rejected state and when evaluating the last command, a popup will appear, allowing you to add the main comment to the task. The task receives a rejected state when at least one answer is rejected.
  • The assignment receives a rejected state when at least one answer has been rejected, and presses the Accept remaining answers button - in this case all answers that do not have a rating yet will be accepted. If you use this button, you will not be able to add a comment to individual responses. The whole task will assume the status of accepted, because there is no rejected answer. Before you go to the list of tasks to be verified you will see a popup with a possibility to add a main comment to the whole task (because one answer has been accepted manually and this will give the task the status Accepted with comment)
  • Press Reject the remaining answers - in this case all answers that do not have a rating yet will be rejected. If you use this button, you will not be able to add a comment to individual answers. The whole task will take the status of rejected, because there is at least one rejected answer. Before you exit the list of tasks to be verified you will see a popup with a possibility to add a main comment to the whole task because the task gets the status of Rejected and you can always add a main comment to this status.

4. user presses: Reject on one of the answers (any), there is space for adding a comment, after pressing Reject this command was rejected. The whole sentence will already have the Rejected status because at least one answer has been rejected. The user now has possible scenarios similar to the one in point 3.

Parameters: "Rejected tasks return for correction" and "Accepted tasks return for correction". - If these parameters are active, the application behaves analogously to the scenario described in point 3, with this difference:
  • the command accepted when a comment is added (commands without a comment are not returned) will be returned to the user. The user in the mobile application will see the task to be corrected (the previously given answers to the returned commands). Sent answers together with the comment of the assessor are visible in the mobile application, the user can view them and finish the task. The process is finished.
  • a rejected command with a comment will be returned to the user for improvement. The user in the mobile application will see the task to be improved (the previously given answers to the rejected commands) and must modify the answer (any one) to be able to resend the result. The user in the mobile application only sees the returned commands (he does not see the whole task, unless the whole task has been returned for improvement). Corrected user's result is visible in the web panel as a task for verification. In the details of this task you can see all the answers (from the first execution and from the patch), the returned / corrected answers need to be accepted again or rejected if the task is rejected, the user returns to the task again if the process ends. 

There is no limit to the rejection and return of the task between the user and the assessor, but keep in mind that the task returned is the same as the original one, so the whole task blocks the possibility of performing the same task in another location (while the process of evaluating the first result has not been completed), in other words, you cannot perform task A in location X, receive it for correction and be able to perform the same task in location B, the evaluation process must be completed (i.e. accepted or interrupted by the user - refusal of correction).
Rejection of decision making commands.
It is not possible to correct a rejected command, i.e. a decision command that can modify the path the user has chosen (No/Yes, Single choice, Dynamic single choice), because changing the response could show the user a new path of commands to be executed, and the expectation is to correct the answers. Example 1, we have a process where we used the YES/NO command, the YES response leads to Take a photo, the NO response leads to an open command, if the command is returned, there will be no way to change the response from YES to NO. Example 2, we have a process where we used the YES/NO command, the YES response and the NO response leads to the same Take picture step, in such a case when the command is rejected and returned for correction, the user can change the YES response to NO, because the NO response does not change the decision and run a different decision path.
Note - the application has no results versioning, there is no functionality to view the series of answers given / rejected and returned. In the case of the scenario where commands for improvement were returned and answers given were changed (corrected) by the user and sent for reassessment, in the application we keep only the last set of answers given (the latest).
Article rating / Czy to odpowiedziało na Twoje pytanie? Article rating success / Dziękujemy za wiadomość There was a problem submitting your feedback. Please try again later.

Still Need Help? / Dalej potrzebna pomoc? Contact Us / Kontakt z nami Contact Us / Kontakt z nami