Documentation

Checklist Flow for Jira

Name on the Atlassian Marketplace: Checklist Flow: Definition of Done for Jira. By Stanki Guild sp. z o.o.

Checklist Flow for Jira 3.1.1 is the production version (1 November 2026). On the Atlassian Marketplace.

Checklist Flow puts a checklist on every Jira work item and lets your workflow enforce it. You mark the items that matter as Required; a workflow validator blocks the transition until they are checked or marked not applicable. Every change is recorded in a hash-chained history that no role can clear in the app, and you can export it as CSV or JSON.

Checklist Flow is an Atlassian Forge app published by Stanki Guild sp. z o.o. It works on work items in any Jira project (the customer portal view needs Jira Service Management) and runs entirely on Atlassian's platform.

It has no Forge remote, no web trigger and no calls to external hosts, so checklists and their history stay on your Atlassian site. The production version is eligible for Atlassian's Runs on Atlassian program. One Data Processing Addendum covers this app and our other two, and the apps use no sub-processors. Free, with every feature, for sites with up to 10 users; above that $0.80 per user per month for users 1-100 (all price bands).

The hash-chained history, its exports and the go / no-go record per release help you produce evidence that changes were recorded and verified, for ISO 27001 (Annex A 8.32) or DORA (Article 9(4)(e)) audits. The app does not decide whether that satisfies a control; that is for you and your auditor. To reach Slack, Teams or another system, build a rule in your own Jira Automation on the JQL fields and the app's Automation actions: the data never passes through us.

Checklist Flow for Jira is on the Atlassian Marketplace: Checklist Flow: Definition of Done for Jira. Billing, trials and licences are handled by Atlassian. Installing works like this:

1. A Jira site administrator installs Checklist Flow from the Atlassian Marketplace.
2. During installation the administrator approves the permissions listed under Permissions and why we need them.
3. To enforce checklists, a Jira administrator adds the validator Checklist Definition of Done to the workflow transitions that should be gated (see Block a transition until the checklist is done).
4. Billing, trials and licences are handled by Atlassian. See Editions.

Checklist items

The panel opens as a work view, every time: the progress, the Definition of Done banner, then one row per item. A tap anywhere on an item's row ticks or unticks it; rows the server would refuse (linked conditions, N/A items, or a person the permissions do not allow to check) do not react. Required, N/A, status, due date and assignee show as small markers on the row. When the Definition of Done is not met, the banner names what blocks it, for example "Still open: "Tests pass", "Docs" and 2 more."

After a tap, a dark bar at the bottom of the panel shows what you did, for example Checked "Tests pass"., next to an Undo button, for about 6 seconds. It stays while the pointer rests on it or it has the keyboard focus, and a new tap replaces its text. Undo takes back that tick or untick under the same rules as a tap, and the history keeps both changes. If someone else changed the item in the meantime, Undo changes nothing and the panel reloads the latest checklist. The bar has a fixed place, so no row moves when it appears or goes. If a second person changes the checklist while the panel is open, their change appears without a reload.

To add or change items, click Edit checklist under the list; it is shown only to people allowed to edit the checklist, and Done editing closes the controls again. On an empty checklist the add field shows at once. More, next to it, holds Check all and Uncheck all, Export, History, Import, Edit as text, Ask the assistant, Templates and the Template library.

In edit mode, type an item and press Enter or click Add. Paste a list to add up to 200 items at once, one per line. On an empty checklist, Load a sample Definition of Done adds six ready-made items, three of them Required.

With a paid licence, Often added here, next to Add, lists up to 10 items that your team kept on at least two of the 30 most recently updated finished work items (status category Done) of the same project and type, with how many of them had each item. The search runs with your own Jira permissions, items already on this checklist are left out, and nothing is written until you click Add next to an item, which adds it under the permissions. It works without Rovo and uses no AI.

• Required: mark an item as required for the Definition of Done. If any item is Required, the validator checks only the Required items; otherwise it checks all of them.
• N/A: mark an item as not applicable for this work item. It counts as satisfied for the Definition of Done but not as done; the progress shows "x/y done" and the number of N/A items separately.
• Check all and Uncheck all, under More, change every item in one step. Unchecking leaves N/A items as they are.
• Edit an item to change its text, set a Due date, choose an Assignee and add a Note (Markdown, up to 2,000 characters). A due date in the past is shown as overdue.
• Item text is limited to 500 characters.
• After you remove an item, Undo puts it back in its old place, as it was, ticked or N/A included.

Sections, order and title

In edit mode, Add a section inserts a header that groups the items below it. Sections can be renamed, collapsed and removed; removing a section keeps its items. Reorder items by dragging them or with the arrow buttons. Name this checklist gives the checklist a title of up to 80 characters, for example "Definition of Done".

Priority, numbering and sub-sections

An item can carry an optional Priority (High, Medium or Low), set in the item editor and shown as a badge. It travels with templates, exports and clones. Sort by priority, under More, shows the most important items first for you only and does not change the checklist's order. In edit mode, Make sub-section turns a section header into a sub-section of the section above (Make section turns it back), and Number the items numbers the items 1., 2. and so on, starting again at 1 in each named checklist. All of this works with or without a paid licence.

Turn an item into a work item

In the item editor, Turn into work item creates a sub-task, or another work item linked to this one, from the item. The summary is the item text; its assignee, due date and note go along when the create screen of that work type has those fields. Jira creates it as you, so your own Jira permissions apply, and a required field the app cannot fill stops the creation and is named. The item then shows the new work item and its status. With Tick this item when the work item is done on, the app ticks the item when the work item reaches a Done status; the history records it as made by the app, through the work item. Works with or without a paid licence.

E-mail to assignees

When an item is newly assigned to someone, Jira sends them one e-mail that names the item, only to people who can see the work item. Saving an item without changing its assignee, assigning yourself, a migration from another app and a clone send nothing. It is on by default; a Jira administrator can switch it off on the Jira data tab of Checklist Flow settings.

Several checklists on one work item

A work item can carry several named checklists, for example "Dev DoD" and "QA DoD". In edit mode, click Add as a separate checklist next to Add section, or use Make checklist on an existing section header (Make section turns it back). Each checklist shows its own heading and its own done and total, and has its own Definition of Done: its Required items, or all its items when none is Required. Items above the first named checklist form the default checklist, so a work item without named checklists works exactly as before.

• In the Checklist Definition of Done validator, Only this checklist checks one checklist by name (not case-sensitive); when several checklists carry that name, their items are checked together. Add the validator once per checklist to require several. A work item without that checklist is not blocked, unless you tick Block when the work item has no checklist with this name.
• Making or clearing a checklist is recorded in the history.
• Named checklists work with or without a paid licence; the validator's configuration page is a paid feature.

Edit as text

