Human Review
Category: Processing
The Human 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 Human 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. |
| There are issues to review (errors, warnings, low confidence) | Any issue of any kind is present. |
| There are errors or low-confidence items | There are errors or low-confidence items. Warnings alone pass through. |
| There are errors or warnings | There are errors or warnings. Low confidence alone passes through. |
| There are errors | There are errors. Everything else passes through. |
A transaction that reached this step through another step's Failed exit (Handling failures), directly or through steps in between such as a Notification, always pauses for a reviewer, whatever the policy: the step that failed may have left no issues to count. So does a transaction that an Agent Review step's agent rejected or sent on with a Send To earlier in the same run, at this step and at any Human Review after it, until that Agent Review decides again: an agent that rejects a document as wrong may leave nothing to count either. A step that is switched off does not pause.
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.
After an Agent Review
If an Agent Review step runs earlier in the workflow, After an Agent Review says what this step does with the agent's work. Only an agent's decision counts: an Agent Review step that is switched off, or had nothing to review, leaves When is review required? to decide. A transaction the agent rejected or sent on always waits for a person, whatever you choose here.
| Choice | What happens |
|---|---|
| Review as usual | When is review required? decides, whatever the agent did. The default. |
| Also review what the agent changed | A transaction also waits for a person when an Agent Review step before this one, in this run, changed data while its agent worked on it, whatever the option above says. That covers an agent that decided, and one that made corrections but did not decide in time, so the step failed. |
| Let through what the agent approved | A transaction the agent approved goes on without a person, even if it still has issues the option above would stop for. A new project's Human Review step uses this. |
| Let through what the agent approved without changes | As the one above, unless the agent changed data: then a person reviews it. |
Use Let through what the agent approved when the agent is there to replace a person's routine review, and Also review what the agent changed when it is there to lighten your reviewers' work: an agent that accepted without changing anything goes straight on, and a person sees every transaction it changed. None of the choices has anything to add under Always require review, which is why the setting is unavailable there.
A change is a different value, a different document type, or a document added or removed; confirming a value is not one, and an edit made through the API counts like one made with the agent's tools.
On the workflow canvas, a Human Review step that lets the agent's approvals through says so under its name, and the Agent Review step's settings say what happens after Approved and Rejected. In the transaction's activity log, a transaction let through reads "let through: an agent approved it", not an approval by a person.
Whether the agent changed data is read from the transaction's checkpoints, the same comparison Memory uses to decide what an agent's review can teach. When it cannot be told, for example because checkpoints are switched off for the project, the transaction waits for review: with a choice that reviews what the agent changed, a project without checkpoints sends every transaction an agent worked on to a person.
The default is Always require review, so a project built before this setting existed behaves exactly as it did. New projects are created with There are issues to review, 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 Human 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 Human 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 Human 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;
- Use when, optional: when to take this action, for example "the amount needs a second signature". The reviewer sees it as the action's description in the viewer, and an assistant reviewing for a person reads it with the action.
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.
Who may decide
People decide at a Human Review step in the viewer, and so does the Assistant in the app, as the person using it. Assistants may decide says whether a person's own AI assistant may too: one connected to their account, or one using their personal API key (Reviewing a transaction with your assistant). Such an assistant decides as the person, and the decision is recorded under their name with the assistant beside it.
It is on by default. Turn it off for a step whose decisions should be taken only in the app: an assistant then cannot decide at that step, nor change the transaction's extracted data with its review tools, and is told so. This is not a lock on the data: a script that calls the REST field-editing endpoints with a person's personal API key can still change values while the transaction waits at the step, though it cannot decide it. The setting is part of the published workflow: a change takes effect for transactions that reach the step after you publish it.
An agent on an integration key never decides at a Human Review step, whatever this says, and neither does the built-in agent. They decide at an Agent Review step.
What the previous reviewer left
Every decision is listed under Comments in the viewer's title bar: when, at which step, who decided and how, with the comment. A person who decided through their own assistant is shown with it, as in "Maria Rossi through Claude"; an agent on an integration key is shown by the key's name. When the step before left a comment, the list opens on its own.
An assistant or agent deciding through the API can also record findings with its decision: what it concluded about a document or a field, and why.
| Finding | Means |
|---|---|
| Corrected | It fixed an extraction error. |
| Document defect | The document itself is wrong, for example lines that do not add up to the total. |
| Unresolved | It could not settle it, which is usually why it sent the transaction on. |
| Confirmed | It checked a value against the page and left it as it was. |
| Observation | Something it noticed outside the issues to review. |
The findings of the last decision are shown at the top of the data panel, on the document they concern, above the issues to review: click a field a finding names to go to it. Findings from earlier decisions stay under their decision in Comments. A person who takes over a transaction an agent sent on starts from what the agent found, not only from the list of errors.
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 |
An agent connected through MCP, or the Assistant, holds a transaction the same way while it works on one: its first change claims it, each later change keeps it, and its decision releases it. An agent that makes no change for the idle timeout loses it. While someone else holds a transaction, an agent's changes to it are refused.
Opening a transaction someone else holds shows who and since when. With the Force checkout permission, Take over takes it from them, a person or an agent; an agent's next change is then refused with your name, and it stops.
Step SLA
A Human 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 Human 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 |
| After an Agent Review | What this step does with an earlier Agent Review's work: review as usual, also review what the agent changed, or let through what the agent approved (with or without changes). | Review as usual |
| 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 |
| Assistants may decide | Whether a person's own assistant may edit and decide at this step, as the person. | On |
| Send To actions | Named extra exits, each with its own comment and assignment rules, and an optional Use when description. | (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 Human 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 Human 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 Human 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.