Skip to main content
Version requirementControl-field-based multiple templates require Checklist 2.6.0 or later. Resetting a checklist on work item type change requires Checklist 25.1.0 or later.

​
Multiple templates for the same checklist ID, keyed by work item type

By default, the system loads a checklist template depending on the work item or document type:
You can specify different template IDs per work item type while keeping the same checklist ID:
The checklist ID (testChecklist) is identical in both properties — only the work item type prefix (userstory, requirement) differs, so each type resolves its own template.

​
Multiple templates for the same type, keyed by a custom field value

You can also reconfigure which built-in or custom field controls the template selection, so that two work items of the same type can load different templates depending on a field value. Example scenario: a work item custom field requirementType is an enumeration with two options, system or software. You want the checklist requirementReady to load a different template depending on that value.

​
1. Designate the control field

Set the control field for all work item types:
Or scope it to a specific work item type only (here, requirement):

​
2. Define a template per control-field value

The value of the requirementType field (system or software) becomes the prefix used to look up the template ID.

​
3. Do the same for documents

The equivalent property for documents is:
All of this lives in Configuration PropertiesAll of these configuration properties are stored under Project Administration > Configuration Properties — there’s no separate template-mapping UI.
Control-field template resolution: a requirement work item's requirementType field value branches to either the system or software control-field mapping, each resolving to its own workItemTemplateId property.
Templates are not automatically shared across work item typesConfiguring a checklist template for one work item type (e.g. User Story) does not make that same checklist ID populate for another type (e.g. Epic). Each work item type needing the checklist must have its own explicit template reference — either a direct workItemTemplateId or a controlField-based mapping — even when the intent is to reuse the same template content across types.

​
Reset the checklist to the template on work item type change

When a work item’s type is changed to a different type that has its own checklist template, the existing checklist content (from the old type’s template) does not automatically get replaced. To handle this, monitor specific checklist IDs for type-change resets.

​
1. Add the monitoring property

In Polarion Administration > Configuration Properties, add a comma-separated list of checklist IDs to monitor on type change:
If a monitored checklist is not empty and the work item’s type changes, the checklist is reset to the template configured for the new type.

​
2. Example walkthrough

  • A Userstory work item uses the checklist testChecklist and has some entries checked.
  • The work item’s type is changed to Requirement, which has its own testChecklist template (per the type-specific workItemTemplateId properties shown above).
  • After the type-change action completes, testChecklist is reset to the Requirement template, because testChecklist was listed in checklistsIdsForTypeChanges.
  • The checklist now shows only the entries relevant to the Requirement type.
Checklist panel on a Userstory work item showing the Test Checklist with four entries and completion 1/4, before the work item's type is changed.
Work item toolbar gear menu with the Change Type to submenu open, showing Requirement and Epic as target types.
Checklist panel after the type change to Requirement, now showing three entries specific to the Requirement template with completion 0/3.
This exists to work around a Polarion issueThe type-change reset feature was introduced because of a tracked Polarion issue: the type-change action itself can convert the checklist field from multi-line plain text into rich text. Nextedy has already reported this to Siemens; you may also report it yourself to help prioritize a fix. Until it’s fixed, keep the relevant checklist IDs listed in checklistsIdsForTypeChanges if your project changes work item types across templates.

​
Verification

  • Configure two work item types with different workItemTemplateId values for the same checklist ID (or a controlField mapping) and confirm each type loads its own template content.
  • Change a work item’s type between two types whose checklist ID is listed in checklistsIdsForTypeChanges, and confirm the checklist resets to the new type’s template.
  • You should now see checklist content that always matches the work item’s current type and field values, rather than stale content from a template that no longer applies.

​
See also

KB Articles
  • How to create checklist template?
  • Multiple templates per one work item/document type
  • How to reset Checklist to the Template on WI type change
Support TicketsSource Code
  • 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/ChecklistProduct.java
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/internal/ChecklistAdminService.java
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/internal/ChecklistService.java
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/wf/ChecklistResetToTemplate.java
Last modified on August 31, 2026