Edit as text, under More next to Export and Import, opens the whole checklist as text in the same format as the Markdown export. Change it, click Preview changes to see what will be added (+), renamed (~ old -> new) and removed (-), then Save, which is enabled only after a preview. An item you keep keeps its history, its linked condition, its only-when rule and its status. A toolbar and a syntax help sit above the text, and the preview can show the old and the new text side by side. If someone changed the checklist since your preview, the save is refused and nothing is lost. Works with or without a paid licence.

Import and export

• Export, under More, gives the checklist as Markdown or CSV text to copy. The Markdown export can be imported again into another work item: # Name starts a named checklist, ## Name a section and ### Name a sub-section. The CSV export ends with status and priority columns.
• Import accepts Markdown, CSV and other checklist apps' text exports. Choose Append or Replace, then Preview shows how many items and sections will be added, and any limit that would be hit, before anything changes. Replacing a non-empty checklist asks for confirmation.
• Imported items keep their checked, Required and N/A state, notes, due dates and assignees where the format carries them. The same item limits apply as for typed items.
• To move many work items from another checklist app at once, see Switch from another checklist app.

Block a transition until the checklist is done

A Jira administrator adds the Checklist Definition of Done validator to a workflow transition. When someone attempts that transition:

• If items that count are still open, the transition is blocked with a message that names them, for example: Definition of Done not met: 1 required checklist item still open: "All linked work items done" (0 of 1 linked work items done; open: SGS-3). It names at most three items and adds "and N more" for the rest.
• Only Required items count when any item is Required. When none is Required, every item counts. An item marked N/A counts as satisfied. An item whose only-when rule does not match the work item does not count.
• A work item with no checklist, or an empty one, is never blocked.
• If the check itself cannot be completed, the transition is blocked (fail closed) and the user is asked to try again.

The validator's configuration page (paid, in Jira's workflow editor) adds four optional settings:

• Only this checklist: check one named checklist instead of the whole work item.
• Block when the work item has no checklist with this name: a work item without that checklist is blocked, with a message that tells the user to add it (for example from the template library). The box is ticked by default when you add the validator to a transition and give it a checklist name; a validator saved earlier without this setting keeps not blocking.
• Enforce only when (optional Jira expression): the Definition of Done is checked only on work items where the expression is true, for example issue.issueType.name == "Bug"; other work items pass. Test evaluates it for a work item you choose. If Jira cannot evaluate the expression, the transition is blocked. Jira evaluates the saved work item, not values typed on the transition screen.
• Also require (optional Jira expression): the transition also needs this to be true, on top of the Definition of Done, for example issue.fixVersions.length > 0. If Jira cannot evaluate it, the transition is blocked with a message.

Without an active paid licence these settings are ignored and the whole work item is checked.

Workflow post function (paid)

The Change the checklist post function runs after a transition. Choose one of: check every item, uncheck every item, clear the status of every item, or apply a checklist template. Linked conditions are left alone, and N/A items keep N/A when unchecking or clearing statuses. The change is recorded in the history as the person who moved the work item. A post function cannot block a transition: if it cannot change the checklist, the transition still goes through and the failure is listed on the Errors tab of Checklist Flow settings. Jira starts a post function only for an app that holds the manage:jira-configuration permission (see Permissions and why we need them); the app makes no call to Jira's configuration. It is offered in company-managed and team-managed projects.

Definition of Ready and Definition of Done

The free library templates Definition of Ready (user story) and Definition of Done (software) each apply as their own named checklist, "DoR" and "DoD". Put the validator on the transition to Ready with Only this checklist "DoR", and on the transition to Done with "DoD": the open DoD items do not block Ready. Tick Block when the work item has no checklist with this name on the Ready transition so that a work item without a DoR cannot pass. The Checklist progress field then shows both, for example "DoR 10/10 met; DoD 3/9 open".

DoD glance

The Definition of Done glance shows the checklist state in the work item's details area: "DoD met", "2 required open", or "DoD 3/5" when no item is Required. Open items of a global checklist that applies are added to it, for example "2 required open + 1 global". It uses the same rule as the validator: a linked condition that is met shows as done, and items not needed on this work item are left out.

Opened, the glance shows a progress bar, whether the Definition of Done is met and a line such as "2/4 done, 1 required open, 1 overdue", then the items as full-width rows. One tap on a row ticks or unticks the item and saves it at once; if the save is refused, the row goes back and the reason shows under it. Only rows the server would accept can be tapped: not linked conditions, not N/A items, and not for someone the permissions do not allow to check items. Long lists show 60 rows, then Show all. Adding and editing items happens in the panel.

On a phone

In Atlassian's Jira mobile apps for iOS and Android, Forge apps do not show yet. Atlassian staff closed the request FRGE-538 with "Forge Apps are not supported on mobile experiences today", and the request to render Forge modules on mobile, FRGE-1492, is still open. This applies to every Forge app, not only ours.

Open Jira in your phone's browser instead: Atlassian supports Safari and Chrome on phones. There the glance gives the one-tap rows described above, and the panel opens in its one-tap work view: each item is a row sized for a finger, ticked with one tap anywhere on it, and the banner names the items still open. An accidental tick can be taken back with Undo in the bar at the bottom of the panel for a few seconds. Edit checklist and More open everything else, with controls large enough to tap. The workflow validator runs inside Jira itself, so a transition made in the mobile app is still checked; how the mobile app displays its message has not been tested yet.

Languages

The work item panel is available in English, German, Spanish, French and Polish. It follows the language in your Jira profile and uses English for any other language. The glance, the settings pages, the reports and the workflow rule pages are in English.

JQL fields

The app keeps a small summary of each checklist on the work item as an issue property (com.stankiguild.checklistflow.dod), which Jira indexes for search:

For example, checklistProgress < 100 AND sprint in openSprints(), or checklistAssignee = currentUser() for work items where you still own an open checklist item. The summary is updated each time the app writes the checklist. It holds these values only: the five numbers, the number of open items without an assignee, the account IDs of the people who own open items, the earliest open due date, the head of the work item's checklist history (block number and SHA-256), the names and ids of the templates applied (the last 20) and, when the work item has named checklists, each one's name and counts (up to 20) and the names of those met and not met. It holds no item text, except the texts of the items that block the Definition of Done (up to 50, 255 characters each) when a Jira administrator has turned on Item text in JQL. checklistAssignee, checklistDue, checklistTemplate, checklistMet and checklistNotMet are left out when there is no value. After an update, an hourly background pass writes the newer fields to work items that already had a checklist; a work item also gets them on its next checklist change. The same hourly job re-reads 20 stored checklists per run, at most one run every 50 minutes, and rewrites a property that differs from the checklist, so a property edited by hand is repaired. A linked condition that changes in Jira (for example an approval) shows in these fields after the next change to the checklist; the panel, glance and validator always read it live.

