2022:Review Queue (Object)

From Grooper Wiki

This article is about an older version of Grooper.

Information may be out of date and UI elements may have changed.

20252023.120232022

person_play Review Queue node objects are designated for human-performed tasks. They organizes the Review tasks that require human attention and can distribute these tasks among different groups of users based on the queue's settings. Review Queues can be assigned on the settings Batch Process level to filter work by an entire process or Review Activities at the edit_document Batch Process Step level to filter tasks at a more granular step-based level.

Review Queues are used to distribute review tasks to users or groups of users by assigning them to Batch Processes or Review steps in a Batch Process.

About

Review Queues allow further control of what Batches and tasks Grooper users have access to. You can control the work presented to users in the "Batches" and "Tasks" pages in the Grooper Web Client with Review Queues (or Grooper Dashboard and Grooper Attended Client in the thick client). This allows you to better filter work to your users by defining ACL settings for Batch Processes and/or steps in a Batch Process.

  • Imagine a situation where you have several Batch Processes running in your environment and several users reviewing work in Grooper. You may want to assign certain users to certain Batch Processes based on their experience with the kinds of documents in the document set or quality of their work.
  • Imagine another situation where you want restrict the kinds of review your workers do. Maybe one group only performs data review and another only performs classification review. And maybe any of them can do document scanning.

You can also think of this as a "soft security" measure. By filtering out work available to users, the Review Queue acts as a kind of gatekeeper, controlling what comes across a reviewer's desk.

⚠

Please note this is not a "hard security" measure. There are conceivable ways in which a user assigned a certain Review Queue may still be able to access Batch content that is outside of their queue. For true "hard security", the best practice is to isolate that work in a separate Grooper Repository and restrict user access in the Security settings configured on the root node.


The general steps to create a Review Queue are as follows:

  1. Add the users to the Users list at the root node of the Grooper Repository.
  2. Create a new Review Queue.
  3. Select which Grooper Users you wish to add to the Review Queue.
  4. Then, the Review Queue can be implemented in one of two ways:
    1. On the Batch Process to restrict work accessed from the "Batches Page" of the Grooper Web Client (or Grooper Dashboard in the thick client).
      • Only Grooper Users listed in the Review Queue will be able to access Batches with that Batch Process in the "Batches Page" interface.
      • This will prevent users who are not members of the Review Queue from seeing any Batch using that Batch Process in the "Batches Page" interface.
      • Use this option if you want users to "pull" work from a list of active Batches.
    2. On a Review step of a Batch Process to restrict work accessed from the "Tasks Page" of the Grooper Web Client (or Grooper Attended Client in the thick client).
      • Only Grooper Users listed in the Review Queue will be able to start the Review task from the "Tasks Page".
      • This will prevent users who are not members of the Review Queue from seeing the Review task in the "Tasks Page"
      • Use this option if you want to "push" work to users, feeding them the tasks you want instead of allowing them to pick the Batches they want.

How To

In the following tutorials, we will show you how to create and implement Review Queues for a variety of scenarios. We will set up a number of Review Queues with the following individuals in mind:

  • Dylan - This is our Grooper designer. He will be creating the Review Queues from Grooper Design Studio and implementing them.
  • Randall - This is a Grooper review user. He will have the most access rights. There won't be any review task he won't be able to perform.
  • Chris - This is a Grooper review user. He will have more limited access rights. There are some review tasks Randall will be able to do that Chris won't.
  • Matt - This is a Grooper review user. He will have the most restricted access. There will only be a handful of tasks he will be able to perform.


We will also use a number of Batch Processes to illustrate Review Queues. Any Review step has been highlighted. These processes should be familiar to you if you've reviewed the Review User Guide article already.

Batch Process Steps In Batch Process Valid Review Users

"OTC Forms"

  • This will be our "control" process. No Review Queues will be implemented for this Batch Process.

Steps in "OTC Forms" Batch Process


Any of our users will be able to process Review tasks.

"HR Docs - Packet Separation"

  • We will use this process to illustrate implementing Review Queues at the Batch Process level.

