Guide · Jira

Jira Automation with checklists: apply a template, add and check items, read status

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

By Bartosz Stankiewicz, founder, Stanki Guild.

Jira Automation can create work items, edit fields and post comments, but it cannot see native checklists: action items in descriptions cannot be read or ticked by a rule. The request is open in Atlassian's tracker as JRACLOUD-96783. Checklist automation therefore runs through a checklist app that adds its own Automation actions, or through JQL fields the app keeps up to date.

This guide gives four recipes. The action names come from our app, Checklist Flow, which adds 15 actions to Jira Automation, among them Apply checklist template, Add checklist item, Check checklist item, Uncheck checklist item, Set checklist item status, Apply checklist rules and Get checklist status. If you use another app, the concepts carry over and the names differ. Rules are built in the Automation rule builder, either for one project or globally by a Jira administrator (Jira settings, System, Automation flows).

Recipe 1: apply a checklist template when a work item is created

The most useful rule of the set: the checklist is there before anyone opens the work item.

Create a rule with the trigger Work item created.
Add a condition on the work item type, for example Bug, so only the types that need the template get it.
Add the action Apply checklist template and enter the template's name. The name is matched without regard to case and must match exactly one saved template on the site.
Turn the rule on and create a test work item of that type.

The template must be saved on your site first: save one from a work item's checklist, or install one from the template library (49 templates in 18 categories, among them Definition of Done, Bug fix verification, Release readiness and Code review). If you only need "this type always gets this template", Checklist Flow's auto-apply by issue type does the same without a rule.

Recipe 2: add a checklist item from a rule

Use case: a label or field value implies an extra step. For example, every work item labelled security gets a security review item.

Trigger: Field value changed, field Labels.
Condition: a JQL condition such as labels = security.
Action: Add checklist item, with the item text, and switch on its Required option if the item must block the Definition of Done.
Check the rule's Audit Log after the first run. In Checklist Flow's history export, changes made by Automation are marked automation in the via column, with the rule actor as the person.

Recipe 3: check an item automatically when something happens

Use case: an item says "Deployment done", and the deployment already transitions the work item when it finishes.

Trigger: Work item transitioned, to the status the deployment sets.
Condition: restrict to the project or label where that checklist item exists.
Action: Check checklist item, with the item text as it appears on the checklist. Checklist Flow checks every item whose text matches exactly, ignoring case; Uncheck checklist item is the separate action that unchecks.
Test end to end: the panel should show the item checked, and the rule stops with a readable reason in its Audit Log if no item matches.

Honest limit: matching by text is fragile. If someone rewords the item, the rule stops matching and fails. Keep automated items short and stable, or prefer applying whole templates over editing single items.

Recipe 4: route work by checklist state

Use case: list the stragglers before the sprint review, or flag work items that reached Done with the checklist unmet.

Checklist Flow writes the checklist state to JQL fields: dodMet (searched as text, dodMet = "true" or dodMet = "false"), dodOpen, checklistTotal, checklistDone and checklistProgress (percent of items resolved), and eight more such as checklistAssignee and checklistDue (13 in all, listed in the documentation). They are searchable values stored in an issue property, not regular fields, so the reliable pattern is a scheduled rule with a JQL search:

Digest: trigger Scheduled, with the JQL dodMet = "false" AND sprint in openSprints(), and an action such as Send customized email or Comment on work item.
Breach detector: trigger Scheduled, JQL dodMet = "false" AND statusCategory = Done, action: add the label dod-breach, so a weekly review picks them up.

Inside a rule, Get checklist status returns openRequired, total, done, progress, dodMet, na, overdue, openItems, assignees and nextDue for later steps, optionally for one named checklist (every checklist with that name, counted together), so a rule can branch on the checklist of the work item it is handling.

What Automation cannot fix

Automation does not make people do the work. Enforcement is the workflow validator's job: it blocks the transition while a required item is open. Automation routes and records; the validator blocks.
Rules count against your plan's allowance. Jira Automation usage is measured in steps (each trigger, condition and action that runs), with a monthly allowance that depends on the plan; see How is my usage calculated?. A rule for every micro-step uses it up quickly, so prefer one template rule over five single-item rules.
Rules run as their actor. If the actor cannot open a work item, Checklist Flow's actions refuse, and the reason appears in the rule's Audit Log instead of the rule failing silently.

How our app helps

Checklist Flow is our app, and four of its 15 Automation actions are the ones used above. The others uncheck, remove, set Required, N/A, due date, assignee or status, check all, run the app's checklist rules, read a work item blueprint and add items from text, for example a checklist proposed by Atlassian's Use Rovo agent action. They need an active paid licence, which is free on sites with up to 10 users; the validator, the JQL fields and the full history work in every edition. Every change made by a rule lands in the same append-only, hash-chained history as manual changes, and the same templates are available in the panel, through auto-apply and through the Rovo assistant.

Pricing: free for up to 10 users with every feature, then from USD 0.80 per user per month for the first 100 users. See the documentation and the comparison with other checklist apps.

Common questions

Can Jira Automation see native action items?

No. Action items cannot be read or changed by Automation; the request is tracked as JRACLOUD-96783. Checklist automation needs an app that adds its own actions.

What is the difference between auto-apply and an Automation rule?

Auto-apply is app configuration: a template mapped to an issue type, applied when a work item is created, with no rule to maintain. An Automation rule is logic you control, with more flexibility, at the cost of setup and Automation steps. Both can land the same checklist; pick one per issue type, not both.

Do the actions respect permissions?

The actions run with the rule actor's access, and a work item the actor cannot open is refused with an explicit message in the rule's Audit Log. Making a Required item weaker (Set checklist item Required to off, or Remove checklist item on a Required item) also needs the Relax a control permission for the rule actor; without it the rule stops with a sentence in its Audit Log.

Can I apply a checklist to many existing work items at once?

Yes, with a scheduled or manually triggered rule over a JQL search that runs Apply checklist template for each work item found. Each run applies one template to one work item, and every run uses Automation steps, so backfill in batches.