The JQL fields count every checklist on the work item together. The per-checklist counts are not searchable in JQL (the names of the checklists met and not met are), but Jira expressions, scripts and the REST API can read them from the issue property.

Checklist progress field

The app adds a read-only custom field, Checklist progress, with values such as "3/5, DoD met" or "3/5, DoD open" (resolved items, checked or N/A, out of the checkable items). With named checklists it lists each one after the whole-work-item value, for example "3/4, DoD open; DoR 2/2 met; DoD 1/2 open", cut at 255 characters. A work item without a checklist has no value.

• A Jira administrator adds it to the screens (Jira settings, Issues, Screens) to show it in the work item view. It also appears as a column in List View and the issue navigator, and you can search it, for example "Checklist progress" ~ "DoD open".
• On a company-managed board, a board administrator can add it under Board settings, Card layout. Atlassian does not document how Forge fields render on board cards, so check it on your board.
• The app writes the value after every checklist change, without adding entries to the work item's Jira history (the checklist's own history records the change), unless a Jira administrator turns on the option described under Jira data and Automation. Existing work items get a value on their next change or when the field is shown.

Jira data and Automation

Two options on the Jira data tab of Checklist Flow settings, both off by default:

• Item text in JQL: the issue property also holds the text of up to 50 items that block the Definition of Done, so JQL can find them (dodOpenItem ~ "plan"). Anyone who can see the work item can read those texts through Jira. Turning it off removes them from each work item at its next checklist change.
• Jira history for Checklist progress: each change of the Checklist progress field is recorded in the work item's Jira history, so a Jira Automation rule can start from the trigger Field value changed on Checklist progress, for example to move a work item to Done when its value ends with DoD met. Needs a paid licence.

Change history and evidence

Every change is recorded with who, what and when: items added, checked, unchecked, marked N/A, made Required, edited, moved and removed, plus changes to notes, due dates, assignees, item statuses, only-when rules, named checklists and the title. In the history export, changes made by auto-apply, a checklist rule, the Create dialog, a clone, a post function, Jira Automation, the Rovo assistant, a work item turned from an item or a migration from another app are marked in the via column.

• Open an item for editing and click History to see every change to that item.
• The history is append-only. There is no action in the app, for any role, that clears or edits it. The one exception is personal data: when a person is erased or Atlassian reports an account as closed, their account ID is replaced in the history, and that redaction is itself recorded so the chain still verifies.
• Each history block carries a SHA-256 hash of its content and the hash of the block before it. A changed or missing block shows up when the chain is checked.
• History: CSV / JSON / PDF exports the work item's full history. The PDF holds the checklist and its history with the chain head. The export states whether the chain verified and prints its chain head (block number and hash). The JSON export contains the raw blocks and the hashing recipe, so the chain can be recomputed without our code. In the CSV, the hours_to_check column gives, on a checked row, the hours since the item was created.
• To check a later state against an earlier export, paste the chain head from that export and click Check. The app tells you whether that block is still in the history exactly as it was recorded. Keep chain heads in your own archive: they are what makes a rewrite of the whole history by someone with direct storage access visible.

Moving a work item to another project

When a work item moves to another project and gets a new key, its checklists, their history and its Definition of Done move with it: the app keeps them under the work item's id, which Jira does not change on a move, so the validator on the new key checks the same items as before. History exports name the current key and the work item's id.

• Checklists saved by an earlier version of the app under a work item's key are moved to its id on the first use of the work item or by an hourly background pass. The history records the move, and the chain still verifies.
• If the old and the new key both hold a checklist, for example because a team started again on the new key, the items missing from the new one are added to it, so a Required item never disappears through a move; the history records this.
• Until the background pass has finished after the update, a work item that has no checklist under its id yet is looked up by its earlier keys. If Jira does not answer that lookup, the transition is blocked (fail closed) and the panel says "Jira did not answer while this checklist was being looked up. Reload the work item; nothing was changed."

Cloned work items

When a work item is cloned in Jira, the clone gets the original's checklist: sections, named checklists, item text, Required, priority, notes, linked conditions and only-when rules. Ticks, N/A, statuses, due dates and assignees are not copied, and neither is the history. A clone that already has items, for example from auto-apply, only gets the items whose text it lacks. The copy is made when Jira links the clone to its original, within 15 minutes of the clone's creation, and the clone's history records it. Works with or without a paid licence.

Templates

Save the current items of a work item as a named template with Save template, then Apply it to other work items: its items are added below the current ones. A saved template keeps each item's text, Required mark, priority, note, linked condition and only-when rule, but not sections. As a separate checklist, next to Apply, adds a template as a new named checklist. Delete removes a template for everyone on the site; checklists already built from it are not affected. Who may save, install and delete site templates is the Manage templates and defaults permission (see Roles and permissions); by default everyone who can edit a checklist.

A site can hold up to 10 templates without a paid licence and up to 500 with one. Template names can be up to 100 characters.

Template library

Template library, under More in the panel, offers 49 ready-made templates in 18 categories, from software delivery, code review and release to security review, GDPR and privacy, change management, employee onboarding, IT access, procurement and sprint ceremonies. Each one shows its description and item counts, and Preview lists its items. Browse the template library.

• Install adds the template to your site's templates, with its sections and Required marks, so it can be applied, auto-applied or used by Automation. It counts toward the template limit, and a name already in use on the site is refused.
• Five templates are free in every edition: Definition of Done (software), Definition of Ready (user story), Bug fix verification, Code review (author and reviewer) and Release readiness. The Definition of Ready and Definition of Done templates apply as named checklists "DoR" and "DoD" (see Definition of Ready and Definition of Done).
• The other 44 carry a Pro badge and a Start free trial button until the site has a paid licence.
• Five templates include a linked condition: four wait for Approval Flow approval and one waits for all linked work items to be done.

Roles and permissions

On the Permissions tab of Checklist Flow settings, roles decide who may do what. A role bundles permissions, and a role is given to everyone, to project administrators, or, with a paid licence, to groups, project roles or named people. The permissions are: Check items, Configure requirements, Relax a control, Manage templates and defaults, Manage rules and automation, Manage app settings, View compliance reports, See people in reports, Export evidence, View change and permissions logs, Erase a person, Import from another app and Manage permissions. The built-in roles are App administrator, Compliance manager, Auditor (read-only), Control owner, Configurer, Checker, Template steward and Member. Jira administrators always hold App administrator, so nobody can lock the site out.

