Review Setup
Review Setup separates what a review is from when it runs:
- A review programme defines who reviews, what they answer, and the rule that closes the round.
- An automatic rule decides which documents get reviewed, and how often.
Open New → Workflow Setup → Review Setup. The area requires the Documents - Manage Review Schedules permission.
Review programmes
A review programme defines who receives the review task, what reviewers answer, and how their replies decide the round. One programme can serve many rules and schedules, so the reviewer setup is defined once rather than repeated per document.
Save stays disabled until all three required fields are set:
- Name
- Reviewed by (distribution group)
- Action request reviewers answer
| Setting | Choices |
|---|---|
| How the round is decided | First reply decides · Everyone must respond · Everyone must approve · A number of approvals |
| Participants are | Reviewers (blocking) · Approvers (blocking) · Consulted (non-blocking) · Informed (non-blocking) |
| When the file is replaced mid-review | Continue the round · Start the round again · Re-review changed clauses (falls back to whole document) |
Blocking participants hold the round open until they reply. Non-blocking participants can contribute without delaying it.
Days to respond sets the deadline, and Email template for the task chooses the notification reviewers receive.
Advanced options
- Reason shown to reviewers — the message on the assignment. Placeholders: {{document_name}}, {{rev_number}}, {{cycle_number}}, {{due_date}}, plus any document field key.
- After the review closes — run a workflow when the round reaches a chosen outcome.
- Which replies mean what — map replies onto Approve, Changes requested and Reject / withdraw. Unmapped replies are classified by their wording. Map them here to be certain.
Automatic rules
An automatic rule chooses the documents it covers, what happens when the rule is due, how often it repeats, and an optional stop condition.Select Automatic rules → Create automatic rule. The editor follows the order the rule runs in.
1. Which documents should this cover? Scope the rule to a Document type or a Folder, then pick the specific one.
2. What should happen? Either Use a review programme or Run a workflow. A programme creates the reviewer tasks and decision round it defines; a workflow starts on each document when its rule falls due.
3. How often should it run? Set a number and a unit — Hours · Days · Weeks · Months — plus a Time of day and two independent switches:
- Automatically include future matching documents — Documents added or moved into this scope later will receive this rule automatically.
- Start the first run immediately — Otherwise the first run waits for one full interval.
Time of day
An interval on its own falls due at whatever minute the rule happened to be saved, so "every 12 months" drifts to an arbitrary time. Time of day pins it: every 2 weeks at 09:00.
Every half hour from 00:00 to 23:30, in the server time zone. Leave it on Any time to keep the interval landing wherever it falls — which is what every rule created before this setting existed does.
Reviews are checked every 15 minutes, so a round opens at or just after this time.Two things it does not apply to:
- Hourly intervals. The control disappears when the unit is Hours, because pinning a loop that repeats several times a day to one clock time would quietly turn it into a daily one. Sent directly to the API, the pair is refused: A time of day cannot be combined with an hourly review interval.
- Start the first run immediately. That means now, so the first run is not held back to the chosen time. Every run after it lands on the time.
4. When should it stop? Optional. When this condition becomes true for a document, that document stops getting future runs.
Stop conditions
Select Add condition to build the test from document fields, and Add inner group when more than one test is needed.
The condition is checked for each scheduled document before a later run. When it matches, that document stops receiving future runs from the rule. This suits a recurring check that should stop once the document reaches a business state — a delivery confirmed, or a certificate superseded.
Reading a saved rule
A saved rule reads left to right: WHEN DOCUMENTS MATCH → RUN A WORKFLOW → SCHEDULE. The middle caption names whichever action the rule uses. Chips underneath show whether future documents are included, whether the first run is immediate, and any stop condition. Use the Edit (pencil icon) to change it.
Applying a rule to existing documents
A new rule covers future documents only. To bring documents already in scope onto it, select Existing documents on the saved rule and choose a mode:
- New documents only
- All documents that have not been overridden
- All documents, discarding overrides
The preview reports the effect before anything is applied:
This would touch 0 documents: 0 new schedules, 0 updated, 0 left as overrides.
An override is a scheduling choice made on an individual document. Use All documents, discarding overrides only when the rule is meant to replace those choices.
Removing a rule
Select the trash icon on a saved rule and confirm:
Remove this rule and stop future runs for documents that inherited it? Existing review history is kept.
Analytics
Six views are ready in the chart builder and datasource builder with no setup. Pick one as a view source; every join is already made.
| View | What it contains |
|---|---|
view_review_register | One row per document under review, with status and days until due |
view_review_rounds | One row per round: outcome, duration, on time, participation |
view_review_decisions | One row per reviewer decision: who, what, when, how authenticated, version reviewed |
view_review_reviewer_load | Open, overdue and recent tasks per reviewer |
view_review_compliance_monthly | Rounds closed per month with outcomes and on-time rate |
view_review_definitions | The programmes with names resolved and schedule counts |