The Issue Review workflow requires a dataset containing the documents to be coded.
When preparing input data for this workflow:
- Import a dataset that reflects the scope of documents under review.
- Ensure the dataset contains sufficient text to support the coding decisions in your protocol.
- Apply appropriate filtering before import to limit the dataset to relevant documents.
If a review protocol has been added to the collection, link it to the workflow during setup. The protocol becomes the master instruction list that the workflow’s steps draw from.
Steps
Unlike the Privilege and PII/PHI workflows, an Issue Review workflow does not start with a fixed set of components. It starts with a single classification step and you build the pipeline the review needs by adding steps.
There are two kinds of step:
| Step | Purpose |
|---|
| Issue Classification | Codes documents against a set of tags. Each tag carries its own instruction stating when it applies, and a document may receive zero, one, or several tags. |
| Issue Field Extraction | Captures structured fields for each document using a text-generation pass. Runs after the classification steps and uses each document’s predicted tags as context. |
Both kinds can be stacked. Use the Add Step button on the Configuration tab to add one, then select the kind from the Add a step dialog.
When to stack steps
A single step has a working limit, and stacking is how you go past it:
- An Issue Classification step holds up to 50 tags. When the catalogue is larger, add further classification steps; they are labelled Issue Classification Part 1, Part 2, and so on.
- An Issue Field Extraction step holds up to 50 fields. When the field catalogue is larger, add further extraction steps.
Stacking is also useful below those limits — for example, to keep a relevance pass separate from a detailed issue-coding pass, so each can be run, reviewed, and re-run on its own.
Output columns
Each classification step writes its tags to an output column in the results table. On the step’s Output tab you can either create a new column or merge the step into an existing one:
- Separate columns — each step’s coding appears as its own column. Use this when the passes answer different questions, such as a relevance column and an issue column.
- A shared column — two or more steps write to the same column and their predictions combine at the document level. Use this when the steps are parts of one catalogue that was split only because of the tag limit.
Tags must be unique across steps that write to different columns, so the same tag never appears in two places. Steps that share a column are free to share tags — that is what merging means.
Changing a step’s output column after the step has run leaves its earlier results under the old column. Re-run the step to populate the new one.
Field names
Field names must be unique across all Issue Field Extraction steps on the workflow, so each field maps to exactly one column in the results.
Step dependencies
Steps run in the order they appear, and each step’s card shows what it depends on.
- Classification steps have no upstream dependency — their tags and instructions come from the protocol or are entered directly.
- Field extraction runs after classification and uses the predicted tags as context.
- When several field extraction steps are stacked, each one also sees the fields extracted by the step before it, so later passes can build on earlier ones.
A workflow must keep at least one Issue Classification step. Field extraction is optional — the workflow runs without it.
Step Results
The Steps Results view shows how the Issue Review workflow progresses through its steps once it is run, and it is where you review each step’s output.
Selecting a step opens its own tabs:
| Step | Tabs |
|---|
| Issue Classification | Results, Metrics, Instructions, Tags, Model |
| Issue Field Extraction | Results, Instructions |
The Results view lists the documents with the tags applied or the fields extracted, along with the model’s reasoning. The Metrics tab on a classification step reports how its model is performing against reviewed documents. The remaining tabs open the step’s configuration in place, so you can adjust an instruction without leaving the results you are looking at.
Outputs
The Outputs tab displays the consolidated results across every step in the workflow — one row per document, with each classification step’s tag column and each extraction step’s fields.
Outputs may include:
- The tags applied by each classification step, in its own column or merged with another step’s
- The field values captured by each extraction step
- The model’s reasoning for the coding decisions
Review outputs to validate results and determine next steps in your review process. Results can be exported for reporting or for use in downstream review.
Overview
The Overview tab summarizes the shape of the workflow and its last run:
- Steps, Issue tags, Output fields, and Documents counts
- A Pipeline view of the steps in order
- The linked Protocol
- The Last run and its status
Use it to confirm the workflow matches the protocol before running it — particularly the tag and field counts, which are the fastest check that an import landed everything it should have.
Runs
The Runs tab provides a history of workflow activity.
From this tab, you can:
- See when the Issue Review workflow was run or deployed
- Review the status of past runs
- Identify which runs completed successfully and which may require attention
- Confirm which steps were included in a given run
Run history helps support tracking, auditing, and troubleshooting over the lifecycle of the workflow.