Skip to main content
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 existA 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

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). 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 openThe 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:
Verify in applicationThe argument name checklist and its comma-separated multi-field syntax are confirmed by the gathered context; the condition/action structure above (conditionId/functionId attributes, <arguments><argument> nesting) matches the canonical example in Workflow Functions and Conditions, 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 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 youWorkflow 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 gateChecklist 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 (which define what must be checked) and feeding into Baseline Tracking (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.
Last modified on August 31, 2026