# Baseline Tracking Source: https://learn.nextedy.com/checklist/concepts/baselines A checklist that only ever shows its *current* state has a fundamental limitation for audit and compliance work: it cannot prove what the checklist looked like at a specific moment in the past. The best mental model is a photograph album next to a whiteboard. The whiteboard (the live checklist field) is always current — anyone can erase and rewrite it. A baseline is a photograph of that whiteboard taken at a specific moment. You can take as many photographs as you like over time, and none of them change when the whiteboard is later erased and rewritten. What baseline tracking gives you is the album of those photographs, in order, each one linked back to the moment it was taken. ## Why baselines exist In regulated processes, it's often not enough to show that a Definition of Done checklist is complete *today* — you need to show it was complete *at the time a specific release, revision, or review was approved*, and that the checklist's content at that point matched what governance required. A live-only checklist can't answer "what did this look like when version 3 was approved," because by the time someone asks, the checklist may have moved on. Baseline tracking exists specifically to answer that question. ## What a baseline actually is A baseline is represented as a lightweight record — not a duplicate copy of the checklist's data, but a reference to a **work item that represents the baseline/revision**, carrying: * an **ID** (typically the revision or baseline value, e.g. a version tag) — used to build baseline links and match a checklist to a specific revision * a **label** (human-readable, typically combining the ID and the associated work item's title, falling back to just the ID if no distinct title exists) * a **date** (the baseline work item's creation date, pre-rendered from the work item's `created` field) * a **URL** linking to the document at that specific baseline revision * a **status** (the underlying baseline work item's workflow status, e.g. Open, Approved — rendered with its normal status icon) * the underlying work item's identifier In other words, "creating a baseline" in this system means creating (or having Polarion create) a work item that stands in for a document revision, and Nextedy CHECKLIST's baseline machinery finds that work item and uses it as an anchor point to reconstruct the checklist as it existed at that revision. A document's live checklist field alongside its baseline work items, each storing a revision identifier used to locate the document at that historical point ## The two configuration properties behind baseline lookup Baseline lookup is driven by document-scoped configuration, resolved via two properties: * `nextedy.checklist.baselines.itemType` — specifies which work item type represents a baseline record for checklist history. **Default: `btask`.** * `nextedy.checklist.baselines.baselineField` — specifies which custom field on that baseline item type stores the baseline/revision identifier. **Default: `baseline`.** These two properties are what let the system build Lucene queries to find either a single baseline item matching a specific revision, or the full set of baseline items associated with a document. If your project uses a different work item type or field to represent revisions, these are the properties to adjust — but note that, unlike the four-level type/field/status hierarchy described in [Configuration Property Hierarchy](/checklist/concepts/configuration-property-hierarchy), these two are read per-document rather than resolved through that broader precedence chain. **Verify in application** These two properties and their defaults are documented, but no narrower per-type or per-field scoping is documented for them, unlike most other Checklist configuration properties. Treat them as document-scoped settings rather than assuming they participate in the same four-level hierarchy used elsewhere, and verify this in your Polarion instance before relying on it. ## Two ways a document's baseline history renders The baseline view for a document behaves differently depending on whether you're looking at a *specific* revision or browsing the *history* as a whole: 1. **General listing mode** — queries all baseline work items associated with the document (via the configured item type and baseline field), sorts them by the baseline field, and renders each as a row showing its label, date, status, and a link to that revision. This is the "photo album" view. 2. **Revision-scoped rendering mode** — when a specific revision context is active, the view looks up the matching baseline work item for that revision and renders the checklist *as it existed at that baseline* rather than the live checklist. This is opening a single photograph instead of browsing the album. The view also automatically adapts when a document is being exported or rendered as a PDF, switching its render mode based on that context. **Verify in application** A flag exists to mark the baselines view as hidden when a document is exported to PDF, but its effect on the exported output is unconfirmed. Confirm in your Polarion instance whether setting this flag actually suppresses the baselines list in PDF output before relying on it for a compliance document that must not show baseline history in its exported form. ## Baselines are read-only history, not editable state A critical distinction: baseline tracking is a *reporting and traceability* feature, not an editable one. You don't check or uncheck items against a historical baseline — you view what was recorded. The live, editable checklist lives on the current document; baselines only ever look backward at frozen work-item-anchored snapshots. This is why baseline tracking pairs so naturally with [Workflow Gates](/checklist/concepts/workflow-gates): a gate enforces that a checklist is complete *before* a transition (for example, before a document is approved or a revision is finalized), and a baseline captured at that same point in time gives you durable, queryable evidence that the gate's requirement was actually satisfied when the transition happened — not just that it happens to be satisfied whenever someone looks at it later. ## Common misconceptions **A baseline is not a copy of the checklist's data** It's tempting to assume a baseline stores its own independent copy of every checklist item and result. A baseline is better understood as a *pointer* — a work item representing a revision, located via a Lucene query against a configured item type and field — from which the checklist as it existed at that document revision is reconstructed. The baseline mechanism depends on the underlying document revision actually being preserved (a standard Polarion document versioning capability); the baseline work item itself does not duplicate the checklist content independently of that revision. **Changing the baseline item type or field affects lookup, not history** Reconfiguring `nextedy.checklist.baselines.itemType` or `nextedy.checklist.baselines.baselineField` changes which work items the system searches for when building the baseline list — it does not migrate or relabel work items that already exist under the old type/field. If you change these properties after baselines are already in use, previously created baseline work items under the old type/field will no longer be found unless they're also updated to match. ## Object scope Baseline tracking is documented specifically in terms of **documents** — the baseline view is built and queried per-document, and the baseline work item's URL links to the document at that specific baseline revision. Work item, test run, and plan checklists are covered elsewhere by templates and workflow gates, but the baseline/history mechanism is a document-level capability. **Verify in application** If your process requires historical snapshots of work item, test run, or plan checklists (rather than document checklists), confirm in your Polarion instance whether an equivalent baseline mechanism exists for those object types. Only document-level baseline tracking is documented. ## 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) # Checklist Items, Result States, and Text Syntax Source: https://learn.nextedy.com/checklist/concepts/checklist-items-and-result-states Every checklist in Nextedy CHECKLIST is built from the same fundamental unit: the checklist item. ## The checklist item: one row, several independent facts A checklist item is not just a label and a checkbox. It's a small record that carries several independent pieces of information at once: * **Label** — the visible text of the item, such as "Peer review completed." * **Result state** — the current outcome recorded for this item: **Empty** (default), **OK**, **NOK**, or **Pending** (plus a separate, non-selectable **Information** row type). * **Mandatory flag** — whether this item must be checked for the checklist to be considered complete. * **Description** — static guidance text, typically written once by whoever authored the template, explaining what the reviewer should actually check. * **Note** — free text a reviewer adds while working the item, distinct from the description. * **Template origin** — whether the item was populated from a checklist template or added directly on this instance. A useful analogy: the label and description are like the printed instructions on a paper form ("check that the fire extinguisher is present — see inspection guide §3"), while the note is what the inspector scribbles in the margin ("replaced 2024-03-01, next due 2025-03-01"). Both live on the same row, but they come from different authors and serve different purposes — the description doesn't change reviewer to reviewer, the note does. **An item with no result set is still meaningful** An item that has never been touched defaults to the `Empty` / none state rather than to some arbitrary value. This matters when you're reasoning about "why does this checklist show as incomplete" — an item nobody has looked at yet is indistinguishable, at the data level, from one explicitly reset. ## The result states A plain checkbox collapses reality into two states: checked or not. A compliance-grade checklist needs more resolution than that, because "reviewed and accepted", "reviewed and explicitly rejected", and "nobody has looked at this yet" are materially different facts — and an audit needs to be able to tell them apart. | Result state | Stored char | Meaning | Counts as "checked" for gating? | | ----------------------- | ----------- | -------------------------------------- | ------------------------------------------------ | | `Empty` (None) | `_` | No decision recorded yet — the default | No | | `OK` (Checked) | `X` | Reviewed and accepted | Yes | | `NOK` (Rejected) | `O` | Reviewed and explicitly rejected | No | | `Pending` (Conditional) | `+` | Accepted conditionally, or still open | Yes — treated as checked for completion purposes | **Common misconception: Pending is not the same as unchecked** Because `Pending` sounds provisional, it's tempting to assume it doesn't count toward completion. In fact, an item accepted conditionally is treated the same as a fully checked item when a workflow gate evaluates whether mandatory items are satisfied. If your process needs conditional acceptances to be visibly flagged for later follow-up even though they pass the gate, that follow-up has to happen through the note field or a separate review step — the gate itself won't distinguish `OK` from `Pending`. **Pending depends on a feature toggle** `Pending` corresponds to the underlying "Conditional" result state, which is only offered to users when the `nextedy.checklist.conditional_enabled` configuration property is set to `true` — it defaults to `false`, so a fresh installation does not show `Pending` as an option until an administrator enables it. See [Configuration Property Hierarchy](/checklist/concepts/configuration-property-hierarchy) for where this toggle fits among other checklist-wide properties, and [Icon, Feature-Toggle, and Baseline Properties](/checklist/reference/configuration/appearance-and-feature-properties) for the full reference entry, including the companion `conditional_sign` icon property. There is also a separate, non-actionable row type used for annotations rather than review steps: an **Information** entry (stored char `i`) that carries guidance text but is excluded from every count and completion calculation. Think of it as a section header or a comment embedded in the checklist rather than a thing to check — it never blocks a mandatory-item gate and never appears in progress statistics, because it isn't a decision anyone needs to make. For example, a checklist with two Information rows ("Section: Code Quality" and "Section: Documentation") plus three actionable rows (one `OK`, one `Empty`, one `Pending`) counts only those three actionable rows toward completion — the two Information rows are excluded entirely. ## Mandatory vs. "all checked": two different gates Two related but distinct questions get asked of a checklist, and conflating them is a frequent source of confusion when setting up workflow gates: * **Is every *mandatory* item checked?** — satisfied when all items flagged mandatory hold a checked-equivalent result (`OK` or `Pending`). * **Is *every* item checked, mandatory or not?** — a stricter requirement that only passes when nothing is left in `NOK` or `Empty`, regardless of the mandatory flag. An administrator-level configuration property can force the stricter "all items" behavior even for a checklist that has no items individually flagged mandatory — effectively saying "treat this entire checklist as if every row were mandatory." Which of the two gates is in effect determines what a reviewer is actually required to resolve before a transition becomes available. See [Workflow Gates: Definition of Done and Definition of Ready](/checklist/concepts/workflow-gates) for how these two evaluations map onto specific workflow functions and conditions. ## The text syntax: why raw field content matters Because a checklist is ultimately stored as text in a custom field, that text has a syntax — and understanding it explains why hand-editing a checklist field directly, or letting some other integration write to it, can silently corrupt the checklist: * Each item is one line that starts with its result state in **square brackets** — `[_]` Empty, `[X]` OK, `[O]` NOK, `[+]` Pending, `[i]` Information — followed by a tab and then the label. * A `!` placed **immediately after the closing bracket** (before the tab) marks the item mandatory, e.g. `[X]!⇥Label`. * A leading `/` marks a description line, attached to the item above it. * A leading `>` marks a note line, attached to the item above it. ```text theme={null} RAW FIELD TEXT PARSED MEANING ----------------------------------- --------------------------------- [X]! Review code changes OK · mandatory · "Review code changes" /See the style guide description of the item above [_] Update documentation Empty · not mandatory >Draft ready, awaiting review note on the item above [+] Run regression suite Pending (conditional accept) ``` (The separator between the bracketed state and the label is a literal **tab**; it is shown as spaces above for readability.) **This is why field type matters** Checklist fields are set up as plain multi-line text, not rich text, precisely so this syntax round-trips reliably. When a checklist field's type gets changed to rich text underneath it — which has been observed as a side effect of using certain built-in Polarion work item templates — the syntax can be mangled and items can appear duplicated. If you see duplicated checklist items right after a work item is created from a template, this text-syntax dependency is the place to start investigating; see [Templates](/checklist/concepts/templates) for the documented workaround. ## Where items come from: manual entry vs. templates An item's `fromTemplate` flag records whether it arrived via a checklist template or was typed directly into this specific instance. This isn't just metadata — it's the hook that makes template-driven updates possible. When a checklist is re-parsed against its template, matching items are updated in place by identifier rather than duplicated, which is what allows a template author to add or reword a review step centrally and have it reflected everywhere the template is referenced, without wiping out notes or results reviewers have already recorded on other, unrelated items. **Template edits reach existing items** On a template-driven merge, an item's label, mandatory flag, and description are refreshed from the template while only the recorded **result** is preserved. So editing a template to change which items are mandatory (or to reword an item) **does** propagate to already-existing checklists the next time each one is parsed — you can rely on template edits to retroactively change mandatory flags and labels. ## Building the mental model The pattern to hold onto: a checklist item is a small bundle of independent facts (label, result, mandatory, description, note, origin), the result states exist because binary checked/unchecked can't represent "reviewed and rejected" or "accepted conditionally" versus "not yet reviewed," and the whole structure is serialized to a specific text syntax that both the rendering UI and any workflow logic depend on being well-formed. Once that clicks, the behavior of workflow gates, template merges, and baseline comparisons (covered in [Workflow Gates: Definition of Done and Definition of Ready](/checklist/concepts/workflow-gates), [Templates](/checklist/concepts/templates), and [Baseline Tracking](/checklist/concepts/baselines)) follows naturally from this underlying data model rather than needing to be memorized as separate rules. For a broader orientation to how these pieces fit into the product as a whole, see [What Is Nextedy Checklist](/checklist/concepts/what-is-checklist). For hands-on setup instead of concepts, start with [Getting Started](/checklist/getting-started/index). # Configuration Property Hierarchy Source: https://learn.nextedy.com/checklist/concepts/configuration-property-hierarchy Nextedy CHECKLIST is configured almost entirely through **configuration properties** — dot-notation keys set in **Administration > Configuration Properties**. ## The problem the hierarchy solves Imagine you administer a project with a dozen work item types, each with its own Definition of Done (DoD) and Definition of Ready (DoR) checklist. Some rules genuinely apply everywhere (nobody outside the QA role should ever be able to restructure a checklist). Other rules are far more specific (only while a `userstory` is in status `draft` can the DoR checklist be edited at all). If every property had to be written out in full for every type, every field, and every status combination, your configuration would be enormous and contradiction-prone. The configuration property hierarchy solves this by letting a single property key omit the segments it doesn't need to be specific about. A property with fewer segments is a broader default; a property with more segments is a narrower override. The system searches from most specific to least specific and applies the first match it finds. ## The general shape of a property key Properties follow the pattern: ```text theme={null} nextedy.checklist._TYPEID_._FIELDID_.propertyName ``` Both `_TYPEID_` (the work item type) and `_FIELDID_` (the checklist's custom field ID) are optional. This is confirmed directly for the `allMandatory` property, which controls whether every item in a checklist is treated as mandatory: ```text theme={null} nextedy.checklist.userstory.dod.allMandatory=true # applies only to 'dod' on 'userstory' nextedy.checklist.dod.allMandatory=true # applies only to 'dod', for any work item type nextedy.checklist.userstory.allMandatory=true # applies to any checklist, for 'userstory' only nextedy.checklist.allMandatory=true # applies to every checklist, on every type ``` **The system searches for the properties in the order listed above** — meaning the most specific form (type + field) is checked first, and the search falls back toward the fully generic form only if nothing more specific is set. diagram **Mental model: think 'CSS specificity,' not 'first property wins'** The most useful analogy is CSS specificity: a highly specific selector (an ID selector) beats a general one (a type selector), regardless of the order the rules are written in the stylesheet. Configuration properties behave the same way — it doesn't matter what order you *typed* the properties into Configuration Properties; what matters is how many segments each key specifies. The narrowest applicable key always wins. ## A four-segment example: `adminPermission` The clearest illustration of the full hierarchy is `adminPermission`, which controls who is allowed to change a checklist's *structure* (add or remove items) as opposed to merely checking items off. Its full key shape adds a workflow status segment: ```text theme={null} nextedy.checklist._TYPEID_._FIELDID_._STATUS_.adminPermission ``` The documented evaluation order — checked from most specific to least specific — is: 1. `nextedy.checklist.userstory.dod.accepted.adminPermission` 2. `nextedy.checklist.dod.accepted.adminPermission` 3. `nextedy.checklist.userstory.dod.adminPermission` 4. `nextedy.checklist.dod.adminPermission` 5. `nextedy.checklist.userstory.accepted.adminPermission` 6. `nextedy.checklist.accepted.adminPermission` 7. `nextedy.checklist.userstory.adminPermission` 8. `nextedy.checklist.adminPermission` Notice the pattern: type+field+status beats type+status, which beats field+status, which beats type+field, and so on, down to the fully generic key with no segments at all. The accepted values for `adminPermission` are `@none` (nobody, including admins, may restructure the checklist), `@all` (any user may), or a comma-separated list of user roles (including project-specific roles). ```text theme={null} # 'dod' checklist can be restructured by global admins and the project_developer role nextedy.checklist.dod.adminPermission=admin,project_developer # but once a 'userstory' reaches 'verified', its 'dod' checklist structure is frozen for everyone nextedy.checklist.dod.verified.adminPermission=@none # 'dor' checklist can never be restructured on 'userstory' items... nextedy.checklist.userstory.dor.adminPermission=@none # ...except while the item is still in 'draft', when anyone can restructure it nextedy.checklist.userstory.dor.draft.adminPermission=@all ``` This is exactly the kind of "freeze the definition once review starts, but let it evolve early" process rule that regulated teams need, expressed as ordinary property configuration rather than custom workflow logic. **adminPermission governs structure, not checking items** This distinction matters enough to repeat: `adminPermission` controls who may add, remove, or redefine checklist items. It says nothing about who may mark existing items as checked or unchecked — that's controlled by ordinary Polarion field permissions (Readonly Fields or field-based Permissions Management), which is a completely separate mechanism layered on top of the checklist-specific hierarchy. ## Other properties that follow the same pattern The hierarchy isn't unique to `allMandatory` and `adminPermission` — it's the general resolution mechanism for checklist-scoped settings. `workItemTemplateId` and `documentTemplateId` (covered in [Templates](/checklist/concepts/templates)) resolve exactly the same way: a property scoped to `_TYPEID_._FIELDID_` is more specific than one scoped to `_FIELDID_` alone, which in turn is more specific than an unscoped global default. Some properties, however, are **not** part of this type/field hierarchy at all — they're plugin-wide settings with a single fixed key, not a family of increasingly specific overrides. These are `nextedy.checklist.debug` (troubleshooting logging, default `false`), `nextedy.checklist.conditional_enabled` (master toggle for the Conditional result state — surfaced in the UI as `Pending`, see [Checklist Items, Result States, and Text Syntax](/checklist/concepts/checklist-items-and-result-states) — default `false`, disabled until an administrator sets it; full reference at [Icon, Feature-Toggle, and Baseline Properties](/checklist/reference/configuration/appearance-and-feature-properties)), `nextedy.checklist.searchAttempts` (default `30`), and the icon overrides `nextedy.checklist.checked_sign`, `nextedy.checklist.unchecked_sign`, `nextedy.checklist.no_sign`, and `nextedy.checklist.conditional_sign`. Don't assume every `nextedy.checklist.*` key participates in type/field narrowing — check the specific property's documentation. **Verify in application** The baseline-related properties `nextedy.checklist.baselines.itemType` (default `btask`) and `nextedy.checklist.baselines.baselineField` (default `baseline`) are read per-document rather than following the full type/field/status hierarchy described above. Confirm in your Polarion instance whether these support any narrower scoping before assuming they behave identically to `allMandatory` or `adminPermission`. ## Common misconceptions **A missing narrow property does not mean 'no rule applies'** A frequent point of confusion is assuming that if you haven't explicitly set a type-specific or field-specific property, the checklist has *no* governing rule. In fact, the system always falls through to the global default (`nextedy.checklist.propertyName`) if one exists, or to the property's built-in default value if no property at all is set anywhere in the hierarchy. "Unconfigured" at the narrow level is not the same as "unconfigured" overall. **Document-level checklists may not share every property's exact syntax** Do not assume that the freeze/permission behavior available for work item checklists (like `adminPermission`) is also available, with the same syntax, for document-level checklists. A document-scoped equivalent does exist for `controlField` (`nextedy.checklist.document._TYPEID_._FIELDID_.controlField`), but the full hierarchy and exact key shape for document-level `adminPermission` is unconfirmed. Verify this in your Polarion instance before relying on it. ## Why this design matters for compliance In a regulated setting, the ability to say "this rule is the organization-wide default, but this specific type in this specific status has a documented, deliberate exception" is not a convenience feature — it's what lets a single configuration file serve as an auditable record of process policy. Because every property key encodes its own scope directly in the key name, an auditor (or a future administrator) can read the full list of configuration properties and reconstruct the entire rule set without needing separate documentation of "which override wins in which case" — the specificity of the key itself answers that question. ## Related guides * [Your First Checklist](/checklist/getting-started/your-first-checklist) * [Templates](/checklist/concepts/templates) * [Workflow Gates: Definition of Done and Definition of Ready](/checklist/concepts/workflow-gates) # Concepts Source: https://learn.nextedy.com/checklist/concepts/index These pages explain how Nextedy CHECKLIST works under the hood — the mental models behind result states, templates, configuration properties, workflow gates, and baselines. What Checklist is, the objects it attaches to, and how it fits into a Polarion workflow. The result states an item can hold and the text syntax used to represent them. How predefined checklist templates keep checklists centrally managed and consistent. The 4-level precedence system used to resolve `nextedy.checklist.*` properties. How workflow functions and conditions turn a checklist into an enforceable gate. How frozen checklist snapshots support audit and compliance review. **Looking for step-by-step instructions instead?** These pages explain concepts, not procedures. For hands-on setup, start with [Getting Started](/checklist/getting-started/index) or browse [Guides](/checklist/guides/index). # Templates Source: https://learn.nextedy.com/checklist/concepts/templates A checklist template is the single source of truth for what a checklist *should* contain. Think of a template the way you'd think of a form used in a paper-based audit process: the form itself (the questions, the order, which boxes are mandatory) is designed once by a process owner. Copies are then handed out to individual reviewers, who fill in their own answers, but nobody is allowed to change the questions on the form itself. Nextedy CHECKLIST templates work the same way — the template defines the *shape* of the checklist, and individual work items, documents, test runs, and plans hold their own *progress* against that shape. ## Why templates exist Without a template, a checklist is just free text typed directly into a custom field. That works for a one-off list, but it breaks down the moment you need the same review criteria applied consistently across dozens or hundreds of objects — which is exactly the situation in regulated environments where Definition of Done (DoD) and Definition of Ready (DoR) gates must be identical across a whole project or product line. Templates solve two distinct problems at once: * **Consistency** — every work item of a given type gets the same checklist items, in the same order, with the same mandatory items flagged. * **Central maintenance** — when the process changes (a new mandatory review step is added, for example), you edit the template once, and, depending on how the template is applied, that change can propagate outward instead of requiring you to hunt down and edit every individual work item. ## Two ways templates are defined There are two distinct mechanisms for supplying a template, and they behave differently enough that mixing them up is a common source of confusion. ### 1. Configuration-property templates The first — and generally preferred — approach points a checklist at a **template work item** (or template document) purely through a configuration property: ```text theme={null} nextedy.checklist._TYPEID_._FIELDID_.workItemTemplateId=WI-124 ``` Here, `_TYPEID_` is the work item type (for example `requirement`) and `_FIELDID_` is the checklist ID — the ID of the custom field that holds the checklist (for example `chkApproved`). Both parts of the key are optional, which is what makes this mechanism hierarchical: you can scope a template narrowly to one type and one checklist, or broadly to any checklist of any type. This precedence behavior is covered in depth in [Configuration Property Hierarchy](/checklist/concepts/configuration-property-hierarchy) — templates are simply one property that follows that same resolution pattern. For documents (LiveDocs), the equivalent property points at a document path instead of a work item ID: ```text theme={null} nextedy.checklist.documentSpecification.documentReadyChecklist.documentTemplateId=Specification/Product Spec Template ``` The important consequence is that **all changes to a checklist template are instantly promoted** — because the checklist items themselves are not copied into the work item at creation time; they're read from the template location, live, at parse time. This is a fundamentally different mental model from a "starter" or "seed" list: it is a live pointer, not a snapshot. **Global templates across projects** A template doesn't have to live in the same project as the objects using it. Prefixing the template ID with a project ID (`myOtherProject:WI-124`) lets you centralize a template in one project and reuse it from any number of downstream projects — useful when a compliance team owns the agreed DoD/DoR definitions and product teams simply consume them. ### 2. Polarion built-in work item templates The second approach uses Polarion's own built-in work item templating (create a work item titled something like "TEMPLATE", mark it resolved so it disappears from default views, and reference it from the `workitem-type-enum`). This piggybacks on a platform feature that predates the checklist product. **Known interaction with Polarion's template copy behavior** When Polarion's built-in template mechanism copies data from the template into a newly created work item, it can change the checklist field's format from Text to Richtext — which corrupts the checklist's expected text syntax. The workaround is to add a `ChecklistResetToTemplate` workflow function to the type's "init" workflow action, with a `checklist` parameter naming the affected custom field, so the checklist is re-parsed (and its format corrected) immediately after creation. This is a Polarion-side issue rather than a defect in Checklist itself. ## The merge model: how a template's items reach a work item Understanding *how* a template's items combine with an object's own checklist field explains a lot of behavior that otherwise looks surprising. When a checklist is parsed, template items are merged into the object's existing items using an ID-based match: * If an item ID from the template does **not** already exist on the object, it's added as a new item (marked as originating from the template). * If an item ID **does** already exist, only its **result** is carried over from the stored content — its label, mandatory flag, and description are refreshed from the template. In other words, the template keeps control of the *shape* of each item (its wording and whether it's mandatory), while the reviewer's recorded **result** (checked / rejected / conditional / empty) is preserved. A template's items merging into a work item's checklist field by item ID, with labels and mandatory flags carried over while recorded results are preserved This merge-by-ID behavior is also what powers **template re-sync**: if the process owner adds a new mandatory item to the template, every work item that reads that template picks up the new item the next time its checklist is parsed — without disturbing results already recorded against the items that already existed. **Changing an item's mandatory flag reaches existing objects** Because label, mandatory flag, and description are always taken from the template on merge, changing whether an existing template item is mandatory (or editing its wording) **does** reach in-flight objects — the change is picked up the next time each object's checklist is parsed. Only the recorded result stays with the object. This applies to already-existing items, not just newly-added ones. ## Item-level template metadata: `fromTemplate` Each checklist item internally tracks whether it originated from a template (as opposed to being added manually to that specific object). This distinction matters conceptually even where the UI doesn't surface it directly to end users: a template-sourced item represents a process requirement handed down from a governing definition, while a manually-added item represents something a specific reviewer decided to track locally. Documentation and process design should treat these as different categories of checklist content — one is centrally governed, the other is ad hoc. ## Object types that can carry a template Template resolution is supported for all four object types that Checklist can attach to: | Object type | Template resolution source | | ------------------ | ------------------------------------------------------------ | | work item | linked template work item, resolved via `workItemTemplateId` | | document (LiveDoc) | linked template document, resolved via `documentTemplateId` | | test run | the test run's own template test run | | plan | the plan's own template plan | Test runs and plans resolve their template from the object's native "template" relationship rather than from a configuration property pointing at an arbitrary object — a subtle but important distinction from the work item and document cases. ## Multiple templates for the same checklist By default, the system picks a template based on the work item or document type alone. But the resolution can be made conditional on the value of another field — a **control field** — so that, for example, a `requirementReady` checklist loads a different template depending on whether a `requirementType` custom field is set to `system` or `software`: ```text theme={null} nextedy.checklist.workitem.requirementReady.controlField=requirementType nextedy.checklist.system.requirementReady.workItemTemplateId=EL-120 nextedy.checklist.software.requirementReady.workItemTemplateId=EL-121 ``` This is the same dot-notation property hierarchy used everywhere else in Checklist configuration, just with the control field's value substituted in place of the work item type segment. The equivalent mechanism exists for documents via `nextedy.checklist.document._CHECKLISTID_.controlField`. ## Common misconceptions **A template is not a one-time starter list** New users sometimes assume that applying a template simply seeds a work item with an initial set of items that can then be freely edited without consequence, the way a code snippet inserts boilerplate text. In practice, template items remain linked by ID to the template's own items, and re-parsing (or an explicit reset/apply-template workflow action) re-syncs against the template. Treat template items as *governed* content, not a one-time copy. **Editing the template does not retroactively fix already-corrupted fields** If a checklist field's format was already corrupted by Polarion's built-in template-copy bug (Text becoming Richtext), simply pointing to a correct configuration-property template afterward does not undo that corruption on existing objects. The `ChecklistResetToTemplate` workflow function is the documented remedy, and it must actually run against the affected object. ## Where templates fit in the bigger picture Templates are one of three pillars that make checklist enforcement possible in a regulated process: the **template** defines what must be checked, [workflow gates](/checklist/concepts/workflow-gates) enforce that it *is* checked before a transition is allowed, and [baselines](/checklist/concepts/baselines) preserve historical proof of what was checked at a point in time. Templates answer the "what should this checklist contain" question; they say nothing on their own about whether completing it is required to proceed — that's the workflow gate's job. ## 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) # What Is Nextedy Checklist Source: https://learn.nextedy.com/checklist/concepts/what-is-checklist Nextedy CHECKLIST is an actionable checklist app for Siemens Polarion ALM. Checklist Example ## The problem: checklists that nobody enforces Most engineering organizations already have checklists — a Definition of Done, a peer-review checklist, a release-readiness list. The usual home for these is a wiki page, a document template, or a rich-text field that someone pastes into a work item. The problem is that none of these are *actionable*: nothing stops a reviewer from approving a work item with half the items unaddressed, nothing distinguishes "not applicable" from "forgot to check," and nothing captures what the checklist looked like at the moment a milestone was reached. Checklist exists to close that gap for regulated and process-driven environments — teams working under ISO 26262, Automotive SPICE, or IEC 62304, where a Definition of Done or Definition of Ready has to be demonstrably enforced, not just written down. Instead of a block of text, a Checklist-backed field becomes a small structured object: a list of checklist items, each with its own result state, that Polarion's workflow engine can inspect and act on. ## The core idea: a checklist is data, not decoration The most important mental shift is this: a Checklist is not a UI widget bolted onto a field — it's structured data stored *as* that field's content. Checklist reads a plain-text (or rich-text) custom field, parses it into a checklist item, and renders that as an interactive checklist form extension. When a user checks an item, the change is posted back and re-serialized into the same field. This is why Checklist can attach to so many different kinds of Polarion objects — work items, documents (LiveDocs), test runs, and plans — without needing a bespoke integration for each: as long as the object has a text-based custom field, the same parsing and rendering logic applies. **Checklist is not limited to work items** A recurring point of confusion in support requests is whether Checklist works on documents as well as work items. It does — Checklist supports work items, documents (LiveDocs), test runs, and plans as attachment points, each with its own configuration path. ## Anatomy of a checklist item Checklist Row Each row in a checklist carries a small set of properties, and understanding them clarifies what a checklist *can* express versus what it can't: * **Label** — the visible text of the item (for example, "Review code changes"). * **Result state** — the current outcome: **Empty** (default), **OK**, **NOK**, or **Pending**. This is the field the workflow engine actually inspects. (A separate, non-selectable **Information** row type also exists, for headings or annotations that carry no result.) * **Mandatory flag** — whether this specific item must be checked before the checklist counts as complete. * **Description** — static, template-authored guidance text for the item (rendered distinctly from a note). * **Note** — a free-text annotation a reviewer adds while working through the checklist, separate from the description. * **Template origin** — whether the item came from a template or was added locally. Think of description and note as two different audiences writing to two different fields on the same row: the template author explains *what to check* (description), while the reviewer records *what they found* (note). ## Result states: more than a checkbox A plain checkbox only has two states. A Checklist item supports **four** result states, because "reviewed and accepted", "reviewed and rejected", "accepted conditionally", and "not yet looked at" are different facts, and conflating them is exactly how compliance checklists lose their evidentiary value. | Result state | Stored char | What it represents | Counts as complete? | | --------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | | Empty (None) | `_` | No decision recorded yet — the default | No | | OK (Checked) | `X` | Reviewed and accepted | Yes | | NOK (Rejected) | `O` | Reviewed and explicitly rejected | No | | Pending (Conditional) | `+` | Accepted conditionally / still open. Disabled by default; an administrator enables it via `nextedy.checklist.conditional_enabled`. | Yes | **Rendered as icons** In the running product the states show as icons only (no text label): an empty square (Empty), a checked square (OK), a minus square (NOK), and a plus square (Pending). The icon classes are configurable — see [Icon, Feature-Toggle, and Baseline Properties](/checklist/reference/configuration/appearance-and-feature-properties). The distinction that trips people up most often is between an item that is **Empty** (nobody has looked at it) and one marked **NOK** (somebody reviewed it and explicitly rejected it). Both leave the item "not checked", but only NOK represents a completed review decision. See [Checklist Items, Result States, and Text Syntax](/checklist/concepts/checklist-items-and-result-states) for the full breakdown, including how these states interact with mandatory-item logic. ## Templates: one definition, many instances Rather than typing the same checklist items into every work item, document, test run, or plan, you define a template once and reference it from a configuration property. When Checklist parses a checklist field, it can merge in items from the linked template — meaning the same review steps are visible on hundreds of items in different sheet, and updates to the template's items propagate the *item content*, not just the result state, to anywhere the template is referenced. For example, the same checklist template can be referenced from a work item's `dod` field, a document's `dodField`, and a test run's `testDone` field at once, and each one merges in the template's items. This is the mechanism behind Definition of Done and Definition of Ready: define the required steps once, in one place, and every object of that type inherits them. See [Templates](/checklist/concepts/templates) for how template resolution actually works, including the type-specific and field-specific property forms. ## Configuration properties: precedence, not just settings Checklist behavior — which items are mandatory by default, which template applies, how summaries are calculated — is controlled through `nextedy.checklist.*` configuration properties set in **Administration > Configuration Properties**. The mental model to hold here is precedence, not just key-value lookup: a property can be scoped globally, to a work item type, to a specific checklist field, or to both a type and a field at once, and Checklist searches from most specific to least specific. For example, `nextedy.checklist.userstory.dod.allMandatory=true` applies only to the `dod` checklist on `userstory` items, while `nextedy.checklist.allMandatory=true` is a blanket default for every checklist in the project. This lets an administrator set a sane default once and override it narrowly wherever a specific work item type or checklist needs different behavior. The full precedence order and worked examples are in [Configuration Property Hierarchy](/checklist/concepts/configuration-property-hierarchy). ## Workflow gates: from checklist to enforcement A checklist that nobody is required to complete is just documentation. Checklist becomes *enforcement* when it's wired into Polarion's workflow engine via workflow functions and workflow conditions attached to transitions. The distinction between the two matters conceptually: * A **workflow function** is an action that runs during a transition. Some functions (like the fail-if-unchecked family) actively block the transition by throwing a user-visible error if mandatory items aren't checked. Others (reset-to-template, uncheck-all) mutate the checklist state itself as a side effect of the transition. * A **workflow condition** is a guard evaluated *before* a transition is even offered. If the condition fails, the transition button is simply unavailable or disabled, with a human-readable message explaining which checklist is incomplete. Workflow condition gate: a transition attempt checks whether mandatory items on the dod checklist are checked, and either proceeds or is disabled with a message This is the concrete mechanism behind Definition of Done and Definition of Ready gates: a work item, document, or test run cannot leave a given state until its associated checklist satisfies whatever rule the administrator configured. See [Workflow Gates: Definition of Done and Definition of Ready](/checklist/concepts/workflow-gates) for the available functions and conditions and how to wire them into `workflow.xml`. ## Baselines: freezing a checklist in time Enforcement answers "was this checked before we proceeded?" Baseline tracking answers a different, equally important question for regulated environments: "what did the checklist look like *then*, and can we prove it?" A baseline is a frozen snapshot of a checklist's state at a point in time, which supports the kind of historical comparison an auditor or safety reviewer expects — not just "is it complete now" but "what changed between this milestone and the last one." See [Baseline Tracking](/checklist/concepts/baselines) for how baseline records are structured and queried. ## Putting it together The pieces compose into a single lifecycle: a template defines the review steps once; a configuration property links that template (and any mandatory-item rules) to a specific field on a specific object type; the checklist form extension renders that field as an interactive checklist for reviewers to work through; a workflow function or condition inspects the resulting result states to gate a transition; and, where audit trails matter, a baseline preserves what the checklist looked like at that moment. Checklist lifecycle: template feeds a configuration property, which feeds the rendered checklist form, which is inspected by a workflow function or condition, which produces a baseline snapshot for audit Once this lifecycle clicks, the rest of the documentation is mostly filling in specifics: which object types support which configuration paths, exactly which workflow functions exist, and how the property precedence resolves in edge cases. Start with [Checklist Items, Result States, and Text Syntax](/checklist/concepts/checklist-items-and-result-states) if you want to go deeper on the data model, or jump straight to [Getting Started](/checklist/getting-started/index) if you'd rather learn by setting one up. # Workflow Gates: Definition of Done and Definition of Ready Source: https://learn.nextedy.com/checklist/concepts/workflow-gates A checklist that nobody is required to complete is just a list. 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 Checklist gates come in two structurally different forms, 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 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** Any error encountered while checking the `skipForUsers` list — a malformed argument, for example — 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 hold for every function and condition on this page. The surrounding `condition`/`action` structure above (`conditionId`/`functionId` attributes, `` nesting) matches the 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) lists this target-type coverage for all seven functions and conditions on this page — `ChecklistFailIfMandatoryUnchecked`, `ChecklistFailIfAnyUnchecked`, `ChecklistUncheckAll`, `ChecklistResetToTemplate`, `ChecklistApplyTemplate`, `ChecklistAllChecked`, and `ChecklistMandatoryChecked`. Plans are not among the supported target types, 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. It is natural to ask whether the reverse holds — whether completing a checklist changes the work item's status by itself. As far as the gate mechanism goes, it does not: 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) # FAQ Source: https://learn.nextedy.com/checklist/faq/index Answers to common questions about Nextedy CHECKLIST, from general usage questions to what the product does and does not currently support.
**Verify in application** Confirm exact UI labels, menu paths, and behavior in your Polarion instance before relying on them operationally. ## What is Nextedy CHECKLIST? Nextedy CHECKLIST is an app 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](/checklist/concepts/index) 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](/checklist/getting-started/index) 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](/checklist/getting-started/setup-plan-checklist) and [Set Up a Test Run Checklist](/checklist/getting-started/setup-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](/checklist/concepts/index) 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](/checklist/getting-started/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](/checklist/reference/index) 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](/checklist/concepts/baselines) 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](/checklist/reference/index) 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](/checklist/reference/index) for configuration details and [Concepts](/checklist/concepts/checklist-items-and-result-states) 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](/checklist/faq/capabilities-and-limitations). ## How the pieces fit together Diagram showing a Template applied to a Checklist instance, which is fed by a Work Item, Document, Test Run, or Plan on one side and a Configuration property on the other, and which in turn feeds a Workflow function or condition (gate) and a Baseline **Start here if you are new** If you are setting up Checklist for the first time, start with [Your First Checklist](/checklist/getting-started/your-first-checklist), then move to the object-specific tutorials for plans and test runs. **Verify in application** Where 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](/checklist/concepts/index) 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](/checklist/reference/index) 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](/checklist/reference/index) 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 the `conditional_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](/checklist/concepts/index) 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](/checklist/concepts/baselines) 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](/checklist/reference/index) 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 the `adminPermission` 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](/checklist/reference/configuration/permission-and-freeze-properties) for both mechanisms. **Verify in application** Whether 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](/checklist/concepts/index) 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 the `PROJECTID: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 application** If 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. ## Is there anything Checklist explicitly does not do? Checklist does not expose or require configuration of its internal implementation — Java class internals, OSGi bundle structure, Velocity template engine internals, and save-hook interceptor architecture are implementation details, not user-facing capabilities, and are intentionally out of scope for this documentation. If you are looking for how to *use* or *configure* Checklist, see [Guides](/checklist/guides/index) and [Reference](/checklist/reference/index) rather than looking for these internals. ## Capability summary | Area | Supported | Notes | | ----------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Object types | Work items, documents (LiveDocs), test runs, plans | See [Concepts](/checklist/concepts/index) | | Result states | Empty, OK, NOK, Pending | Four selectable states (Pending only when the conditional state is enabled); plus a non-selectable Information row | | Gate enforcement | Workflow functions and conditions | Seven total; see [Reference](/checklist/reference/index) | | Baselines | Frozen snapshot + comparison views | Document (LiveDoc) checklists; not confirmed for other object types | | Configuration | 4-level property precedence | Global → type → field → type+field | | Structure lock | `adminPermission` (type/field/status-scoped) | Item-level check/uncheck lock uses standard Polarion field permissions instead | | Template content import | Paste text into a template work item | Not a cross-project/system checklist migration feature | | Reporting | Summary field aggregation | For dashboards/reports | **Where to look next** For exact workflow function signatures and configuration property syntax, go to [Reference](/checklist/reference/index). For task-based walkthroughs, go to [Guides](/checklist/guides/index).
If your question involves scripting against checklist data (Velocity or a custom workflow function), see the [Reference](/checklist/reference/index) section for the service API and the stored text syntax. # Getting Started Source: https://learn.nextedy.com/checklist/getting-started/index These tutorials walk you through setting up your first Nextedy CHECKLIST on the three most common Polarion object types. Set up a checklist on a work item, the most common starting point for Checklist. Add a checklist to a Polarion plan and show it on the plan report. Add a checklist to a test run and show it on the test run report. Mapping from each Checklist tutorial to its configuration steps **Pick the tutorial that matches your object type** All three tutorials follow the same pattern — create a custom field, expose it in the UI, and optionally attach a template — but the exact configuration steps differ by object type. Start with [Your First Checklist](/checklist/getting-started/your-first-checklist) if you are new to Checklist. # Set Up a Plan Checklist (Tutorial) Source: https://learn.nextedy.com/checklist/getting-started/setup-plan-checklist This tutorial walks you through setting up a Nextedy CHECKLIST to control Polarion plans. ## What you will achieve You will create a custom field to hold plan checklist data, place a script block on the plan report to render the checklist, and configure a plan template so new plans start with the same predefined checklist items. ## Prerequisites * Administrator access to **Project Administration** in Polarion * Permission to create custom fields * Permission to customize plan report pages * An existing plan (or plan template) to attach the checklist to In **Project Administration**, create a new custom field of type **Text (multi-line plain text)**. This field stores the checklist's item text and result states for the plan. You can set up multiple checklist custom fields if you need more than one checklist on a plan (for example, separate DoD and DoR checklists). **What you should see:** the new custom field listed among your plan custom fields, with type **Text (multi-line plain text)**. Next, make the checklist visible by adding it to the plan's report page. 1. Open your plan, click the gear/actions menu, and choose **Customize Plan Report**. 2. If possible, select **Customize Shared Report** so the same report layout is used across your plan and plan template — this avoids repeating the setup for every individual plan. 3. Place a **Script Block Widget** wherever you want the checklist to appear on the page, and enter: ```text theme={null} $checklistService.getChecklistView().plan($plan).checklist("planDone").render() ``` Here, `planDone` refers to the ID of the checklist custom field you created in Step 1 — replace it with your own field ID if you named it differently. 4. Save the report. **What you should see:** the checklist section now appears on the plan report page, initially empty since no items have been defined yet. Attaching the checklist to a plan template lets every new plan created from that template start with the same predefined items. 1. Open your plan template by clicking the template link in the plan's properties. 2. If the checklist isn't visible on this plan template yet, repeat Step 2 for the template. 3. Set your checklist items on the template. **What you should see:** the checklist you defined on the template now also appears — pre-populated — on any plan created from that template. **Templates propagate automatically** Once the template plan has a checklist configured, new plans created from it inherit the same checklist items automatically. You don't need to repeat the report configuration for each new plan. **Repeat the report setup per plan if not shared** If you did not use **Customize Shared Report** in Step 2, you'll need to repeat that step for every individual plan and its template separately. ## Next steps * Explore the [Getting Started](/checklist/getting-started/index) section for the equivalent tutorial on [test run checklists](/checklist/getting-started/setup-test-run-checklist) or [work item checklists](/checklist/getting-started/your-first-checklist) * Visit the [Guides](/checklist/guides/index) section to define a reusable checklist template in more detail and configure permissions * Check the [Concepts](/checklist/concepts/index) section to understand checklist items, result states, and templates * See the [Reference](/checklist/reference/index) section for configuration property details # Set Up a Test Run Checklist (Tutorial) Source: https://learn.nextedy.com/checklist/getting-started/setup-test-run-checklist Nextedy CHECKLIST can enforce a structured checklist on Polarion test runs, not just work items. ## What you will achieve By the end of this tutorial you will have: * A custom field on the test run object that stores checklist data * The checklist rendered and editable on the test run's report page * A test run template that pushes the checklist automatically to every test run created from it On the test run's report page, a Script Block Widget calls `$checklistService.getChecklistView().testRun($testRun).checklist("testDone").render()`, which renders the `testDone` checklist inline. **Work items work the same way** If you are looking to add a checklist to a work item instead, see [Your First Checklist](/checklist/getting-started/your-first-checklist). If you need a checklist on a plan, see [Set Up a Plan Checklist (Tutorial)](/checklist/getting-started/setup-plan-checklist). ## Prerequisites * Administrator access to the Polarion project (**Project Administration**) * Checklist installed and licensed on your Polarion instance * At least one existing test run or test run template to work with The checklist itself is stored as plain text in a custom field on the test run object. 1. Go to **Project Administration > Custom Fields**. 2. Create a new custom field of type **Text (multi-line plain text)**. 3. Give it a short, memorable ID — for example `testDone`. **What you should see:** the new field listed among your test run custom fields, with type `Text (multi-line plain text)`. **Multiple checklists are fine** You can create more than one checklist custom field on the test run object — for example one for `testDone` and another for a separate review gate. Each is configured and rendered independently. Next, expose the checklist field on the report page that testers actually see. 1. Open your test run, click the gear/actions menu, and choose **Customize Test Run Page**. 2. Choose **Customize Shared Report** if it's available, so the same layout applies to both the test run and its template. Otherwise you will need to repeat this step for every individual test run. 3. Drag a **Script Block Widget** onto the report page, wherever you want the checklist to appear. 4. Enter the following line into the Script Block Widget: ```text theme={null} $checklistService.getChecklistView().testRun($testRun).checklist("testDone").render() ``` Replace `testDone` with the ID of the custom field you created in Step 1. 5. Save the report. **What you should see:** the checklist form extension rendered directly on the test run's report page, with its items ready to be checked off. **Match the field ID exactly** The string passed to `.checklist(...)` must exactly match the custom field ID from Step 1. A mismatched ID is a common cause of a checklist that fails to render or appears empty. Rather than typing checklist items by hand on every test run, define them once on a test run template so every new test run starts pre-populated. 1. Open your test run template by clicking the template link in its properties. 2. If the checklist widget is not visible on the template's report page, repeat Step 2 for the template itself. 3. Enter your checklist items directly into the checklist form extension on the template. **What you should see:** the checklist items you defined now also appear automatically on test runs created from this template — you no longer need to re-enter them for each run. When a new test run is created from the template, its `testDone` field is populated with a copy of the same checklist items defined on the template (for example Smoke tests pass, Regression pass, Sign-off recorded). **Verify in application** Whether template item edits made *after* a test run is already created automatically re-sync into that existing test run's checklist should be confirmed in your environment before relying on it for audit purposes. ## Next steps * [Your First Checklist](/checklist/getting-started/your-first-checklist) — the equivalent walkthrough for work items * [Set Up a Plan Checklist (Tutorial)](/checklist/getting-started/setup-plan-checklist) — apply the same pattern to Polarion plans * [Concepts](/checklist/concepts/index) — understand result states, templates, and workflow gates before configuring gate enforcement on your test runs # Your First Checklist Source: https://learn.nextedy.com/checklist/getting-started/your-first-checklist This tutorial walks you through setting up your first Nextedy CHECKLIST on a work item — the most common starting point for the product. ## What you will achieve You will create a custom field to hold checklist data, expose it on the work item form, and attach the **checklist form extension** so the checklist renders and can be interacted with. You will also optionally set up a **summary field** that reports checklist completion. ## Prerequisites * Administrator access to **Project Administration** in Polarion * Permission to create custom fields and edit work item form layouts * A work item type to attach the checklist to (for example, a user story or requirement type) **Document checklists are different** This tutorial covers **work item** checklists. To set up a checklist on a document (LiveDoc) instead, see the [Guides](/checklist/guides/index) section. In **Project Administration**, create a new custom field of type **Text (multi-line plain text)**. This field will hold the raw checklist item text and the result state of each item. Give the field a short, memorable ID — for example `dod` (for Definition of Done) or `dor` (for Definition of Ready). You'll reference this ID in the next step. **What you should see:** the new custom field listed among your work item custom fields, with type **Text (multi-line plain text)**. Text Type CF The checklist form extension replaces the raw text field with an interactive checklist widget, but the underlying custom field must still be present in the form configuration. **Mandatory step** The custom field **must** be exposed on the work item form, either inside a `` or inside a `
`. It is **not** supported to place the checklist `` outside of a `` or `
`. The form extension hides the raw field once it's configured, but Polarion still needs it declared in the layout. Add the field to your form layout XML as you would any other custom field, inside a panel or section. In the same form layout, add the **checklist form extension** at the location where you want the checklist to appear: ```xml theme={null} ``` * `checklistId` refers to the ID of the custom field you created in Step 1 (here, `dod`) * `label` is free text — it becomes the title of the checklist section in the UI * `id` must always be `ChecklistFormExtension` **What you should see:** when you open a work item of the configured type, a checklist section appears on the form, titled with whatever you set as `label`. Since the checklist is empty at this point, it will show no checklist items yet. Field Added To Form And Extension A **summary field** reports whether a checklist is complete — useful for dashboards and reports. 1. Create a new custom field of type **String (single line plain text)**. Its ID must follow the pattern `YOUR_CHECKLIST_ID_summary` — for example, if your checklist field from Step 1 is `dod`, create `dod_summary`. 2. Make this field **read-only** using the read-only fields configuration page — not by permissions. 3. In **Project Administration > Config Properties**, tell Checklist which checklist field(s) feed the summary, using the type-specific configuration property: ```text theme={null} nextedy.checklist.userstory.checklistsIdsForSummary=dod ``` This example uses the work item type ID `userstory` and lists the `dod` checklist field ID created in Step 1. To summarize more than one checklist field on the same type, list each distinct checklist field ID separated by commas. **What you should see:** the summary field populates automatically based on the checklist's completion state once items are checked. Summary Field Open a work item of the configured type and check an item in the checklist section. Saving the work item persists the checklist state. Empty Checklist **How saves work** Checklist state is submitted to the server and written to the corresponding work item within a transaction. If a save fails, the server returns an error — check server logs if a checklist doesn't seem to persist. Start typing a new entry and then add it by clicking on the + icon on the right. Once you have a few items added, mark some of them as mandatory, and some others as completed.
Once an item is saved, you'll see the completion information also on the summary fields. Checklist With Entries ## Next steps * Explore the [Concepts](/checklist/concepts/index) section to learn about checklist items, result states, and text syntax * Visit the [Guides](/checklist/guides/index) section to define a reusable checklist template, configure gate enforcement (DoD / DoR), and cover other work item checklist scenarios * Check the [Reference](/checklist/reference/index) section for configuration property details # Track and Compare Checklist Baselines Source: https://learn.nextedy.com/checklist/guides/baselines Configure baseline tracking so a document's checklist history is captured at each revision and reviewable for audit and compliance evidence. ## What a baseline captures A **baseline** is a frozen checklist snapshot tied to a document revision. Nextedy CHECKLIST identifies baselines by querying for work items of a configurable type and reading a configurable field that stores the revision identifier. Each baseline entry displayed to users carries: * an ID (the revision/baseline value) * a label (typically the ID combined with the baseline work item's title) * the creation date of the baseline work item * the workflow status of the baseline work item * a URL linking to the document at that specific revision **Verify in application** This guide does not cover the exact steps to create a baseline work item (e.g. via a Polarion document baseline/revision action). Confirm the baseline-creation workflow in your project before relying on this guide for that step. Baseline tracking is configured per document and looks for baseline records using two configuration properties: ```properties theme={null} # Work item type that represents a "baseline" record for checklist history nextedy.checklist.baselines.itemType=btask # Custom field on the baseline item type that stores the baseline/revision identifier nextedy.checklist.baselines.baselineField=baseline ``` Both properties have defaults: | Configuration property | Default | Purpose | | ------------------------------------------- | ---------- | ------------------------------------------------------------- | | `nextedy.checklist.baselines.itemType` | `btask` | The work item type queried as a baseline record | | `nextedy.checklist.baselines.baselineField` | `baseline` | The custom field on that type holding the revision identifier | If your project already uses `btask` for something unrelated to baselines, override `nextedy.checklist.baselines.itemType` in **Administration > Configuration Properties** to point at a dedicated work item type instead. **Baseline work items must actually exist and be linked to the document** The baselines list is built entirely from work items matching the configured type and field — it does not automatically snapshot a document's checklist state on its own. If no work item of the configured type (with the baseline field populated) exists for a given revision, that revision will not appear in the baselines list, even if the document itself was revised. The baselines feature renders in one of two ways, depending on whether a specific revision is in context: Baselines widget rendering flow: no revision in context leads to querying and listing baseline items, while a revision in context leads to looking up the matching baseline and rendering the checklist as of that baseline * **General listing** — queries all work items matching the configured baseline item type and sorts them by the baseline field, producing the list of baseline entries (ID, label, date, status, URL). * **Revision-scoped rendering** — when a specific revision is active in the viewing context, the widget instead looks up the one baseline work item matching that revision and renders the checklist as it existed at that baseline. The baselines list is rendered as part of a document's (LiveDoc) checklist tooling, alongside the checklist itself. Because a document can have multiple checklists, the baselines view needs to know which checklist it should reflect. At minimum, confirm the following are set for your document: * the target **document** the baselines view is bound to * the **checklist** ID within that document, required when the document defines more than one checklist * an optional **title** to display above the baselines list **Verify in application** This documentation set does not give the exact Velocity/report-page syntax for embedding the baselines widget on a document page — only the equivalent test run checklist embedding syntax. Check your document's report/page configuration in the application, or consult **Set Up a Document (LiveDoc) Checklist**, for the precise embedding steps. The baselines view supports a flag to hide it when the document is exported or rendered as PDF. **hideInPdf may not currently suppress rendering** A flag to hide the baselines view in PDF output exists, but its effect on the exported output is unconfirmed. Verify actual PDF output in your environment before relying on it to keep baselines out of exported documents. Each entry in the baselines list shows: * the baseline **label** (falls back to just the ID if the baseline work item has no distinct title) * the **date** the baseline work item was created * the **status** of the baseline work item (its workflow status, shown as an icon/label) * a **URL** linking directly to the document at that revision Clicking a baseline's URL navigates to the document as of that revision, where the checklist form extension renders the checklist items with the result states (`Empty`, `OK`, `NOK`, `Pending`) as they were recorded at that point in time. **Use baselines with restricted checklist permissions for audit trails** Nextedy CHECKLIST does not currently track *which user* checked or commented on an individual checklist item, or *when* they did so, as a built-in, per-item audit feature. If your audit or compliance process needs that level of attribution, combine baseline tracking with the `adminPermission` configuration property (see **Control Who Can Change the Checklist**) to split a single checklist into team-specific checklists, each restricted to the users responsible for that portion — the baseline snapshot then shows what was completed at each freeze point, while permissions constrain who could have completed it. ## Comparing baselines for compliance review A typical audit or compliance comparison scenario: 1. Open the document's baselines list to see every recorded revision, its date, and its workflow status. 2. Select an earlier baseline to view the checklist exactly as it stood at that revision (result states for every checklist item, including any mandatory items). 3. Select a later baseline (or the current document state) and compare which items changed result state between the two points. 4. Cross-reference the workflow status shown on each baseline entry to confirm the checklist was in the expected state (e.g. all mandatory items checked) before the document transitioned to that status. This lets reviewers reconstruct, revision by revision, how a Definition of Done or Definition of Ready checklist evolved over the life of the document — useful evidence for ISO 26262, Automotive SPICE, or IEC 62304 process compliance reviews. ## You should now see A baselines list on the document showing each recorded revision with its ID/label, creation date, workflow status, and a working link to that revision. Opening a baseline's link should render the document's checklist with the result states exactly as they were at that revision, distinct from the checklist's current live state. ## See also * [Control Who Can Change the Checklist](/checklist/guides/permissions) * [Set Up a Document (LiveDoc) Checklist](/checklist/guides/setup/documents) * [Configure Gate Enforcement (DoD / DoR) and Freeze on Status](/checklist/guides/workflow-gates-and-freeze) * [Export Checklists and Surface Progress in Reports](/checklist/guides/reporting-and-export) # Guides Source: https://learn.nextedy.com/checklist/guides/index These guides show you how to set up and manage Nextedy CHECKLIST across work items, documents, test runs, and plans — from initial installation through templates, workflow gates, permissions, and baselines. ## Topics Install Checklist on your Polarion server and confirm licensing. Add a checklist custom field to a work item type and expose it on the form. Embed a checklist panel inside a LiveDoc using a wiki block. Attach a checklist to a test run for execution-time verification. Attach a checklist to a plan for release or milestone gating. Define a centrally managed template so changes propagate to every item. Use workflow functions and conditions to gate transitions on checklist completion. Freeze checklist snapshots and compare them across revisions for audits. ## Guide Groups ### Setup * [**Installation and Licensing**](/checklist/guides/installation) — Install Checklist and verify licensing before configuring any checklist. * [**Set Up a Work Item Checklist**](/checklist/guides/setup/work-items) — Custom field, form extension, and optional summary field for work items. * [**Set Up a Document (LiveDoc) Checklist**](/checklist/guides/setup/documents) — Custom field plus a wiki block for LiveDocs. * [**Set Up a Test Run Checklist**](/checklist/guides/setup/test-runs) — Attach a checklist to a test run. * [**Set Up a Plan Checklist**](/checklist/guides/setup/plans) — Attach a checklist to a plan. ### Templates * [**Create a Checklist Template**](/checklist/guides/templates/create-a-template) — Centrally manage checklist content with `workItemTemplateId` / `documentTemplateId`. * [**Multiple Templates per Type and Reset on Type Change**](/checklist/guides/templates/multiple-templates-per-type) — Handle several checklist templates on one work item type. * [**Shared and Cross-Project Templates**](/checklist/guides/templates/shared-and-document-templates) — Reference a template stored in another project. * [**Import Checklist Content**](/checklist/guides/templates/import-a-checklist) — Bring existing checklist content into a template. ### Workflow and Access * [**Configure Gate Enforcement (DoD / DoR) and Freeze on Status**](/checklist/guides/workflow-gates-and-freeze) — Block or gate transitions on mandatory items. * [**Control Who Can Change the Checklist**](/checklist/guides/permissions) — Restrict who can edit checklist structure versus who can check items. * [**Add Notes and Customize Item Icons**](/checklist/guides/item-notes) — Attach reviewer notes and adjust item icons. ### Baselines and Reporting * [**Track and Compare Checklist Baselines**](/checklist/guides/baselines) — Freeze and compare checklist snapshots. * [**Export Checklists and Surface Progress in Reports**](/checklist/guides/reporting-and-export) — Export checklist content and surface summary fields in reports. ### Troubleshooting * [**Checklist Is Marked Read-Only**](/checklist/guides/troubleshooting/checklist-readonly) — Diagnose why a checklist can't be edited. * [**Save Errors and Version Compatibility**](/checklist/guides/troubleshooting/save-errors-and-compatibility) — Resolve save failures and version mismatches. * [**Duplicate, Type-Change, and Formatting Issues**](/checklist/guides/troubleshooting/duplicate-and-type-change-issues) — Fix common data issues after templates or type changes. Checklist guide groups: Guides branches into Setup, Templates, and Workflow / Access, which converge into Baselines / Reporting and Troubleshooting **Where to start** New to Checklist? Start with [Installation and Licensing](/checklist/guides/installation), then follow the setup guide for the object type you need — work item, document, test run, or plan. # Installation and Licensing Source: https://learn.nextedy.com/checklist/guides/installation Install Nextedy CHECKLIST on your Polarion server and confirm it's licensed before setting up any checklists. ## Install Checklist 1. Download the latest distribution from the [Checklist download page](https://checklist.nextedy.com/download). 2. Stop the Polarion service. 3. Unzip the downloaded `checklist.zip`. 4. Copy the `com.nextedy.polarion.checklist` folder into `[POLARION_INSTALL]/polarion/extension`. 5. If you already have a production license, copy the `checklist_lic.json` file into `[POLARION_INSTALL]/polarion/license` , or add it later manually through the Polarion UI once Checklist is already installed. 6. Delete `[POLARION_INSTALL]/data/workspace/.config`. 7. Start the Polarion service. **Don't skip step 6** Deleting `[POLARION_INSTALL]/data/workspace/.config` is required for Checklist to register correctly. Skipping this step is a common cause of Checklist not appearing after installation. ## Check the license status Nextedy CHECKLIST ships with an admin/license page reachable from Polarion administration under **Administration > Nextedy CHECKLIST**. This page shows: * The Checklist version, resolved from the installed bundle * Current license status * Links to documentation (support), pricing (get a quote), the latest-version check, the download page, the changelog, and the setup guide diagram If the license is not in **OK** status, a colored banner appears wherever a checklist is rendered (work item form, LiveDoc panel, test run, or plan), with links to Help & Documentation, Contact us, and Get a quote. **Verify in application** The exact banner colors and thresholds (invalid vs. info-status) are determined by the license state reported by the admin page; confirm current wording and color coding directly on your instance. ## Set up your first checklist Installation only makes Checklist available — you still need to create a custom field and wire it into a form, LiveDoc, test run, or plan before a checklist appears anywhere: * Work items: see [Set Up a Work Item Checklist](/checklist/guides/setup/work-items) * Documents (LiveDocs): see [Set Up a Document (LiveDoc) Checklist](/checklist/guides/setup/documents) **Project template available** Nextedy CHECKLIST ships a ready-made Polarion project template (`checklist_template`) that administrators can apply when creating new projects, giving you a working example configuration to start from. ## Security considerations For security guidance that applies to all Nextedy Polarion add-ons — including the platform vs. add-on responsibility model, administrator permissions, input handling, and recommended configuration — see the common security guidance article on the Nextedy support portal. Refer to the Checklist-specific section within that document for product-specific details. **Common pitfall: incomplete setup after install** Installing Checklist and restarting Polarion is not enough on its own. Checklist must still be paired with a custom field and a form extension (work items) or a wiki block (documents) before it does anything visible. Follow the appropriate setup guide immediately after installing. ## Verification You should now see **Administration > Nextedy CHECKLIST** in your Polarion administration menu, showing the installed version and a license status that is not an error banner. If the license is not **OK**, resolve that before proceeding to checklist setup — the same banner will otherwise appear on every checklist you configure. ## See also * [Set Up a Work Item Checklist](/checklist/guides/setup/work-items) * [Set Up a Document (LiveDoc) Checklist](/checklist/guides/setup/documents) * [Create a Checklist Template](/checklist/guides/templates/create-a-template) * [Control Who Can Change the Checklist](/checklist/guides/permissions) # Add Notes and Customize Item Icons Source: https://learn.nextedy.com/checklist/guides/item-notes Attach free-text notes to individual checklist items to capture reviewer context, distinct from the static description text defined by the template author. ## Before you start This guide assumes you already have a checklist set up on a work item, document, test run, or plan. If you haven't created one yet, see [Set Up a Work Item Checklist](/checklist/guides/setup/work-items) or the relevant setup guide for your object type. ## Understanding notes vs. descriptions A checklist item can carry two different kinds of supporting text, and Checklist distinguishes them visually: | Text type | Who sets it | Rendering marker | Typical use | | --------------- | --------------------------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Description** | Template author (static, part of the template definition) | Leading `/` | Guidance/help text explaining what the checklist item is asking for | | **Note** | Reviewer, at check time | Leading `>` | Free-text remark added while working through the checklist (e.g. justification, evidence reference, exception rationale) | **Verify in application** Beyond the `/` and `>` markers used in the underlying stored text, the exact visual styling of description vs. note text in the rendered checklist form extension is not confirmed — confirm the on-screen appearance in your Polarion instance. ```text theme={null} Checklist item storage format (per line): \t