> ## Documentation Index > Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt > Use this file to discover all available pages before exploring further. # Template Configuration Properties > Reference for configuration properties that control how checklist **templates** are resolved, applied, and enforced across work items, documents (LiveDocs), test runs, and plans. export const LastReviewed = ({date}) => { if (!date) return null; const formatted = new Date(`${date}T00:00:00Z`).toLocaleDateString("en-US", { year: "numeric", month: "long", day: "numeric", timeZone: "UTC" }); return

Last reviewed on {formatted}

; }; 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 hierarchy** Template properties follow the standard Checklist property hierarchy. See [Property Hierarchy and Precedence Reference](/checklist/reference/configuration/property-hierarchy-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 | Name | Type | Default | Description | | --------------------------------------------------------- | ----------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `nextedy.checklist._TYPEID_._FIELDID_.workItemTemplateId` | `string` (work item ID) | See application (no static default — see fallback note below) | ID of the work item whose checklist content is used as the **template** for the checklist stored in `_FIELDID_` on work items of type `_TYPEID_`. `_TYPEID_` and `_FIELDID_` are both optional segments. | | `nextedy.checklist._TYPEID_._FIELDID_.allMandatory` | `boolean` | `false` | When `true`, treats every checklist item in the resolved checklist as mandatory, regardless of the per-item mandatory flag. | `_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 template** Confirmed from `ChecklistService.java`: if `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](#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` ```text theme={null} nextedy.checklist.userstory.dod.allMandatory=true # applies just for "dod" on story level nextedy.checklist.dod.allMandatory=true # applies just for "dod" checklist for any work item type nextedy.checklist.userstory.allMandatory=true # applies to any checklist for the 'userstory' work item type nextedy.checklist.allMandatory=true # applies to any checklist ``` 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 ```text theme={null} # requirement is the work item type, chkApproved is the checklist custom field ID nextedy.checklist.requirement.chkApproved.workItemTemplateId=WI-124 # work item type omitted — applies to any type using a "chkDone" checklist field nextedy.checklist.chkDone.workItemTemplateId=WI-125 ``` **Templates are live** All 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 | Name | Type | Default | Description | | --------------------------------------------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `nextedy.checklist._TYPEID_._FIELDID_.documentTemplateId` | `string` (document path) | See application (no static default — same built-in-template fallback as `workItemTemplateId`, see note below) | Path to the LiveDoc used as the checklist template for a document-scope checklist. `_TYPEID_` here refers to the document (LiveDoc) type ID; `_FIELDID_` is the checklist field/ID on the document. | ```text theme={null} # documentSpecification is the LiveDoc type, documentReadyChecklist is the checklist ID nextedy.checklist.documentSpecification.documentReadyChecklist.documentTemplateId=Specification/Product Spec Template ``` 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 template** Confirmed from `ChecklistService.java`: if `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 | Name | Type | Default | Description | | ------------------------------------------------------------------------------ | ----------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | `nextedy.checklist._TYPEID_._FIELDID_.workItemTemplateId` (cross-project form) | `string` (`PROJECTID:WORKITEMID`) | See application | Same property as above, but the value is prefixed with a project ID to reference a template work item stored in a **different** Polarion project. | | `nextedy.checklist._FIELDID_.documentTemplateId` (cross-project form) | `string` (`PROJECTID:Space/DocumentName`) | See application | Same property as the document template property above, but referencing a document template stored in a different project. | ```text theme={null} # Work item template stored in "myOtherProject" nextedy.checklist.requirement.chkApproved.workItemTemplateId=myOtherProject:WI-124 # Document template stored in "myOtherProject" nextedy.checklist.checklist.documentTemplateId=myOtherProject:Specification/SpecificationTemplate ``` **Format** The 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 templates** When 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](/checklist/reference/workflow)). 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 | Behavior | Description | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Merge on parse | When a checklist field is parsed, items from the linked template are merged with the existing stored items. | | Result carried over on merge | If an item with the same ID already exists in the stored checklist, only its **result** is carried over/preserved — other fields (label, mandatory, description) are refreshed from the template. | | Reset destroys local progress | Applying `ChecklistResetToTemplate` (or the underlying reset operation) discards existing checklist progress and reloads the template content in full. | **Reset is destructive** Resetting 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 application** The exact API surface for test run and plan template resolution (their template reference mechanism) is confirmed at the service level in code, but the corresponding admin-facing configuration property names for test runs and plans specifically were not present in the gathered context. Confirm the exact property names in the running application before publishing type-specific guidance beyond what is shown here. ## Related Configuration * [Property Hierarchy and Precedence Reference](/checklist/reference/configuration/property-hierarchy-reference) — general 4-level precedence model shared across all Checklist configuration properties. * [Permission, Freeze, and Read-Only Properties](/checklist/reference/configuration/permission-and-freeze-properties) — controlling who can edit a checklist's structure once a template is applied. * [Icon, Feature-Toggle, and Baseline Properties](/checklist/reference/configuration/appearance-and-feature-properties) — appearance and baseline-related properties. * [Workflow Functions and Conditions](/checklist/reference/workflow) — `ChecklistApplyTemplate` and `ChecklistResetToTemplate` workflow functions that act on templates during workflow transitions. **KB Articles** * Checklist configuration properties **Support Tickets** * [#3346](https://support.nextedy.com/helpdesk/tickets/3346) **Source Code** * `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistConf.java` * `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistAdminServlet.java` * `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/internal/ChecklistSetupService.java` * `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistSettings.java` * `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistProduct.java` * `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/internal/ChecklistService.java`