• Defaults: everyone who can open a work item can edit and tick its checklist (the Configurer and Checker roles); Jira administrators hold the rest. Template steward is everyone for site templates and project administrators for a project's templates. Control owner is project administrators.
• Relax a control: un-requiring or deleting a Required item, removing its linked condition, setting or changing an only-when rule on it, and turning "in order" off need this permission, on every way in (panel, Edit as text, import, release checklists, and, for the rule actor, the Automation actions Set checklist item Required and Remove checklist item on a Required item). Without it the panel shows the control read-only and says who may change it.
• Check items is also needed to import or restore a ticked item and to set an item status. Marking a Required item N/A needs Check items or Relax a control.
• Tabs: Roles and holders; What each role can do; Check a person, which shows what one person can do and why; Log; Export and import, with a preview before anything is applied.
• Paid: groups, project roles, named people (up to 50 per role), roles of your own (up to 10), limiting a holder to chosen projects, a second administrator who approves permission changes, and import. Without a paid licence the model is fixed and read-only, and everyone who can open the work item can edit and tick.
• Log: every change to roles and holders and every safeguard turned off is hash-chained to the one before, and filtered by role and person. Past 10,000 entries the log is sealed into an archive, not trimmed. People who hold View change and permissions logs read it, and the settings log, under Apps, Checklist Flow logs even if they are not Jira administrators.

The server checks the permission on every change, not only in the panel; someone who is not allowed sees the checklist read-only with a short explanation. If Jira cannot confirm someone's groups or project roles, the change is refused. A person's groups and project roles are cached for 60 seconds per site. Jira Automation rules, checklist rules, template auto-apply and the post function are not limited by Check items and Configure requirements, because they run as the rule an administrator built; the Rovo assistant and Add items from text are, for the person using them. If a licence lapses, the saved model is kept and comes back with the licence; meanwhile everyone who can open the work item can edit and tick again.

Project statuses and templates (paid)

A project's settings page has a Checklist Flow settings page with two tabs, for people who hold the Manage templates and defaults permission in that project (project administrators by default).

• Statuses: choose which of the site's item statuses this project uses and in which order, or Checkbox only, which offers no custom statuses there. Items that already have a status keep it.
• Templates: templates for this project only (up to 100), saved from a work item with This project only or copied from a site template. A checklist in the project lists these first, then the site templates, and a project template hides a site template of the same name. Here you also choose the template a new work item of each work type gets in the project, which wins over the site's auto-apply mapping.

Templates on the Create dialog (paid)

A Jira administrator adds the custom field Checklist templates to a Create screen. The person creating a work item picks up to 5 templates (the project's first, then the site's), for example a Definition of Ready, and they are added when the work item is created, after auto-apply. It never blocks creation and never overwrites a checklist that already exists.

Items in order (paid)

In the panel, Items must be checked in order makes an item settleable (checked, N/A, or a status that counts as done) only when every item above it in the same named checklist is settled. Sections do not reset the order; a named checklist does. Unchecking is never refused. Turning the setting off needs the Relax a control permission.

Lock when done (paid)

On the Settings tab of Checklist Flow settings, Lock when done is off by default. When it is on, the panel shows the checklist read-only on a work item whose status is in the Done category and says why, and the customer portal and the Rovo assistant refuse changes too. Reopening the work item unlocks it. Jira Automation actions and checklist rules are not limited, so a rule that checks every item on the way to Done keeps working. It needs the Manage app settings permission and a paid licence.

Template auto-apply by issue type (paid)

On the Templates tab of Checklist Flow settings, map a work type to a saved template. When a work item of that type is created, the template is added to it automatically. This runs after the work item is created and never blocks creation, and it never overwrites a checklist that already exists. Changing the mapping needs the Manage rules and automation permission (Jira administrators by default).

Checklist rules (paid)

On the Rules tab of Checklist Flow settings, checklist rules change a checklist based on what the work item says. Creating or changing rules needs the Manage rules and automation permission (Jira administrators by default).

