> ## Documentation Index > Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt > Use this file to discover all available pages before exploring further. # Workflow Gates: Definition of Done and Definition of Ready > A checklist that nobody is required to complete is just a list. export const LastReviewed = ({date}) => { if (!date) return null; const formatted = new Date(`${date}T00:00:00Z`).toLocaleDateString("en-US", { year: "numeric", month: "long", day: "numeric", timeZone: "UTC" }); return

Last reviewed on {formatted}

; }; Think of the checklist itself as the *questionnaire*, and the workflow gate as the *bouncer at the door*. The questionnaire can exist and be filled out with nobody ever checking it — but the bouncer is what actually stops someone from walking through the door of a status transition until the questionnaire says they're allowed to. ## Two philosophies: conditions vs. functions The gathered context describes two structurally different mechanisms, and the distinction between them is the single most important thing to understand before configuring a gate. **Workflow conditions** *gate the availability* of a transition. A condition is evaluated continuously; if it doesn't pass, the transition button is simply not available (or is shown with an explanation of why it's disabled). Nothing is thrown, no error dialog interrupts the user — the door just isn't there to walk through. **Workflow functions** *actively block execution* if invoked as part of a transition that a user has already initiated. A function throws a user-friendly exception when its condition isn't met, aborting the transition attempt after the user has already tried to click through it. **Why both exist** A condition gives a cleaner user experience (you can't click what isn't there), but functions provide a hard backstop — useful when a transition can be triggered by automation, or when you deliberately want the click to be possible but rejected with an explanatory message rather than silently hidden. Many configurations use conditions for the primary UI experience and rely on the equivalent function as defense in depth. ## The gate-relevant functions and conditions | Name | Kind | Effect | | ----------------------------------- | --------- | ----------------------------------------------------------------------------------------------------- | | `ChecklistAllChecked` | Condition | Enables the transition only if every item in the specified checklist is checked — mandatory or not. | | `ChecklistMandatoryChecked` | Condition | Enables the transition only if every **mandatory** item in the specified checklist is checked. | | `ChecklistFailIfAnyUnchecked` | Function | Throws a user-friendly exception, blocking the transition, if any item in the checklist is unchecked. | | `ChecklistFailIfMandatoryUnchecked` | Function | Throws a user-friendly exception, blocking the transition, if any mandatory item is unchecked. | | `ChecklistApplyTemplate` | Function | Applies the configured template to the checklist field(s) as a transition action. | | `ChecklistResetToTemplate` | Function | Resets the checklist field(s) back to template state, discarding all local progress. | | `ChecklistUncheckAll` | Function | Clears every item's result, without touching the template linkage. | All seven accept a **mandatory `checklist` argument** — the ID of the custom field holding the checklist to act on. Multiple checklists can be evaluated together in a single function or condition call by supplying a comma-separated list of custom field IDs in that argument. ## The all-vs-mandatory distinction, and how `allMandatory` bridges them `ChecklistAllChecked` / `ChecklistFailIfAnyUnchecked` require every item checked. `ChecklistMandatoryChecked` / `ChecklistFailIfMandatoryUnchecked` require only the items flagged **mandatory**. These are genuinely different gates, and choosing the wrong one is a common source of "why did this transition succeed when I have unchecked items" confusion — an unchecked *optional* item never blocks a mandatory-only gate. The two are connected by the `allMandatory` configuration property (see [Configuration Property Hierarchy](/checklist/concepts/configuration-property-hierarchy)). When `allMandatory` is enabled for a checklist, the mandatory-checked gates additionally require that *every* item — not only those individually flagged mandatory — is checked. In other words, `allMandatory` effectively upgrades a "mandatory items only" gate into an "everything" gate without switching which workflow function or condition you're using. diagram ## Applying and resetting templates as transition actions `ChecklistApplyTemplate` and `ChecklistResetToTemplate` are not gates in the "block or allow" sense — they're **actions** that run as part of a transition, changing the checklist's state rather than validating it. `ChecklistApplyTemplate` populates the specified checklist field(s) with the template's predefined items; calling it on a field that already has data re-applies the template on top. `ChecklistResetToTemplate` goes further, discarding local additions entirely and returning the checklist to exactly its template state — this is documented as a **destructive** action, since it discards recorded progress. `ChecklistResetToTemplate` also supports an optional `skipForUsers` argument: a comma-separated list of user IDs for whom the reset is skipped entirely. This exists so that specific accounts — for example, automation or service accounts that trigger the same transition programmatically — don't have their checklist state wiped every time the transition fires. Whitespace around each user ID is trimmed and empty entries are ignored. **skipForUsers fails open** The gathered code context notes that any exception encountered while checking the `skipForUsers` list (for example, a malformed argument) is silently swallowed, and the reset proceeds as if the current user were not on the skip list. Don't rely on a malformed `skipForUsers` value to *prevent* a reset — treat it as fail-open, not fail-safe. `ChecklistUncheckAll` is the simplest of the three actions: it clears every item's recorded result, leaving the checklist's structure (and template linkage) untouched. Use it when the intent is "start the review over" rather than "reset to the officially defined items," which is what `ChecklistResetToTemplate` does instead. ## A representative workflow XML pattern The following illustrates the general shape of wiring a mandatory-checked condition and a fail-safe function together on a transition, using the `checklist` argument documented for these functions and conditions: ```xml theme={null} dor dod ``` **Verify in application** The argument name `checklist` and its comma-separated multi-field syntax are confirmed by the gathered context; the `condition`/`action` structure above (`conditionId`/`functionId` attributes, `` nesting) matches the canonical example in [Workflow Functions and Conditions](/checklist/reference/workflow), but the exact schema can still vary by Polarion version — validate against your project's actual workflow file before relying on it as a copy-paste template. ## Object types supported Gate functions and conditions apply across work items, documents (modules), and test runs. [Workflow Functions and Conditions](/checklist/reference/workflow) confirms this target-type coverage for all seven functions and conditions on this page — `ChecklistFailIfMandatoryUnchecked`, `ChecklistFailIfAnyUnchecked`, `ChecklistUncheckAll`, `ChecklistResetToTemplate`, `ChecklistApplyTemplate`, `ChecklistAllChecked`, and `ChecklistMandatoryChecked` — each resolving its target via `context.getTarget()` with an `instanceof IWorkItem`/`IModule`/`ITestRun` check. There is no `IPlan` branch, so none of these functions or conditions execute against plans. ## Common misconceptions **A gate doesn't retroactively check anything for you** Workflow gates only read the *current* recorded state of a checklist; they never automatically mark items as checked. A common early-adoption question recorded in ticket insights was, in effect, "does completing a checklist affect the work item's status automatically?" The answer implied by the gate mechanism is no in either direction: a gate can *prevent* a transition when items are unchecked, but nothing about checklist completion pushes a status change forward on its own. The transition still has to be explicitly triggered. **Information-type items never satisfy or block a gate** Checklist items with an Information result are excluded from all completion counting used by the underlying checklist logic — they cannot cause `ChecklistAllChecked` to fail, and they can never be "the mandatory item" a `ChecklistMandatoryChecked` gate is waiting on. If a gate isn't blocking when you expect it to, confirm the item you're relying on isn't an information-only row. ## How gates relate to templates and baselines Workflow gates are the enforcement layer sitting on top of [Templates](/checklist/concepts/templates) (which define what must be checked) and feeding into [Baseline Tracking](/checklist/concepts/baselines) (which preserves a record of what was checked when a gate was passed). A gate without a template behind it still works, but produces an unaudited, ad hoc list; a gate without a baseline captured at the transition point leaves no durable evidence that the gate was satisfied at that moment in time, only that it is satisfied *now*. ## Related guides * [Your First Checklist](/checklist/getting-started/your-first-checklist) * [Set Up a Plan Checklist (Tutorial)](/checklist/getting-started/setup-plan-checklist) * [Set Up a Test Run Checklist (Tutorial)](/checklist/getting-started/setup-test-run-checklist)