Steps in "HR Docs - Packet Separation" Batch Process


Only Randall will be allowed to process Review tasks in this Batch Process

"Invoices Process"

  • We will use this process to illustrate implementing Review Queues at the Review step level.

Steps in "Invoices Process" Batch Process


Only Chris and Randall will be allowed to process the "Classification Review" step of this Batch Process.

Only Randall will be allowed to process the "Data Review" step of this Batch Process.

"URLA Redaction"

  • We will use this process to illustrate what not to do when implementing Review Queues (or at least something that goes against general best practice advice).
  • It is generally considered best practice to implement Review Queues at the Batch Process level or the Review step level, but not both. This will avoid what could be considered user access inconsistencies.

Steps in "URLA Redaction" Batch Process

For this Batch Process, we will review which users have access to what Batches/Review steps in the #Security Considerations section of this article.

Create a Review Queue

Add Users at Root Node

To create a Review Queue, you will first need to add individual users or groups of users to the Grooper Repository. You will do this by adding users using the Users property at the Root Node.

  1. Select the Root Node of the Grooper Repository.
  2. Under the Security settings, at least one Grooper designer will need to be added to add users.
    • In our case, our designer, Dylan, has already added himself using the Designers property.
    • When adding Designers be sure you, yourself, are added to the list. Otherwise, you will lock yourself out of the Grooper Repository in Grooper Design Studio.
  3. Select the Users property to add users.
  4. Press the ellipsis button at the end of the property.


  1. This will bring up the "ACL Editor" window.
  2. Use the "Groups" tab to add groups of users in your Windows directory.
  3. Use the "Users" tab to add individual users in your Windows directory.
  4. Use the Search box to enter the group name or user name you wish to add.
  5. Select the user you wish to add from the list.
  6. Press the Add button to add the user.


  1. This will add the user to the Users list.
  2. Continue adding users you wish to have access rights to review Batches in the Grooper Repository.
    • We've added our other Grooper users, Chris and Randall, to this list already.
  3. If you intend for your Grooper designers to process Batches in the Grooper Web Client, be sure to add users listed as Designers to the Users list as well!
    • We've added our Grooper designer, Dylan, to the Users list.
    • If you do not, the Grooper designer will not be able to access Batches or process Review tasks in the Grooper Web Client.
  4. Press OK when finished.


  2. When you have finished adding users, press the Save button.

Add a New Review Queue


  1. To add a new Review Queue, right-click the Queues folder.
  2. Select Add.
  3. Then, select Review Queue...

This brings up the "Add New Review Queue" window.

  2. Name the Review Queue.
  3. Press OK when finished.


  2. This will add the Review Queue to the Queues folder.


Next, we will configure the Review Queue by adding users to it, using the Performers property.

Add Users to the Review Queue

⚠

Please note you must add users to the Users property at the root node before this step. If you do not add users to the root node first, the Review Queue property will not appear on Batch Process and Review steps.


Next, we will add users to the Review Queue. When the Review Queue is implemented, it will restrict access to the Batch and/or Review tasks to the users added. To do this, you will add a list of users using the Performers property.

For example, we've added a Review Queue named "Classification Review". Of our three users, Chris, Randall and Matt, we only want Chris and Randall to do document classification review during a Review step. By adding Chris and Randall to the Review Queue (and not Matt) and implementing it on a Review step configured for classification review, this would present the Review task to Chris and Randall, but not Matt.


  1. Select the Review Queue in the Queues folder.
  2. Select the Performers property.
  3. Press the ellipsis button at the end of the property.


  1. This will bring up the "ACL Editor" window.
  2. Just as you did when adding Users to the Grooper Repository, use the "Groups" or "Users" tab to search for user groups or individual users.
  3. Add only the appropriate users/groups according to the Review Queue's function.
    • For our example, Chris and Randall, are our classification reviewers. So, we've only added them to the Review Queue.
    • FYI: As long as a Designer is added to the Users list, they are implicitly members of all Review Queues and do not need to be added to the Performers list.
  4. Press OK when finished.


  2. Don't forget to Save the Review Queue when finished adding Performers.

