> ## 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. # Configuration Property Hierarchy > Nextedy CHECKLIST is configured almost entirely through **configuration properties** — dot-notation keys set in **Administration > Configuration Properties**. 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}

; }; ## 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 KB content is explicit that **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 in the gathered context 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. From the gathered context: `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 the live application 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** The gathered ticket insights record a real question from a Polarion consultant: whether freeze/permission behavior (like `adminPermission`) available for work item checklists is also available, with the same syntax, for document-level checklists. The KB content confirms a document-scoped equivalent exists for `controlField` (`nextedy.checklist.document._TYPEID_._FIELDID_.controlField`), but the full hierarchy and exact key shape for document-level `adminPermission` is not confirmed in the gathered context. ## 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) **KB Articles** * Checklist configuration properties * Checklist workflow functions and conditions * How to control who can change the list and when ? **Support Tickets** * [#235](https://support.nextedy.com/helpdesk/tickets/235) * [#325](https://support.nextedy.com/helpdesk/tickets/325) * [#3346](https://support.nextedy.com/helpdesk/tickets/3346) **Source Code** * `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/Checklist.java` * `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistItem.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/ChecklistConf.java` * `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistAdminServlet.java`