General Questions
What Checklist is, the objects a checklist attaches to, and how templates, result states and workflow gates behave day to day.
General Questions
What Checklist is, the objects a checklist attaches to, and how templates, result states and workflow gates behave day to day.
Verify in applicationConfirm exact UI labels, menu paths, and behavior in your Polarion instance before relying on them operationally.
What is Nextedy CHECKLIST?
Nextedy CHECKLIST is a plugin for Siemens Polarion ALM that lets teams define, track, and enforce structured checklists on work items, documents, test runs, and plans. It combines a template system for consistent checklist definitions with workflow integration so checklists can gate transitions, such as Definition of Done (DoD) or Definition of Ready (DoR) reviews. See Concepts for the underlying model.Who is Checklist meant for?
Checklist targets project engineers, quality engineers, process engineers, and Polarion administrators who need structured checklist enforcement for process compliance. End users typically check items and review baselines, while administrators handle template setup, workflow configuration, and configuration property management. See Getting Started for role-appropriate starting points.Which Polarion object types can have a checklist?
Checklist supports four object types: work items, documents (LiveDocs), test runs, and plans. Each object type has its own setup path — for example, see Set Up a Plan Checklist and Set Up a Test Run Checklist.What result states can a checklist item have?
Each checklist item can be set to one of four result states: Empty (default — nothing recorded yet), OK (checked/passed), NOK (rejected/failed), and Pending (conditional, available only when the conditional state is enabled — off by default). There is also a non-selectable Information row type for headings/notes that carry no result. These states are the basis for workflow gate logic and baseline comparisons — see Concepts for how result states drive gate enforcement.How do templates work?
A template is a predefined checklist definition that can be associated with a specific work item type, document type, test run, or plan, so that checklists start from a consistent, repeatable set of items rather than being built by hand each time. Work items and documents resolve their template via a configuration property; test runs and plans resolve theirs from the object’s own native template relationship instead. Templates are the standard mechanism for keeping checklist content consistent across similar objects. For a hands-on walkthrough, see Your First Checklist.Can a checklist block a workflow transition?
Yes — Checklist provides workflow functions and workflow conditions that integrate with Polarion’s workflow engine, allowing checklist completion (for example, all items checked, or all mandatory items checked) to gate a status transition. This is the primary mechanism for enforcing Definition of Done and Definition of Ready gates. See Reference for the full list of workflow functions and conditions.What is a baseline, and why would I create one?
A baseline is a frozen snapshot of a checklist at a point in time, used together with baseline comparison views to support audit and compliance reviews — for example, proving that a Definition of Done checklist was fully satisfied at the moment a document revision was approved. Baseline tracking is confirmed for document (LiveDoc) checklists specifically; whether an equivalent mechanism exists for work item, test run, or plan checklists is not confirmed and should be verified in your instance. See Concepts for more on how baselines fit into the broader checklist lifecycle.How are checklist settings configured?
Checklist uses a hierarchical configuration property system (nextedy.checklist.*) with four levels of precedence: a global default, a type-specific override, a field-specific override, and a combined type-and-field-specific override. This lets administrators set an organization-wide default while still tuning behavior for specific work item types or specific fields. See Reference for property syntax and precedence examples.Where can I see which items are mandatory?
A mandatory item is a checklist item that must be completed (resolved to OK or Pending, both of which count as checked) before a gated transition is allowed. In the rendered checklist, mandatory items are shown with a red! icon next to the item and a red left border on the row, so you can see at a glance which items must be completed. The flag is a per-item property, normally set by whoever authors the checklist template — it’s recorded in the item’s underlying text with a ! placed immediately after the result token (e.g. [X]!), not trailing at the end of the line. Administrators can also force every item in a checklist to be treated as mandatory, regardless of individual flags, using the allMandatory configuration property. See Reference for configuration details and Concepts for the item text syntax.Is there more than one FAQ page?
Yes — this page covers general product questions. For questions specifically about what Checklist can and cannot do, see the Capabilities and Limitations FAQ.How the pieces fit together
Capabilities and Limitations
What Checklist currently supports and the known limitations to plan around, based on the confirmed product scope.
Capabilities and Limitations
What Checklist currently supports and the known limitations to plan around, based on the confirmed product scope.
Verify in applicationWhere a capability is not explicitly confirmed below, it is marked as unconfirmed rather than described as working — verify it against your Polarion instance before relying on it.
Which Polarion object types does Checklist support?
Checklist supports four object types: work items, documents (LiveDocs), test runs, and plans. If you need a checklist on an object type outside this list, it is not part of the confirmed feature set. See Concepts for how checklists attach to each supported object type.Can I enforce a checklist before a status change?
Yes — this is a core capability. Checklist provides workflow functions and workflow conditions that plug into Polarion’s workflow engine, so a status transition can be blocked until checklist conditions are met (for example, all items checked, or all mandatory items checked). See Reference for the full list of workflow functions and conditions and their parameters.How many workflow functions and conditions are available?
The product brief confirms seven workflow functions and conditions, including behaviors named around all-checked, mandatory-checked, fail-if-unchecked, apply-template, reset-to-template, and uncheck-all. Exact function names, signatures, and parameters should be confirmed on the Reference page rather than assumed from this summary.Does Checklist support more than pass/fail per item?
Yes — each checklist item can be set to one of four result states: Empty (the default, nothing recorded yet), OK (checked/passed), NOK (rejected/failed), and Pending (conditional). This is richer than a simple checked/unchecked model, letting a reviewer record a failing (NOK) or a conditional (Pending) outcome distinctly from an item nobody has decided yet (Empty). Pending (the conditional state) is only offered when theconditional_enabled property is turned on (it is off by default). There is also a non-selectable Information row type for headings/notes that carry no result and are excluded from completion counts. See Concepts for how result states are used in gate logic.Can I keep an auditable record of checklist completion over time?
Yes, for document (LiveDoc) checklists — Checklist supports baseline tracking, which freezes a checklist snapshot and provides comparison views against that snapshot. This is intended for audit and compliance use cases such as proving a Definition of Done checklist was satisfied at a specific point in time. Baseline tracking is confirmed at the document level; an equivalent mechanism for work item, test run, or plan checklists is not confirmed and should be verified in your instance. See Concepts for details.Can different work item types or fields have different checklist behavior?
Yes — configuration properties (nextedy.checklist.*) resolve through a four-level hierarchy: a global default, a type-specific override, a field-specific override, and a combined type-and-field-specific override. This lets administrators set organization-wide defaults while tuning behavior narrowly where needed. See Reference for property syntax and precedence examples.Can I lock a checklist so it can no longer be edited?
Yes, but “edited” covers two distinct things that lock differently. Locking who can add, remove, or redefine checklist items (the checklist’s structure) is a confirmed capability via theadminPermission configuration property, which can be scoped to a work item type, checklist field, and workflow status — for example, freezing a Definition of Done checklist’s structure once a work item reaches verified. Locking who can check or uncheck existing items, by contrast, is controlled by standard Polarion field permissions (Readonly Fields or Permissions Management), not by a nextedy.checklist.* property. See Reference for both mechanisms.Verify in applicationWhether a dedicated
nextedy.checklist.*.readonly property also exists to drive read-only state directly (as opposed to it being derived purely from standard Polarion field permissions and workflow status) is not confirmed — verify in your instance.Can checklist data be used in reports or dashboards?
Checklist supports summary field aggregation, which rolls up checklist status into a field intended for reporting and dashboard integration. This is distinct from the per-item result states and represents an aggregate view of a whole checklist. See Concepts for more.Can checklists be moved between projects or systems?
Only a narrower, confirmed mechanism exists — this is not a general checklist import/export or migration feature. You can paste existing checklist text directly into a template work item to seed its content, and a template can be referenced from another project using thePROJECTID:WORKITEMID syntax so multiple projects share one centrally-maintained template. Neither of these moves a checklist’s recorded results between projects or systems, and there is no confirmed mechanism for exporting/importing a completed checklist (with its result states) as a portable file for backup or migration purposes.Verify in applicationIf you need to move checklist results (not just template content) between projects or systems, this is not a documented capability — verify directly in your instance before relying on it for migration or backup workflows.