Next, we will demonstrate how to implement Review Queues. Review Queues can be implemented in one of two ways:

  1. On the Batch Process to restrict work accessed from the "Batches Page" of the Grooper Web Client.
    • Only Grooper Users listed in the Review Queue will be able to access Batches with that Batch Process in the "Batches Page" interface.
    • This will prevent users who are not members of the Review Queue from seeing any Batch using that Batch Process in the "Batches Page" interface.
    • Use this option if you want users to "pull" work from a list of active Batches.
  2. On a Review step of a Batch Process to restrict work accessed from the "Tasks Page" of the Grooper Web Client.
    • Only Grooper Users listed in the Review Queue will be able to start the Review task from the "Tasks Page".
    • This will prevent users who are not members of the Review Queue from seeing the Review task in the "Tasks Page"
    • Use this option if you want to "push" work to users, feeding them the tasks you want instead of allowing them to pick the Batches they want.
Click here to return to the top

Implement a Review Queue on the Batch Process Level

A Review Queue should be implemented on a Batch Process if you intend on users to pull their own work using the "Batches Page" of the Grooper Web Client (or using Grooper Dashboard in the thick client). When you add a Review Queue at the Batch Process level, only users in that Review Queue will be able to access Batches with that process from the "Batches Page". If a user is not a member of that Review Queue, they won't even see the Batches listed.

To illustrate this, we will implement a Review Queue named "PII" set on the "HR Docs - Packet Separation" Batch Process. Only Randall will be listed in the Review Queue. If another user, for example Chris, uses the "Batches Page" to access work, any Batch using the "HR Docs - Packet Separation" process will not be listed.

This is a way of filtering work to individual users based on specific Batch Processes. Perhaps Randall is better trained to handle human resources documents than Chris. Considering they have Personally Identifiable Information (PII), Randall may be certified to view and review more sensitive data, whereas Chris may not be. Setting the Review Queue on the Batch Process level is a way to better ensure Chris pulls the right Batches for himself, when accessing work using the "Batches Page".

Set Up the Review Queue


  1. We have added a Review Queue named "PII"
  2. Using the Performers property, we have added a single user, Randall.

Assign the Review Queue to the Batch Process


  1. Select the Batch Process you wish to assign the Review Queue to.
  2. Using the Batch Process Properties panel, select the Review Queue property.
  3. Using the dropdown list selector, select the Review Queue you wish to use.
    • In this case the one named "PII", listing only Randal as a performer.


⚠ Don't forget to publish changes to your Batch Process! If you add a Review Queue to a previously published Batch Process, those changes won't be reflected in production Batches until the Batch Process is re-published.

The Review Queue Performer's Perspective


Now that we've assigned the Batch Process a Review Queue, we can see the differences in users' perspectives from the "Batches Page". We will start with Randall's perspective, who is listed as a performer for the "PII" Review Queue (which is assigned to the "HR Docs - Packet Separation" Batch Process.

  1. When implementing Review Queues on the Batch Process level, you should access work from the "Batches Page" in the Grooper Web Client.
    • Or if using the thick client, using Grooper Dashboard.


The "Batches Page" interface will filter out Batches based on a user's membership in any Review Queue defined on a Batch Process.

  2. Because Randall is listed as a performer for the "PII" Review Queue, he is able to see any Batches using the "HR Docs - Packet Separation" process.
  3. With this Review step listed as Ready, he could go ahead and process this task.

Other Users' Perspective

For users who are not a member of the Review Queue, they will see something quite different when they use the "Batches Page". We'll look at things from Chris's perspective next. He is not listed as a performer for the "PII" Review Queue.

The "Batches Page" interface will filter out Batches based on a user's membership in any Review Queue defined on a Batch Process. The Batch using the "HR Docs - Packet Separation" process, is therefore not present in Chris's list of Batches.

  1. If the user is listed as a performer in the Review Queue defined for a Batch's process (or if no Review Queue is defined), the user will see the Batch listed. Otherwise, they will not.

