Approval settings that change behavior
The reference layer behind every approval process: the system-wide switches — checkout during approval, hiding routed documents, PIN requirements, button relabeling — and the per-process options that tune one process without touching the rest.
By the end of this page you'll know which lever changes which approval behavior — and, just as useful, which layer it lives on: the system-wide settings that govern every process, or the per-process options that tune just one.
Layer 1 — System Settings (every process at once)
Administration > System Settings > Approval-Process Settings (in the Queues & Workflow group):
| Setting | What it changes |
|---|---|
| Allow documents to be checked out while on an approval process | Off by default — which is why "This document is on an approval process and cannot be checked out." is the message most admins meet first. Turning it on unlocks editing mid-route, plus the dependent setting below |
| Hide checked-out documents in the Approval Queue from other users of the same group | With checkout allowed, keeps two group members from working the same document |
| Hide documents from Search & Catalog Browser when on an Approval Process | Routed documents vanish from casual view until the process ends — for content that shouldn't circulate before it's approved |
| Require PIN for Approval + PIN Length | Approvals demand a personal PIN — a signature-grade confirmation. Heed the setting's own warning: "Changing PIN length resets all users' PINs" |
| Allow limitations on field editing | Unlocks the per-process field-permission options in layer 2 |
| Allow content deletion in Approval Queue | Lets queue workers delete documents from the queue — off unless your process genuinely culls |
| Approve Button Label / Reject Button Label | Approve (Default), Move to [Stage Name], or Custom with your own text — so a review pipeline can say "Send to Legal" instead of "Approve" |
The PIN is the only credential approvals ask for — approve/reject never prompts for a password. And a related switch lives elsewhere: Allow user substitution ("Valid for Work Queue and Approval Queue") is under User Settings, not here.
Layer 2 — the process editor (one process at a time)
Each approval process (Administration > Catalogs & Document Types > the type > Approval Processes > open one) carries its own Options panel. The ones that answer real questions:
- Automatically start this process on all captured content of this document type — the difference between a process people must remember to start and one that just runs.
- Notify member of new arrivals, with Attach document to arrival notification and Include Approve and Reject links in arrival notification — approvals handled from the email itself.
- Require note on all assignments and stage changes — an audit-grade paper trail, at the cost of a required box on every action.
- Allow rejections by first member / Allow custom rejection path — who can bounce a document, and where it bounces to.
- Remove from this process when assigned to any other process — prevents a document riding two routes at once.
- Enable system field — surfaces the process's status as a searchable field.
- Allow selective field editing by active member only / Prevent field editing by all non members when document is on this process — the field-locking pair (the first appears only when layer 1's Allow limitations on field editing is on), with a Field Permissions grid deciding field-by-field.
The same editor holds the Deadlines panel — Enable Deadlines, a process deadline with Divide Process Deadline Among Members, and Deadline Messaging on a repeating schedule to members and the admin tiers you choose.
The questions that land on this page
| "Why can't…" | The lever |
|---|---|
| …anyone check out a routed document? | Layer 1, Allow documents to be checked out… — off by default, on purpose |
| …I find a document I know exists? | Layer 1, Hide documents from Search & Catalog Browser… — it's mid-route |
| …people just approve from the email? | Layer 2, Include Approve and Reject links in arrival notification |
| …we tell who approved what, and why? | Layer 1 PIN for the who; layer 2 required notes for the why |
Success check: change one behavior deliberately — say, approval-from-email — and run a test document through: the arrival email carries the links, and the approval lands with the right identity attached.