Review
Category: Processing
The Review activity is where a person checks what the AI produced. When a transaction reaches this step, the step first decides whether a human is needed at all. If it is, the transaction pauses and waits in the review queue until a reviewer accepts it, rejects it, or sends it somewhere else. If it is not, the transaction approves itself and carries on down the workflow without stopping.
Everything on this page is configured on the Review node in the workflow designer.
When a transaction enters review
Before pausing, the step counts the issues the transaction currently carries and groups them into three kinds:
| Kind | What it covers |
|---|---|
| Errors | Business rule results at error level, whether the rule is bound to a field, to a document, or to the whole transaction. |
| Warnings | Business rule results at warning level, from the same three levels. |
| Low-confidence items | Extracted values, split decisions, and classification decisions whose confidence falls below this step's thresholds. |
The When is review required? setting then decides what to do with those counts.
| Option | A human sees the transaction when |
|---|---|
| Always require review | Every time, even when the transaction is completely clean. |
| Only for errors, warnings, or low-confidence items | Any issue of any kind is present. |
| Only for errors or low-confidence items | There are errors or low-confidence items. Warnings alone pass through. |
| Only for errors or warnings | There are errors or warnings. Low confidence alone passes through. |
| Only for errors | There are errors. Everything else passes through. |
When the policy is not triggered, the transaction is auto-approved: it continues immediately on the Approved exit, exactly as if a reviewer had accepted it. It never appears in the review queue, and Monitoring counts it as automatically processed rather than as review work.
The default is Always require review, so a project built before this setting existed behaves exactly as it did. New projects are created with Only for errors, warnings, or low-confidence items, which is the setting most teams want.
What counts as one issue
An issue is one thing a reviewer has to look at, which is one stop in the viewer's issue list. The same definition is used by the issue badge in the Transaction Viewer, by the accept and review gates, and by the table columns described below, so the numbers always agree.
- Each failing rule result is one issue. A field with two failing rules is two issues, because it is two messages to read.
- A low-confidence value is one issue, counted per scalar field, per group member, and per table cell, not per column or per row.
- A field that already has a rule issue is not counted again as low confidence. The rule message is the richer stop.
- A split decision and a document's class are one issue each when they are below threshold.
- Once a reviewer confirms a value, it stops counting as a low-confidence issue.
Unanchored redaction findings
If the workflow contains a Redact step, it can find a value that should be hidden but fail to locate it in the recognized text, so its pixels may still be visible until a reviewer draws the region by hand. Unanchored redaction findings count as decides whether such a finding is treated as an error (the default) or as a warning. Both gates on this page then handle it like any other error or warning.
What counts as low confidence
The Review step owns the definition of low confidence. The Split, Classify, and Extract steps only record how confident they were; this step decides what is low. It applies its thresholds the moment a transaction arrives, so the flags the reviewer sees, the issue badge, the gates, and the table columns all come from one place.
| Threshold | Applies to | Default |
|---|---|---|
| Splitting | The confidence of each document's split decision. | 0.8 |
| Classification | The confidence of each document's assigned class. | 0.8 |
| Extraction | The confidence of each extracted value, including group members and table cells. | 0.8 |
Each threshold is a number between 0 and 1. A value is low confidence when its confidence is below the threshold, so the default 0.8 means "anything under 80 percent goes to review". Raise a threshold to send more to review, lower it to send less.
Thresholds are read when a transaction reaches the step, so changing one affects transactions that arrive afterwards. Transactions already waiting in the queue keep the flags they entered with until they pass the step again.
Because this step is what applies the thresholds, a workflow that never reaches a Review step leaves confidence recorded but unjudged, and the viewer shows no low-confidence markers.
Actions at the review step
The Reviewer's actions section defines the buttons a reviewer gets in the Transaction Viewer, and where each one sends the transaction. Every Review node always has an Approved exit; Reject and each Send To action add their own exit handle to the node, which you wire to a target activity in the designer.
Accept
Accept approves the transaction and continues on the Approved exit. The Accept policy decides when the button is available.
| Option | Accept is blocked by |
|---|---|
| Accept only when no errors, warnings, or low-confidence items | Anything left unresolved. |
| Accept with low-confidence items; block on errors or warnings | Errors and warnings. |
| Accept with warnings; block on errors or low-confidence items | Errors and low-confidence items. |
| Accept with warnings and low-confidence items; block on errors | Errors only. This is the default. |
| Accept regardless of errors, warnings, or low-confidence items | Nothing. The reviewer always decides. |
When the policy blocks Accept, the button is disabled and its tooltip lists exactly what is in the way. The server checks the same rule again when the action is submitted, using the live counts at that moment, so a reviewer who fixes the last error can accept straight away.
Accept comment controls whether accepting opens a comment dialog: no dialog, an optional comment, or a required one.
Reject
Allow Reject adds a Reject button and a Rejected exit on the node. What rejection does depends on the workflow graph, not on a separate setting:
- Rejected exit wired to an activity: the transaction continues down that branch, for example back to a correction step or on to an exception handler.
- Rejected exit left disconnected: the transaction is marked as failed.
The settings panel tells you which of the two is in force for the node you are editing. Reject comment works like the accept comment: no dialog, optional, or required.
Send To actions
A Send To action is a named extra exit, for example "Send to Supervisor" or "Send to Exceptions". Add as many as the step needs. Each one gets:
- a name, which is the button label in the viewer and the label on the node's exit handle. Names must be unique so reviewers can tell two buttons apart;
- a comment mode: no comment, optional, or required;
- an assign reviewer mode: no assignment, optional, required, or auto-assign to sender, which sends the transaction onward already assigned back to the person who moved it.
Wire each action's handle to the activity that should receive the transaction. An assignment made here carries to the target step, so the receiving reviewer finds it in their own queue.
Reviewer inactivity
While a reviewer has a transaction open, it is held for them so nobody else works on the same one. If they stop interacting, the transaction is released back to the queue.
| Setting | Meaning | Default | Range |
|---|---|---|---|
| Idle timeout (minutes) | How long a reviewer can be inactive before the transaction returns to the queue. | 10 | 2 to 120 |
| Warning before timeout (seconds) | How long the reviewer is warned before that happens. | 60 | 15 to 300 |
Step SLA
A Review step can carry its own SLA, calculated when the transaction enters the step, so a queue can be sorted and monitored by how close each item is to its due time. It is configured in the SLA panel at the bottom of the Review settings and reported in Monitoring.
Accept policy, reject options, and Send To actions apply to Playground and to My Work Queue, which is the production dataset. Memory and Evaluation datasets stay deliberately permissive so training and test flows are never blocked.
Configuration reference
| Setting | Description | Default |
|---|---|---|
| Instructions for Reviewer | Guidance shown to the reviewer when they open the transaction. | (optional) |
| When is review required? | Whether the transaction pauses for a human or auto-approves. | Always require review |
| What counts as low confidence | Split, classification, and extraction thresholds, from 0 to 1. | 0.8 each |
| Unanchored redaction findings count as | Whether such findings gate as errors or as warnings. | Errors |
| Accept Policy | Which issues block the Accept button. | Accept with warnings and low-confidence items; block on errors |
| Accept comment | Comment dialog on Accept: none, optional, or required. | No comment dialog |
| Allow Reject | Show the Reject button and expose the Rejected exit. | On |
| Reject comment | Comment dialog on Reject: none, optional, or required. | Optional |
| Send To actions | Named extra exits, each with its own comment and assignment rules. | (none) |
| Idle timeout | Inactivity before the transaction returns to the queue. | 10 minutes |
| Warning before timeout | Warning shown before the idle timeout fires. | 60 seconds |
| Step SLA | Per-step due time for this review. | Off |
Review issue columns in the transaction table
Playground and My Work Queue can show how much review work each transaction carried and how much of it was actually corrected. Three columns are built in:
| Column | Shows |
|---|---|
| Issues before review | The number of issues the transaction had at the moment it first entered a Review step, before anyone touched it. |
| Issues to review | The number still open right now. It falls as a reviewer fixes and confirms things. |
| Issues corrected | Issues before review minus issues to review, so the work a human actually did. |
The columns are hidden by default. Turn them on from the column menu on any table header, or in Manage columns. They sort like any other column and can be used in the advanced filter and saved in views, so a supervisor can build a tab for, say, Issues corrected > 0.
A few things worth knowing about the numbers:
- Before review is captured once, the first time the transaction enters a Review step, and never moves afterwards. That is what makes it a fair baseline for comparison.
- A blank cell means there is no data, not zero. A transaction that never entered review, including one the review-required gate auto-approved, has no before-review baseline, so those cells stay empty rather than showing a misleading 0.
- Issues corrected can be negative if a reviewer's edits introduced new rule failures, which is a legitimate signal rather than an error.
- The counts use the same issue definition as the viewer's badge and the gates above, so a transaction showing "5 issues to review" in the table opens with 5 stops in the viewer.
Custom review issue columns
The three built-in columns are grand totals. When you want to track one specific kind of issue, add a custom review column: choose any combination of cells from a grid of six reasons by three states, and the column shows their sum.
| Reason | State |
|---|---|
| Errors | Before review |
| Warnings | To review |
| Low-confidence fields | Corrected |
| Low-confidence class | |
| Low-confidence split | |
| Unanchored redaction findings |
For example, a column combining "Errors, corrected" and "Warnings, corrected" tracks rule issues a reviewer resolved, while "Low-confidence fields, before review" tracks how much the extraction was unsure about before anyone looked. Custom review columns are created in Manage columns, are project-wide, and sort and filter like the built-in ones. Adding or editing them requires the project.configure_transaction_view grant, the same one that governs other custom columns and project views.
You can also ask the AI assistant, for example "add a column with errors and warnings corrected", or "show me transactions where more than ten issues were corrected".
Notes
- Validation results from the Validate step are what produce the errors and warnings both gates count, so a Review step usually follows a Validate step.
- Review is what teaches Memory. A transaction approved here can become a training sample, but only if the reviewer's role carries the "System can learn from user" permission. The built-in Reviewer role does not, so check this before relying on production learning.
- A role can be limited to specific review steps, so a reviewer only sees the queue for the steps they are responsible for. This is configured on the role in user administration.