Click here to return to the top

Implement a Review Queue on the Review Step Level

A Review Queue should be implemented on a Review step of a Batch Process if you intend on pushing work to reviewers using the "Tasks Page" of the Grooper Web Client (or using Grooper Attended Client in the thick client). When you add a Review Queue at the Review step level, only users in that Review Queue will be able to process that Review step. If a user is not a member of that Review Queue, they will not be apple to execute the Review step as configured in the Batch Process. If you have multiple Review steps in a Batch Process, they can each use their own Review Queues, based on the task at hand.

To illustrate this, we will implement two Review Queues: one named "Classification Review" set on a Review step intended to review document classification and another named "Data Review" set on a Review step intended to review document data extraction. Both Randall and Chris will be listed in the "Classification Review" queue, but only Randall will be listed in the "Data Review" queue. This means both Chris and Randall will be able to perform tasks using the "Classification Review" queue, but only Randall will be able to perform tasks using the "Data Review" queue. And our other user, Matt, wouldn't be able to do either.

This is a way of filtering work to individual users based on the types of work in a given Review task. Randall may be best trained in reviewing extracted data. There may be more stringent business requirements for a reviewer to even understand the data extracted. However, both Chris and Randall may be equally qualified to determine if a document was classified correctly. By putting Chris and Randall in the "Classification Review" queue but only Randall is put in the "Data Review" queue, you can ensure the right types of work suited to the individual are pushed across their desk when using the "Tasks Page" to filter their work.

Set Up the Review Queue(s)

In this tutorial, we will set two Review Queues on two Review steps of a single Batch Process.


  1. The first Review Queue is named "Classification Review"
    • This will be implemented on the same-named "Classification Review" step of the "Invoices Process" Batch Process.
  2. Using the Performers property, we've added two users.
  3. Both Chris and Randall have been added to the Review Queue.


  1. The second Review Queue is named "Data Review"
    • This will be implemented on the same-named "Data Review" step of the "Invoices Process" Batch Process.
  2. Using the Performers property, we've added one user, Randall.

Assign the Review Queue(s) to the Review Step(s)


  1. Select the Batch Process whose steps you want to assign the Review Queue to.
  2. Using the Steps in Batch Process panel, select the Review step.
    • Review Queues can only be added to steps whose Activity Type is the Review activity.
    • We've named this step "Classification Review". But its Activity Type is Review.
  3. Using the Step Properties panel, select the Queue Name property.
  4. Using the dropdown list, select the Review Queue you wish to use for the selected review task.
    • In our scenario, we want Chris and Randall to be our users who perform document classification review. The "Classification Review" step is setup to do that (i.e. it has the Classification Viewer configured). The "Classification Review" queue has Chris and Randall listed as its performers. Therefore, we've set the "Classification Review" step's Queue Name property to the "Classification Review" queue.


If you have more than one Review step in your Batch Process, you will need to configure each one's Queue Name property separately. Otherwise the "default" queue will be used, which is to say any user will be able to access the review task for that step.

  1. Select the next Review step.
  2. Using the Queue Name property, choose the Review Queue you wish to use for the selected review task.
    • In our scenario, we want Randall to be the only user who reviews the results for a document's extracted data. The "Data Review" step is setup to do that (i.e. it has the Data Viewer configured). The "Data Review" queue has only Randall listed as its performer. Therefore, we've set the "Data Review" step's Queue Name property to the "Data Review" queue.


⚠ Don't forget to publish changes to your Batch Process! If you add a Review Queue to a previously published Batch Process, those changes won't be reflected in production Batches until the Batch Process is re-published.

The Review Queue Performer's Perspective


| Now that we've assigned two different Review Queues to two different Review steps, we can see the differences in users' perspectives from the "Tasks Page". We will start with Randall's perspective, who is a member of both the "Classification Review" and "Data Review" queues.

  1. When implementing Review Queues on the Review step level, you should access work from the "Tasks Page" in the Grooper Web Client.
    • Or if using the thick client, using Grooper Attended Client.


