> ## 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.
# Export Checklists and Surface Progress in Reports
> Render a checklist and its progress summary on a LiveReport page, and understand what is and isn't currently possible when exporting checklist results to PDF/Word or tabular reports.
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}
;
};
## Render a checklist on a report page
Checklist form extensions live on the object's own page (work item, document, test run, plan), but you can also render a read-only view of a checklist inside a LiveReport — for example a shared test run report or a plan report — using a script block.
1. Open the report you want to customize and click **Customize Report Page**.
2. If the report is shared between an object and its template (for example a test run and its test run template), select **Customize Shared Report** so you only configure it once. Otherwise repeat this procedure for each object individually.
3. Drag a **Script Block Widget** onto the report where you want the checklist to appear.
4. Add the rendering call for the object type you're reporting on:
For a test run:
```text theme={null}
$checklistService.getChecklistView().testRun($testRun).checklist("testDone").render()
```
For a plan:
```text theme={null}
$checklistService.getChecklistView().plan($plan).checklist("planDone").render()
```
The string passed to `.checklist(...)` (`testDone`, `planDone`, etc.) is the ID of the custom field holding that checklist — substitute your own field ID.
5. Save the report.
You should now see the checklist rendered on the report page, reflecting the live result state of each checklist item.
**Reuse the same field ID across templates**
Because the script block references the checklist by custom field ID, once you've wired a shared report template to a field ID, every test run or plan created from that template automatically shows the same checklist on its report — no per-object reconfiguration needed.
## What the checklist tracks internally
Each checklist item carries a result state (`Empty`, `OK`, `NOK`, `Pending`), and the checklist as a whole exposes aggregate counts that a summary field can surface — for example the number of checked items and the number of rejected items. Items using the **Information** type (see [Using Information-type items for static context](/checklist/guides/item-notes)) are excluded from these counts, so an informational row in your checklist will not affect the progress totals shown in the summary. This is distinct from the `Empty` result state, which is a normal, countable state for an active item that simply hasn't been set yet.
## Exporting to PDF or Word
A confirmed configuration property, `nextedy.checklist._TYPEID_._FIELDID_.hideInPdf` (`boolean`, default `false`), suppresses a specific checklist custom field on a specific work item/document type when the containing document or work item is exported to PDF — see [Property Hierarchy and Precedence Reference](/checklist/reference/configuration/property-hierarchy-reference) for the full property definition. Set it to `true` for the checklist field(s) you want hidden from PDF output.
Separately, the baseline-listing view (see [Track and Compare Checklist Baselines](/checklist/guides/baselines)) has its own, distinct `hideInPdf` flag. Based on the gathered code context, that widget's render logic does not appear to branch on the flag, so the baselines list may still appear in PDF exports even when it is set. Beyond these two confirmed flags, this documentation set does not have a full list of Velocity/scripting methods for controlling checklist appearance in exported documents.
**Baselines-widget hideInPdf is unconfirmed; the checklist-field property is not**
A support ticket reports a user who could only discover a `hideInPdf()`-style flag by trial and error — that experience relates to the baseline-listing widget specifically. The general `nextedy.checklist._TYPEID_._FIELDID_.hideInPdf` configuration property for the checklist field itself is documented in the [Property Hierarchy and Precedence Reference](/checklist/reference/configuration/property-hierarchy-reference) and is not subject to that same trial-and-error caveat.
**Verify in application**
Beyond the confirmed `hideInPdf` configuration property, this documentation set does not have a full list of Velocity/scripting methods for controlling checklist appearance in exported documents. Confirm any additional export-formatting needs directly in your project.
## Surfacing checklist status outside the object
Customers evaluating Checklist frequently ask for a way to see checklist completion status — counts of `OK`/`NOK`/`Pending` items, or an all-checked/mandatory-checked flag — in a tabular or dashboard view, without opening each work item individually.
What **is** confirmed:
* A checklist's aggregate state (checked count, rejected count, and whether all items or all mandatory items are checked) is computed by the checklist itself and can be reflected in a **summary field** on the object's own form. Once configured, the summary field is a normal custom field, so it can be added as a column in a work item query/table and shown across many objects at once — see [Summary Field Reference](/checklist/reference/summary-field) for the full setup.
* That per-object rendering can also be placed on a LiveReport page via the script block shown above, for one object at a time (or one shared template report reused across a set of objects created from that template).
What is **not confirmed**:
* A native LiveReport table-field integration for **live, per-item** checked-state (as opposed to the static `_summary` field text) — for example, rendering a dynamic `1/7 completed` progress format directly as a table column without scripting. The confirmed approach for this is Velocity scripting against `$checklistService.parse()`, not a plain table column. See [IChecklistService and Velocity Rendering API](/checklist/reference/api-service).
* Whether the summary counter shown at the top of the checklist form extension itself (distinct from the `_summary` custom field) can be surfaced via reporting, columns, or export — this is not confirmed to be supported based on available evidence.
**Summary field enables cross-object reporting; live per-item scripting has no table-column shortcut**
Support history shows a request for checklist item counts and status to appear in a report or table across many objects at once, without opening each one. The **summary field** is the confirmed mechanism for this — it is a normal custom field usable as a column like any other. A separate, unresolved request asks for **live per-item** progress in a LiveReport table without scripting; no confirmed built-in mechanism exists for that narrower case.
## Common pitfalls
**Wrong field ID in the script block**
The `.checklist("testDone")` / `.checklist("planDone")` argument must exactly match the custom field ID that holds your checklist. A mismatched ID will not render the intended checklist — double-check the field ID in **Administration** before troubleshooting further.
**Report not shared, changes don't propagate**
If you configure the script block on an individual test run or plan report instead of the shared report template, new test runs/plans created later from the same template will not automatically show the checklist. Prefer **Customize Shared Report** whenever the report can be shared with its template.
## Verification
You should now see the rendered checklist appear on your report page with the current result state of each item, and — where you've built a summary field for the object — a progress summary (checked and rejected counts) reflecting the same underlying data.
## See also
* [Track and Compare Checklist Baselines](/checklist/guides/baselines)
* [Set Up a Test Run Checklist](/checklist/guides/setup/test-runs)
* [Set Up a Plan Checklist](/checklist/guides/setup/plans)
* [Import Checklist Content](/checklist/guides/templates/import-a-checklist)
* [Configure Gate Enforcement (DoD / DoR) and Freeze on Status](/checklist/guides/workflow-gates-and-freeze)
**KB Articles**
* Setup New Plan Checklist
* Setup New Test Run Checklist
* How to import a checklist?
**Support Tickets**
* [#51](https://support.nextedy.com/helpdesk/tickets/51)
* [#4624](https://support.nextedy.com/helpdesk/tickets/4624)
* [#235](https://support.nextedy.com/helpdesk/tickets/235)
**Source Code**
* `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/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/ChecklistAdminServlet.java`
* `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/baselines/BaselinesView.java`