• Conditions, one per line, are field, operator and value, for example priority = Highest or labels contains security. Operators: = != > >= < <= in contains. Choose whether all conditions or any condition must match. A rule can also carry a Jira expression, for example issue.issueType.name == "Bug", as one more condition; Test expression evaluates it for a work item you choose, and a broken expression is refused with Jira's own message when you save.
• When a rule matches, it can add items (## starts a section, ! makes an item Required), apply a saved template, and make existing items Required by their text.
• Up to 50 rules, each with up to 10 field conditions, and at most 20 rules that carry a Jira expression. Each rule adds its items once per work item.
• Rules run when a work item is created (after template auto-apply), from Apply checklist rules in the panel and from the Jira Automation action Apply checklist rules, so your Automation decides when else they run, for example when the priority changes. The fields are read by the app, so the outcome never depends on who triggered the rule.
• Every change a rule makes is recorded in the checklist history with the rule's name.

Rules add items when fields match; an only-when rule on an item hides that item when a field does not match. The two work together.

Item statuses (paid)

On the Item statuses tab of Checklist Flow settings, you define up to 10 statuses, for example "In progress", "Blocked" or "Skipped", each up to 30 characters and marked Counts as done or Open. In the panel each item then has a small status select and shows its status as a lozenge; the header counts items by status, and a menu under More, and one on each section, sets every item in the list or the section to a status in one change. A project can use only some of the statuses, or none (see Project statuses and templates).

• A status that counts as done satisfies the Definition of Done like a checked item: the validator, the glance, the JQL fields, DoD Health and the gadget treat it as resolved. An open status still blocks.
• Checking an item, marking it N/A or Check all clears its status. Linked conditions never take a status.
• Setting a status needs the right to check items under the permissions. The change is recorded in the history, and the CSV export carries it in its last column, status.
• An item keeps the status it was given even if the definition is later edited or deleted, so a work item's Definition of Done never changes behind its back. If a licence lapses, items keep their statuses and they keep counting; new statuses cannot be set.

Work item blueprints (paid)

A blueprint attaches a description template and, optionally, an Approval Flow policy name to a saved checklist template, so one Automation rule can set up a new work item completely.

1. On the Blueprints tab of Checklist Flow settings, choose a template, type the description (up to 10,000 characters, plain text or Jira wiki markup) and, if you use Approval Flow, a policy name. Limit it to work types and project keys if you like. Saving a blueprint needs the Manage rules and automation permission.
2. In Jira Automation, build a rule: trigger Work item created, action Get blueprint with the work item key, a condition that its found output is true, then Jira's own Edit work item action that sets the description from its description output, and, with Approval Flow, its Apply approval policy action with the approvalPolicy output. The admin page shows the recipe.
3. The checklist itself comes from auto-apply or a checklist rule.

Get blueprint picks the most specific match (project and type, then type, then project, then neither). It only reads: Checklist Flow never edits your work items, so it needs no permission to change them; Jira Automation makes the edit as the rule actor. Deleting a template deletes its blueprint.

Global checklists (paid)

A Jira administrator creates global checklists in the Global checklists section of the admin page: a name, items one per line (start a line with ! to make it Required), and optionally the issue types and project keys it applies to (empty means all).

• A global checklist appears live on every matching work item, labelled Global, "managed by your Jira admin". Edits to the definition show up everywhere at once; each work item keeps its own progress, and items can be checked or marked N/A there.
• Up to 50 global checklists, with up to 200 items each.
• The Global checklist done validator blocks a transition until every global checklist that applies to the work item has its Required items (or all items, when none is Required) checked or N/A. Its configuration page lets you pick one global checklist instead; that page is available in Jira's new workflow editor.
• A global checklist that does not apply to a work item never blocks it. If the check cannot be completed, the transition is blocked (fail closed).

Linked conditions (paid)

A linked condition is a checklist item that resolves itself from data on the work item. In edit mode, click Add a linked condition and choose one:

• Approval Flow: approvals complete: met when Approval Flow's approval of the work item is verified. Anyone who may edit a work item can change the status Approval Flow publishes on it, so Approval Flow signs that status, and Checklist Flow counts it only when the signature is valid for this work item and Approval Flow's own read-only Approval status field agrees. Both apps must be installed on the site for this. An approval that is reported but not verified does not count: the item stays open and says "not verified". An approval also stops counting once a sign-off it rests on is past its validity (Approval Flow's Sign-offs valid for N days). Work items approved earlier are signed by an hourly Approval Flow job after the update, so on a large site some can show "not verified" for a day or more; their next approval change signs them at once.
• All linked work items done: met when every linked work item is in a Done status, optionally only links of one type such as "blocks". By default it also waits until the work item has at least one such link; untick Require at least one linked work item to let a work item with no such links count as met.
• A field equals a value: met when a field, given by its field id (for example status, priority, labels or customfield_10010), has that value.
• A field has a value: met when the field is not empty.

A linked condition shows Met or Waiting with a short explanation instead of a checkbox. It can never be ticked by hand or marked N/A, and Check all and Automation skip it. When it is Required and its data cannot be read, it stays open and keeps blocking (fail closed). At most 20 linked conditions per checklist.

Only-when items (paid)

An only-when rule makes an item apply only to work items where a field matches, so one template can serve every work item. For example, "DB migration reviewed" only when labels is database, or "Rollback tested" only when priority is High or Highest.

1. In the panel, click Edit checklist, then the pencil on an item.
2. Under Only when, type the field id (for example priority, labels, components, issuetype or customfield_10010).
3. Choose is one of and type one or more values separated by commas (not case-sensitive), or choose has any value.
4. Click Set rule. Remove rule takes it off again.

When the rule does not match, the item is not needed on that work item: the validator, the glance, the JQL fields, DoD Health and the customer portal leave it out, and the panel hides it behind Show N items not needed on this work item, where it appears greyed with Not needed and the rule, for example "Only when priority is High or Highest: priority is Low."

• An item is hidden only when Jira positively says the field does not match. If the field cannot be read, or the checklist has more than 50 rules, the item stays and counts as usual.
• Rule changes are recorded in the item's history, kept by saved templates, and restored by Undo.

Jira Automation actions (paid)

Checklist Flow adds 15 actions to Jira Automation, so your own rules decide when a checklist changes. In the rule builder they are listed with other apps' actions (under Other apps in our testing). The first time, the rule builder asks you to connect the app and approve its access.

• Apply checklist template: adds the items of a saved template, found by name (not case-sensitive). The name must match exactly one template. With the optional Checklist name, the template is added as a separate named checklist.
• Add checklist item: adds one item, optionally Required.
• Check checklist item and Uncheck checklist item: check or uncheck every item whose text matches exactly (not case-sensitive). Linked conditions are refused.
• Remove checklist item: deletes every matching item; the deletion stays in the history.
• Set checklist item Required, Set checklist item not applicable: turn Required or N/A on or off for the matching items.
• Set checklist item due date: a date as YYYY-MM-DD or a smart value date; empty clears it.
• Set checklist item assignee: an Atlassian account ID, for example the smart value issue.assignee.accountId; empty clears it.
• Check all checklist items: one change for the whole checklist, or unchecks all with Uncheck instead. Linked conditions are left alone.
• Set checklist item status: sets an item status by name; empty clears it.
• Apply checklist rules: runs the checklist rules on the work item now.
• Get checklist status: returns openRequired, total, done, progress, dodMet, na, overdue, openItems (the open item texts, one per line), assignees (account IDs), nextDue and, with an optional Checklist name, the counts of one named checklist (every checklist with that name, counted together), for later steps of the rule, as smart values such as fetchedChecklistChecklist.dodMet.
• Get blueprint: returns the blueprint for the work item's type and project. It writes nothing.
• Add items from text: adds items from text, one per line (## starts a section, ! makes an item Required; bullets, numbers and task boxes are stripped), at most 30 at a time. Items already on the checklist are skipped, so a rule that runs twice adds nothing twice. Unlike the other actions, it needs the Configure requirements permission for the rule actor.

The Work item key field defaults to the smart value issue.key, the work item that triggered the rule. The work item is looked up as the rule actor, who must be able to open it. Changes are recorded in the history as made through Automation, by the rule actor. An action that would change nothing writes nothing. When an action cannot run (no licence, unknown template, no matching item), the rule stops and the reason appears in the rule's Audit Log. Automation actions, except Add items from text, are not limited by the Check items and Configure requirements permissions, because the rule is what an administrator built. Making a Required item weaker is the exception: Set checklist item Required (to off) and Remove checklist item on a Required item need the Relax a control permission for the rule actor, and the rule fails with a sentence in its Audit Log without it. With Lock when done on, the actions still run. After an app update, Atlassian notes that changes to actions can take up to 20 minutes to appear.

To read checklists from ScriptRunner, see the guide Checklist Flow with ScriptRunner for Jira Cloud.

Rovo assistant (paid)

On sites where Rovo is enabled, the Checklist Flow assistant agent can:

• Suggest checklist for this work item: reads the work item's summary, description, type and current checklist, plus matching templates from the library and the same team history as Often added here, so Rovo can propose items. It writes nothing.
• Add suggested checklist items: adds the items you agreed to, with sections and Required marks. Items already on the checklist are skipped. At most 60 lines at a time.
• Explain what blocks Definition of Done: lists the open items, which of them are Required, what each open linked condition is waiting for, and any open global checklist.
• Review evidence for Required items: reads the items the Definition of Done counts (the Required ones, or every item when none is Required) with their state and notes, the latest 20 comments, linked work items with their status, web links and attachment names, so Rovo can say, as an advisory note, which done items have a supporting comment or link and what evidence would close the open ones. It writes nothing, and the assistant is instructed never to call an item verified or to tick, untick or change an item because of it.
• Apply checklist template by name: applies a saved template, or a library template your edition includes.

The two actions that change a checklist return a preview and write nothing unless the request is marked as confirmed; the assistant is instructed to mark it only after you agree. A change the assistant makes shows in the item's History as made by the person who confirmed it, "via Rovo". The work item is always checked against your own Jira permissions. Rovo is optional: checklists, templates, rules, the validators, Automation actions, history and exports all work the same without it. The language work is done by Rovo itself, on your Rovo plan: Checklist Flow calls no AI service of its own and sends nothing outside Atlassian.

• Ask the assistant, under More in the panel, opens the assistant in Rovo with a prompt for this work item: "Suggest a checklist" on an empty checklist, otherwise "What blocks the Definition of Done". It appears only on licensed sites where Rovo is enabled. If Rovo cannot be opened for you, the button goes away and one line says that the assistant needs Rovo and that the checklist works without it.
• A checklist proposed by AI on every new work item: a Jira Automation rule with the trigger Work item created, Atlassian's Use Rovo agent action with a prompt, then Checklist Flow's Add items from text with the agent's answer. The admin page shows this recipe. Rovo writes the proposal; Checklist Flow adds it under your permissions and records it in the history.

Use with Rovo agents (paid)

This is for teams who want a Rovo agent to work through a Definition of Done: read the checklist, do the items it can, and report them with evidence. A person stays in charge of what counts.

The tools, by the names Rovo Studio lists:

• Definition of Done status: every item with its state, owner, whether an agent may tick it and whether a person must confirm it, which items block the transition, and whether the work item may move now.
• What is left on the Definition of Done: the open items in the order to do them, blocking ones first, each marked as something an agent can do or a person must.
• Complete a checklist item: the agent says an item is done and must give evidence, a short text or a link.
• Propose a checklist item: the agent suggests a missing check. It is marked as proposed by an AI agent and blocks nothing until a person accepts it.

Set it up in Rovo Studio:

1. Open Rovo Studio, then Agents, then Create an agent, then Start from blank.
2. Under Instructions, tell the agent how to work. For example: check the Definition of Done before you start, complete only the items you really did and give evidence, and never say an item is done while it waits for a person.
3. Choose Add tools, search for "Definition of Done", pick the tools you want and choose Add.
4. Choose Test and try it on a work item or page you can open. Publish the agent when it behaves.

The tools are a paid feature of Checklist Flow. Rovo agents need Rovo on your site and a Rovo plan that allows custom agents; the agent runs on your Rovo plan, and Checklist Flow calls no AI service of its own.

Rules that hold whatever the agent does:

• The agent acts as the signed-in user, with that person's Check items permission. The Done lock and "items must be checked in order" still apply.
• An agent's tick on a Required item, or on one marked Human must confirm, is "waiting for human confirmation". It does not count as checked, so the validator, JQL, DoD Health and the gadgets keep the item open until a person confirms it in the panel with one tap. Reject drops the agent's tick.
• Items marked Human only cannot be ticked by an agent at all.
• The history shows every agent change as "via an AI agent", with the person it acted for and the agent's evidence.
• No tool confirms, accepts or approves. That happens in the panel.

Limits, stated plainly:

• The evidence is text. Checklist Flow decides who may count a tick, it does not check that the evidence is true.
• The person who connected the agent can also confirm its tick. If a different person must confirm, use the Check items permission or Approval Flow.
• A Rovo agent that Jira Automation starts cannot run write actions. That is an Atlassian rule, so Complete a checklist item and Propose a checklist item work in chat, not from an automation rule.
• Using the same tools from outside clients such as Claude or Cursor goes through mcp.atlassian.com, an Atlassian Early Access feature that is not generally available yet. Coming when Atlassian opens it.

DoD Health (paid)

The DoD Health project page lists the work items that have a checklist, which of them are blocked by open items and which have met their Definition of Done, with a By epic breakdown.

• Choose the scope: Whole project, Open sprints, One sprint (by id), One epic (by key) or One release (fix version).
• The search runs with your own Jira permissions, so the report contains only work items you can open.
• At most 200 work items are scanned per view; the page states when there are more.
• Linked conditions and only-when rules are resolved with your own Jira permissions, within a time limit of about 12 seconds. Work items not reached in time count as open, so the report can over-report open items but never under-reports them, and the page says how many were not resolved.
• An Overdue items column counts open items past their due date.

Release readiness

To answer "is this release done?":

1. On the DoD Health page, choose the scope One release (fix version).
2. Type the fix version name (or its numeric id) and show the report.
3. Read the headline: "Release 2.4.0: ready" when every work item has met its Definition of Done, or "N of M can't be Done" otherwise, plus how many work items in the release have no checklist.
4. Click Export evidence for this report: the evidence export runs at once on the same work items. In JSON format it adds a readiness block with the scope, the counts and one row per work item.

Release readiness: go / no-go per fix version (paid)

The Release readiness tab of the DoD Health project page answers "can we ship this version?" in one place.

1. Open the project's DoD Health page and choose the tab Release readiness.
2. Pick a fix version (unreleased versions first; archived ones are hidden).
3. Read the verdict, one of three:

• No-go: not ready (red) when something blocks: a work item with open Required checklist items, an Approval Flow approval pending or rejected, an open release checklist, or a version without work items. The reasons say what, for example "1 work item has open Required checklist items" or "ABC-1: approval rejected: QA sign-off", and the Required items still open are listed.
• Not known (grey) when nothing blocks but something cannot be confirmed: work items without a checklist, work items without Approval Flow data, approvals that are reported but not verified, or no release checklist. The Not known box lists them. A work item without Approval Flow data is shown as "no data", never counted as approved.
• Go: ready (green) only when nothing blocks and nothing is unknown.

1. Under each approval, the tab shows the requirements Approval Flow reports as still blocking.

An approval counts toward Go: ready only when it is verified, shown as "Approved (verified)" (or "Not required (verified)"): signed by Approval Flow for this work item and confirmed by Approval Flow's read-only Approval status field, as for the linked condition. Both apps must be installed, and a sign-off past its validity in Approval Flow ends the verification. An approval that is only reported shows as "Approved (reported)" and is listed under Not known, because anyone who may edit a work item can change the status Approval Flow publishes on it. A pending or rejected approval blocks either way.

• Release checklist: a checklist for the version itself, for example from the library template "Release readiness". It is stored and hash-chained like a work item's checklist. Who may change it follows the permissions in the project; its Required items are read-only for people without Relax a control, and the panel says why.
• Go / no-go record: download a PDF with the verdict ("GO (ready)", "NO-GO (not ready)" or "NOT KNOWN"), the reasons, what is not known, the work items with the head of each one's Approval Flow log (to check against Approval Flow's own export), the blocking items, the release checklist with its full history and block hashes, the chain check and a report SHA-256. When you may edit the release checklist, the export is first recorded in its history, so the PDF names the block that records it; for a viewer the PDF says it was not recorded.
• The search and the version lookup run with your own Jira permissions; at most 200 work items per version. A version with more than 200 work items is never Go: ready: the tab says which were not judged. The app also counts the version's work items itself and compares the count with what you can see. If you see fewer, or the count fails, the verdict is Not known with a line that some work items are hidden, and no go / no-go entry is written to the release history under your name; the PDF says so. Approval Flow's state is read from the issue property it publishes on each work item, and checked against its Approval status field.

Evidence export per JQL filter (paid)

On the DoD Health page, Evidence export collects every checklist change in the work items a JQL query returns: who, what and when, with each work item's history chain verified. Filter by date range and by kind of change (checked, unchecked, N/A, Required, added, removed, text or note edits), choose CSV or JSON, then click Build export. The query runs with your own Jira permissions, and a work item whose chain fails the check is flagged.

Item states export, on the same page, gives the current state of every checklist item in the work items a JQL query returns as CSV, one row per work item and item: text, state (checked, N/A, open, a status, or for a linked condition met or waiting), Required, whether the item is needed on that work item, assignee and due date. The query runs with your own Jira permissions.

Dashboard gadget (paid)

Add Definition of Done health to a Jira dashboard and, in its settings, choose one project key or a JQL query (or saved filter), with an optional auto refresh every 15, 30 or 60 minutes. It shows how many work items meet their Definition of Done and how many are open, the five items that block the most work items, the ten work items with the most open items, and overdue items. The search runs with the viewer's own Jira permissions over at most 200 work items, so each person sees only the work items they may browse. An empty or broken query shows a message, never an empty report. The gadget only reads.

My checklist items gadget

Add My checklist items to a Jira dashboard to see the open checklist items assigned to you across work items, and tick them in place. It looks at the 50 work items you can open where you own an open item (the most recently updated first) and lists at most 200 items. Items you may not tick are shown read-only with the reason: you lack the Check items permission, or the work item is locked by Lock when done. Works with or without a paid licence.

Switch from another checklist app

Jira administrators can move checklists from Smart Checklist, HeroCoders Checklists, Checklist for Jira Enterprise (HeroCoders, formerly Okapya) and Multiple Checklists (SolDevelo) in one go, on the Switch from another app tab of Checklist Flow settings: choose the app and a JQL, run a dry run that writes nothing, then Import. The other app is only read, never changed. Imported items are ordinary Checklist Flow items, and each work item's history records that they were imported, from which app, by whom and when. Running the same migration again adds nothing twice, and every run can be undone: Undo this import removes only the items that run added. Works with or without a paid licence.

• Smart Checklist: read from its "Smart Checklist" field (older installs: the "Checklists" field; run Smart Checklist's Synchronize first there). A single checklist tab lands in the default checklist; several tabs become named checklists. Run live once, on 17 Oct 2026 with Checklist Flow 2.7.0; the importer changed afterwards (priority and custom statuses, preselected field) and those changes have not been run live. Not tested with Smart Checklist Free.
• HeroCoders Checklists: read from its "Checklist Text" field, which HeroCoders fills only when its Sync checklists to Custom Fields setting is on. Turn it on first and wait until its sync progress in Global Settings reaches 100%: a work item whose checklist has not been synced yet shows an empty field and nothing to import. Either "Checklist Text" field works ("Checklist Text" or "Checklist Text (view-only)"). Several HeroCoders checklists become named checklists. Run live once, on 17 Oct 2026, on one work item; not run on production 3.1.0.
• Checklist for Jira Enterprise (HeroCoders, formerly Okapya): choose it as the source and pick the "Checklist Text" field, which it fills when its Sync checklists to Custom Fields setting is on; a field moved over from Data Center is marked in the list. Checklists, headers, Required, checked and skipped items are read. Run a dry run first and compare a few work items.
• Multiple Checklists (SolDevelo): read from its issue properties, no field to choose; several checklists become named checklists.
• A work item that already has a Checklist Flow checklist is skipped, unless you tick Add below an existing Checklist Flow checklist; a work item whose source changed after an earlier import is listed for you instead of being imported twice.
• Checklist Flow cannot read Didit Checklists' content: copy each checklist and paste it per work item with Import.

What moves and what does not, per app: Switching to Checklist Flow.

Customer portal view

On a Jira Service Management request, an agent can click Show on customer portal in the panel. The customer then sees the checklist read-only on the portal: its title, sections, items and whether each is done, N/A or Required. A met linked condition shows as done, and items not needed on the work item are not shown. Notes, assignees, due dates and history are never shown there. It is off by default and set per request; Hide from customer portal turns it off again. The read-only view works with or without a paid licence.

With a paid licence, an agent can also switch on Customer can tick on the portal for single items in the item editor. The customer can then check and uncheck exactly those items on the portal, and nothing else; each tick is recorded in the history. A tick is refused for a linked condition, an N/A item, an item out of order when items must be checked in order, and on a work item locked by Lock when done.

How do I block a Jira transition until the checklist is done?

Mark the items that must be finished as Required in the Checklist Flow panel. Then, in the Jira workflow editor, add the Checklist Definition of Done validator to the transition you want to gate, for example the move to Done. The transition is blocked while a Required item is open, and it is also blocked if the check itself cannot be completed. The validator is available without a paid licence.

Which checklist items does the Definition of Done validator check?

If at least one item on the work item is marked Required, the validator checks only the Required items. If no item is Required, every item must be checked. An item marked N/A counts as satisfied, and a work item with no checklist is never blocked. A Required linked condition counts only when its Jira data says it is met. An item whose only-when rule does not match the work item is not checked.

How do I find work items with an unfinished checklist in JQL?

Checklist Flow adds 13 JQL fields: dodMet, dodOpen, checklistTotal, checklistDone, checklistProgress, checklistAssignee, checklistDue, checklistUnassigned, checklistTemplate, checklistTemplateId, checklistMet, checklistNotMet and dodOpenItem (the last only when a Jira administrator turns on item text in JQL). For example, checklistProgress < 100 finds work items whose checklist is not fully resolved, and dodMet = "true" (with quotes, because the value is stored as text) finds those whose Definition of Done is met. The fields are updated each time the checklist changes and are available without a paid licence.

Can anyone delete or edit the checklist history?

No role can clear or edit the history from inside the app, Jira administrators included. The one exception is personal data erasure, which replaces a person's account ID and records that it did so. Each history block is chained to the one before it with a SHA-256 hash, so a changed or missing block is reported when the chain is checked. Exports print a chain head that you can keep and later paste back to confirm that the recorded history is unchanged. The history is deleted when the app is uninstalled, and an account ID is removed from it when Atlassian reports that account as closed.

How many checklist items and templates can I use without a paid licence?

A work item can hold up to 2,000 entries (items and sections), with or without a paid licence. Without a paid licence a site can hold up to 10 saved templates; with one, up to 500. Five templates from the template library are free; the other 44 need a paid licence.

Can Jira Automation add or tick checklist items?

Yes, with a paid licence. Checklist Flow adds 15 Automation actions, among them Add, Check, Uncheck and Remove checklist item, Add items from text, Set Required, Set N/A, Set due date, Set assignee, Set status, Check all, Apply checklist template, Apply checklist rules and Get checklist status. Check and Uncheck change every item whose text matches exactly, ignoring case; linked conditions cannot be changed this way. The rule actor must be able to open the work item, and a failed action stops the rule with its reason in the Audit Log.

Who can edit or tick a checklist?

By default, anyone who can open the work item. With a paid licence, a Jira administrator can give the Configure requirements permission (edit) and the Check items permission (tick) separately to project administrators, groups, project roles or named people, under Permissions in Checklist Flow settings. Making a Required item weaker needs the Relax a control permission, which project administrators hold by default. The app's server checks the permission on every change; Jira administrators are always allowed.

Does Checklist Flow work in the Jira mobile app?

Not yet: Atlassian's Jira mobile apps do not show Forge apps today (Atlassian's issues FRGE-538 and FRGE-1492). Open Jira in your phone's browser instead, where you can tick items with one tap in the Definition of Done glance or in the panel's work view.

Can I move my checklists from another app?

From Smart Checklist, HeroCoders Checklists and Checklist for Jira Enterprise (with their custom field sync on) and Multiple Checklists by SolDevelo, yes: a Jira administrator picks the app and a JQL, runs a dry run, then imports. The other app is not changed, a repeated run adds nothing twice, and each run can be undone. From other apps, paste their exported text into Import on each work item.

Checklist Flow is paid via Atlassian. Without an active paid licence the app keeps working with a reduced feature set. Sites with up to 10 users get the paid edition at no cost, because the 10-user tier is $0; prices for larger teams are on the comparison page.

Where a paid feature is unavailable, the app shows a Start free trial button that opens the app's pricing page on the Atlassian Marketplace, where the free trial starts.

In the app, locked templates in the library and paid sections of the admin page carry a Pro badge.

If a licence lapses, nothing already saved is removed and checklists keep taking new items up to 2,000 entries; saved templates can still be applied, but no new ones can be saved while the site has 10 or more. The permissions fall back to "anyone who can open the work item can edit and tick" until the licence is active again; the saved model is kept.

The app writes to Jira in these places only: those two issue properties, the value of its own read-only Checklist progress field (Jira's API for an app's own field values needs no extra permission; with the Jira history option on, each change also adds a line to the work item's history), the e-mail to a newly assigned person, and, when you click Turn into work item, the new work item and its link. Checklists themselves live in the app's own storage. It never edits fields such as the description on an existing work item: a blueprint is applied by your own Jira Automation rule. It does not store work item descriptions or comments. It declares no external network access, so it cannot send data anywhere outside Atlassian.

• All data is stored in Forge hosted storage on your own Atlassian site. Stanki Guild operates no servers and has no access to your data.
• Stored: item text, sections, checklist titles and names, notes, due dates, item states (checked, Required, N/A, status, priority, "Customer can tick"), assignee account IDs, the work items created from items (their id and key), linked condition settings, only-when rules (a field id and values), the change history (account ID, time and what changed), templates, global checklist definitions and each work item's progress on them, checklist rules, item status definitions, blueprints (description template, policy name, issue types and project keys), release checklists and their history, migration runs (which work items an import touched and what it added, so it can be undone), the auto-apply map, settings (including who last changed Lock when done, the assignee e-mail and the Jira data options), project statuses and project templates, the permissions model (roles and the people, groups and project roles that hold them) with its hash-chained log, the settings change log (who changed which setting, old and new value, newest 1,000 entries), an error log of the last 20 failures (function name, error code and time, no personal data), an index of work item keys to ids with markers of which checklists were moved (no personal data), and a list of the account IDs the app holds, for personal data reporting.
• On each work item with a checklist, the app also writes the issue property com.stankiguild.checklistflow.dod for JQL: five numbers (whether the Definition of Done is met, open items, total, done and percent resolved), the number of open items without an assignee, the account IDs of up to 20 people who own open items, the earliest open due date, the head of the checklist history, the names and ids of the templates applied and, for named checklists, each one's name, counts and whether it is met. Only if a Jira administrator turns on Item text in JQL does it also hold the text of up to 50 open Definition of Done items. It also writes the Checklist progress field value, such as "3/5, DoD met", and, on a Jira Service Management request, the small property com.stankiguild.checklistflow.portal that records whether the portal view is on.
• Not stored: display names (looked up when the panel is shown), email addresses, passwords or tokens. The work item summary and description, and the comments, links, web links and attachment names read for the evidence review, are passed to Rovo and not stored.
• The change history is kept as the audit trail while the app is installed. When Atlassian reports an account as closed, the app clears that person's item assignments and removes their account ID from the history, recording the redaction so the chain still verifies. The same change rewrites the issue property without them. A Jira administrator can run the same erasure for one person on request with Erase a person on the People tab of Checklist Flow settings, with or without a paid licence; the app keeps an erasure log with the counts, who ran it and when, but not who was erased.
• On uninstall, the app runs a clean-up that first rewrites the JQL issue property without account IDs (and without item texts) on every work item whose checklist has an assigned item, or on every work item with items if Item text in JQL was ever turned on, then deletes its stored data: every checklist (release checklists included), the full change history, every template, every global checklist, the checklist rules, item statuses and blueprints, project statuses and templates, the permissions model and its log, the settings log, the error log, the migration runs, the record of work items created from items, the auto-apply map, the settings, the key index, the personal data list and the erasure log. If the clean-up cannot finish, Atlassian holds the remaining data only for its 28-day retention window after uninstall and does not restore it automatically on reinstall; we cannot read it during that time.
• The clean-up does not remove the JQL issue property from work items. It keeps the five numbers, the number of unassigned open items, the earliest open due date, the template and checklist names and the chain head from the last change, never item text or account IDs. The small portal property, which only says whether a request's portal view is on, also stays. The rewrite gets up to 25 seconds; on work items it could not reach in that time, or where Jira refused, the property also keeps the account IDs of the people who then owned open items. Delete it in Jira if you need it gone.
• Uninstalling deletes all records. Reinstalling does not bring them back: from the app's point of view the deletion is final. Export first: the checklist and history exports work without a paid licence.

Full details: Privacy Policy, Security Policy, Data Processing Addendum.

• Documentation and policies: https://stankiguild.com/
• Support: support@stankiguild.com, 09:00-17:00 Monday to Friday, Europe/Warsaw. See Support for response targets and what to include.
• Security issues: security@stankiguild.com
• Privacy and data protection: privacy@stankiguild.com

• Jira checklist templates: 49 ready-made templates for Checklist Flow
• How Checklist Flow works: a walkthrough with real screenshots
• Checklist Flow compared with other Jira apps: installs, prices and features of the alternatives, with sources
• Switching to Checklist Flow: what moves from other apps, with a dry run first
• Attestation Flow for Confluence: documentation
• Approval Flow for Jira: documentation