When accessing work from the "Tasks Page" tasks are filtered to the user based on Review Queues.

By default, the "default" Review Queue is used. This shows users a list of Review tasks with no Review Queue assigned in their Batch Processes.

  2. These Review steps do not have a Review Queue configured.
  3. Conspicuously missing from the list are Batches using the "Invoices Process", which does have Review steps with Review Queues configured.
  4. In order to access work from these queues, we need to filter our work using the Task Filter.


Using the Task Filter a user can select a single Review Queue. Executing the filter will present the user with any available Review tasks for the selected Review Queue.

  1. Press the Task Filter button.
    • This will bring up the Task Filter window.
  2. Press the hamburger icon at the end of the Queue property.
    • This will present the user with a dropdown list of any Review Queues they belong to.
    • For example, Randall has been listed as a performer for the "Classification Review", "Data Review" and "PII" Review Queues. So, he can choose to filter tasks from any of those queues.
  3. Select a Review Queue from the dropdown list.
  4. Press the Save button to apply the filter.


  2. With the "Tasks Page" filtered by the "Classification Review" queue, the user is only presented with ready Review tasks who have been configured to use that queue.
    • In Randall's case here, the ready "Classification Review" steps of the "Invoices Process" Batch Process.


If filtered by another Review Queue the user will be presented with a list of ready tasks using the selected queue.

  2. Here, Randall has filtered by the "Data Review" queue. So, he's able to process ready "Data Review" steps of the "Invoices Process" Batch Process.

Other Users' Perspective

Other users will see something different when they use the Tasks Filter in the "Tasks Page" interface. We'll look at things from Chris's perspective next. He is listed as a performer for the "Classification Review" queue, but not the "Data Review" queue (nor the "PII" queue for that matter).


When selecting Review Queues to filter by, a user can only select a Review Queue if they are a member of the queue.

  1. Chris is only listed as a performer for the "Classification Review" queue. So, that is the only one he can select (besides the "default" queue).


  2. Matt is not listed in any Review Queue. So, he is only able to filter by the "default" queue, receiving only Review steps/tasks with no Review Queue assigned.

Click here to return to the top

Security Considerations

Because Review Queues are a method of filtering work using Access Control Lists, you may think of them as a way of implementing security at a Batch Process or Batch Process Step level. To a certain extent, this is true, but Review Queues should be considered a "soft security" measure as opposed to a "hard security" measure.

If your intention is to truly restrict a user's capability to access a Batch's documents or even edit document classification or extracted data elements, there are ways in which Review Queues will fail to restrict user's access rights. If you want a "hard security" setup, you should utilize separate Grooper Repositories to isolate work and restrict a user's access to the Grooper Repository as a whole.

In this tutorial, we will demonstrate the limitations of Review Queues access restrictions.

Batch Step Level Limitations

