Skip to main content
Reference for configuration properties that control how checklist templates are resolved, applied, and enforced across work items, documents (LiveDocs), test runs, and plans. All properties in this document are set in Administration > Configuration Properties using the nextedy.checklist.* dot-notation namespace.
Property hierarchyTemplate properties follow the standard Checklist property hierarchy. See Property Hierarchy and Precedence Reference for the full 4-level precedence model. This page documents template-specific keys and their exact resolution order where it differs from the general model.

​
Work Item Template Properties

_TYPEID_ is a work item type ID (for example userstory, requirement). _FIELDID_ is the custom field ID holding the checklist (for example dod, chkApproved). Both segments are optional and can be omitted independently, which is what produces the 4-level precedence.
workItemTemplateId falls back to Polarion’s built-in item templateIf workItemTemplateId is not configured for a given type/field, template resolution falls back to the work item type’s own built-in Polarion template reference — the same mechanism described in Built-in Polarion Work Item Templates below. The two mechanisms aren’t fully independent alternatives: the config property takes precedence when set, and the built-in template is the fallback when it isn’t.

​
Precedence example — allMandatory

The system searches for the property in the order shown above — most specific (type + field) first, least specific (global) last.
allMandatory resolution order, from most specific (type and field) to least specific (global)

​
Work item template ID example

Templates are liveAll changes made to a checklist template work item are instantly promoted to every work item, document, test run, or plan that resolves its checklist through that template.

​
Document (LiveDoc) Template Properties

Document-level checklist templates are resolved by the checklist form extension when rendering the checklist for a document. A document that is itself designated as the template automatically receives administrative permission over its own checklist structure.
documentTemplateId falls back to Polarion’s built-in document templateIf documentTemplateId is not configured for a given type/field, resolution falls back to the document type’s own built-in Polarion template reference, mirroring the workItemTemplateId fallback described above.

​
Cross-Project (Global) Templates

FormatThe cross-project reference format is PROJECTID:WORKITEMID for work item templates, or PROJECTID:Space/DocumentName for document templates. Omitting the PROJECTID: prefix resolves the template within the current project.

​
Built-in Polarion Work Item Templates

Checklist also supports Polarion’s own built-in work item template mechanism. As noted above, this is the fallback template source used when workItemTemplateId is not configured for the given type/field — not merely an unrelated alternative:
  1. Create a new work item (for example, titled “TEMPLATE”).
  2. Mark it resolved so it disappears from default views.
  3. Reference this item from the work item type enumeration as the type’s built-in template.
Known limitation — duplicated checklist items with Polarion item templatesWhen using Polarion’s built-in work item template mechanism (rather than workItemTemplateId), a bug in current versions of Polarion — not in Checklist — changes the checklist field’s format from Text to Richtext when data is copied from the template to the new item. This can result in duplicated checklist items.Workaround:
  1. Open the workflow configuration for the affected work item type.
  2. Select the init action.
  3. Add the workflow function ChecklistResetToTemplate (see Workflow Functions and Conditions).
  4. Add a checklist parameter with the value set to the name of the checklist custom field.
This resets the checklist immediately after item creation, which also corrects the field type. Nextedy has raised this issue with Siemens; the workaround will not be necessary once it is fixed upstream.

​
Template Merge Behavior

Reset is destructiveResetting a checklist to its template overwrites current checklist progress, including all local additions and previously recorded result states. This action cannot be undone from within the checklist form extension.

​
Object-Type Template Resolution Summary

Object-type template resolution summary showing how work items, documents, test runs, and plans each resolve and merge their checklist template
Verify in applicationTest runs and plans resolve their checklist template through the same template reference mechanism, but the admin-facing configuration property names that apply to test runs and plans specifically are not documented here. Confirm the exact property names in your Polarion instance before relying on type-specific behavior beyond what is shown above.