In the previous tutorial (#Implement a Review Queue on the Review Step Level), we demonstrated how to use Review Queues on Review steps to filter review tasks based on the type of work being performed step itself. We created a "Classification Review" queue for a "Classification Review" step and a "Data Review" queue for a "Data Review" step.

In our scenario, Chris was not a member of the "Data Review" queue, meaning when he used the "Tasks Page" to filter work, he couldn't select the "Data Review" queue. These tasks were obscured from him. However, that does not necessarily mean Chris could not edit a document's data. The way we configured things, Chris could have used the "Batches Page" to edit a document's data, under the right circumstances.


  1. Instead of using the "Tasks Page", Chris is going to access work using "Batches Page"
    • Again, if implementing Review Queues on the step level, Chris should be using the "Tasks Page" to access work, not the "Batches Page". The reasons for this should become apparent shortly.


Because no Review Queue has been assigned at the Batch Process level, Chris is able to see all Batches using the "Invoices Process" Batch Process in the list.

  1. This includes a Batch with a "Data Review" step ready for processing.
    • Even though Chris is not a member of the "Data Review" queue, he is still able to see the Batch in the list.
  2. However, if Chris tries to process the task by double-clicking the Batch, Grooper will not allow him to do so.
    • This is a good thing! We don't want Chris to perform "Data Review" based on how we configured our Review Queues.


So what's the problem? Chris can't edit the documents' data. Everything is good right?

Not necessarily. If the Batch is paused, the Batch can be opened. An opened Batch's documents can be edited in a variety of different ways.

  1. This Batch is now Paused.
  2. Since it is Paused, it can be opened.


Opened Batches can have their content accessed using the following Views:

  • Folder Viewer
  • Thumbnail Viewer
  • Data Viewer
  1. All Chris has to do to edit a document's data now is navigate to the Data Viewer tab.
  2. He can edit any data element he wants at this point.
  3. He can save any document's edited data too.


This is one way in which Review Queues fail to be a "hard security" measure. Even though Review Queues were used to break up work between "Classification Review" and "Data Review", there are circumstances where a reviewer can perform a function they aren't "supposed to". Be aware of this limitation around paused and then opened Batches.

Batch Process Level Limitations

You should also be aware Review Queues can start to behave in undesirable ways if you assign Review Queues at both the Batch Process and the Review Step level. Generally, it is best practice to choose one or the other, but not both.


  1. Imagine you have an created a Review Queue named "Image Review".
    • In our scenario, this Review Queue is typically assigned to Review steps using the Thumbnail Viewer to review results from an image processing step.
  2. Let's say all our users, Chris, Randal and Matt, are cleared for performing document image review generally.


  1. Now, let's imagine we're configuring Review Queues for another of our Batch Processes named "URLA Redaction".
  2. URLAs also contain Personally Identifiable Information which is more sensitive data. So, we might want to restrict who can process these Batches using our "PII" Review Queue.
    • Only Randall is a member of this Review Queue. He's done his PII compliance training. Truthfully, no user who hasn't completed PII compliance training should touch these Batches.
  3. What's going to happen if we assign the "Image Review" queue to a Review step?
    • For example, the "Image Review" step of this Batch Process
    • Will Chris or Matt, who aren't members of the "PII" queue be able to access Batches with the "URLA Redaction" process? Conceivably, yes.


From the "Batches Page", it seems as if Chris or Matt would not have access to Batches with the "URLA Redaction" process.

  1. There is no Batch with the "URLA Redaction" process in the list.

However, from the "Tasks Page", it's a different story.

  1. Chris or Matt would be able to filter by the "Image Review" Review Queue.


  2. Remember, we configured the "URLA Redaction" process's "Image Review" step to use the "Image Review" queue.
  3. Because a Batch using the "URLA Redaction" process has an "Image Review" task ready for processing, Chris or Matt can see the task in their list and process it.


In this way, configuring Review Queues for both the Batch Process and a Review step can create what could be considered access inconsistencies.

Setting Up a Grooper Repository for Hard Security

The previous example is a good example of the need for separate Grooper Repositories as a "hard security" measure.

Truthfully, documents with PII data should be isolated from certain users view. Only users who are cleared to view and review sensitive data should even be given the option of looking at these documents. Instead of using Review Queues to filter work, the Batch Processes and Grooper assets involved (such as a Content Model) should be siloed into a second Grooper Repository.

With a separate Grooper Repository, you can lock down global access to its contents using the Security settings on the Root Node. So a preferable solution here would be to create another Grooper Repository and use that repository to process the more sensitive documents, locking down security at the repository level itself.


  1. For example, we could create a new Grooper Repository named "PII Compliance"
  2. We would restrict access to the Grooper Repository itself using the Users property.
    • In our case, Randall is the only reviewer cleared to review documents with PII data. So, he's the only user we've added to the list.


  1. If any other user attempts to access this Grooper Repository, they will be presented with an "Access Denied" message.
  2. The "Batches Page" and "Tasks Page" will also be greyed out and unclickable, preventing them from accessing any Batch content in the repository whatsoever.

Retrieved from "https://wiki.grooper.com/index.php?title=2022:Review_Queue_(Object)&oldid=22379"