Does Jira have a built-in decision log?

Not as a dedicated feature. Confluence has decision items and a decision report, which many teams pair with Jira. To keep the log in Jira itself, an admin adds a Decision work type, a few custom fields, a small workflow, and a filter that lists decisions as a register.

Should decisions live in Jira or Confluence?

Confluence suits long reasoning and pages people read. Jira suits decisions that must stay linked to the tickets they govern and need automation, such as review reminders. Many teams write the reasoning in Confluence and track the decision itself as a Jira work item that links to the page.

How do I link a decision to the tickets it affects?

Create a custom link type in Settings > Work Items > Work Item Linking, for example named Governs, with the outward description governs and the inward description is governed by. Then link each Decision to the stories and epics it constrains.

How do I stop a Jira decision log from going stale?

Give every decision an owner and a review date, and use a Scheduled automation rule with a JQL query to remind owners when the date passes. Mark reversed decisions Replaced and link them to the new decision instead of editing the old one.

Can Jira automation notify teams when a decision changes?

Yes. A rule triggered when a Decision work item transitions can branch to its linked work items and comment on each one, or send a Slack message. That tells the people working on governed tickets that a rule they depend on has changed.

Decision log in Jira: a template and automation rules

A team uses Jira for everything. Stories, bugs, epics, incidents. Decisions live somewhere else: a Confluence page, a Slack thread, someone's memory. When an engineer opens a ticket, nothing on it says that the team decided last month to cap free workspaces at three projects.

A decision log in Jira fixes the location problem. The decision sits next to the work it governs, links to it, and can trigger automation when it changes. This guide sets one up with standard Jira Cloud features, using Atlassian's current documentation and terms. Jira now calls issue types "work types" and issues "work items", and this guide uses those names.

When a Jira decision log makes sense

Keep decisions in Jira when they constrain work that is already tracked there, and when you want them linked to that work and checked automatically. Keep them in Confluence, or link out to a Confluence page, when the reasoning runs to pages and people need to read it as a document.

The two combine well. For a Confluence-first setup with a page per decision and a self-updating register, use the Confluence decision log template. For other ways to attach decisions to tickets, see how to link decisions to Jira tickets.

Step 1: add a Decision work type

A Jira administrator adds work types in company-managed spaces. Per Atlassian's guide, go to Settings, then Work items, then Work types, and choose Add work type. Name it Decision, add a short description, and choose a standard work type, not a sub-task.

Then add it to the work type scheme of each space that should use it.

Step 2: add the fields

A decision needs more than a summary. These are the fields worth adding, and why:

Field	Type	Why it exists
Summary	Built in	The decision in one sentence: "Free workspaces are capped at 3 projects"
Description	Built in	Context: what problem forced the decision
Reason	Paragraph	Why this option won
Rejected options	Paragraph	What else was considered, so nobody reopens it without new information
Decision owner	User picker	The one person who can change it
Approved by	User picker, multiple	Who agreed, especially other teams affected
Review date	Date	When to check the decision still holds
Source	URL	The Slack thread, PRD section, or meeting notes it came from

Keep the list short. Every required field is a reason someone skips filing. Reason and owner are the two worth making required.

Step 3: a three-status workflow

Decisions need states that tickets don't. A simple workflow:

Status	Meaning
Proposed	Written down, not yet agreed
Accepted	Agreed. Work must follow it
Replaced	No longer current. Linked to the decision that replaced it

Do not delete or edit an accepted decision when the team changes its mind. Create a new Decision, accept it, and move the old one to Replaced with a link to the new one. The history of why the rule changed is the most useful thing a decision log holds, and editing destroys it.

Step 4: a link type for governed work

Jira's default link types, such as "relates to" and "blocks", don't say what a decision does to a ticket. Create a custom one. In Settings > Work Items > Work Item Linking, add a link type with these values:

Property	Value
Name	Governs
Outward description	governs
Inward description	is governed by

Now a story can show "is governed by DEC-12: Free workspaces are capped at 3 projects" in its links panel. Anyone opening the story, or any tool reading it, sees the constraint.

Add one more link for replacements: a link type named Replaces, with the outward description replaces and the inward description is replaced by.

Step 5: the register is a filter

The decision register is a saved JQL filter, not a separate page. For all current decisions in a space:

type = Decision AND status = Accepted ORDER BY created DESC

Save it, share it with the team, and add it to a dashboard. Two more filters are worth saving:

type = Decision AND status = Proposed ORDER BY created ASC

type = Decision AND status = Accepted AND "Review date" <= now()

The first is decisions waiting for agreement. The second is decisions due for review.

Step 6: three automation rules

Automation is what keeps the log from going stale. Jira's automation triggers and actions cover all three rules below.

Rule 1: remind owners to review.

Trigger: Scheduled, every 7 days, with the JQL type = Decision AND status = Accepted AND "Review date" <= now(). The documentation says actions then run on the work items the query returns.
Action: Send customized email or Send Slack message to the decision owner, asking them to confirm, update, or replace it.

Rule 2: tell governed work when a decision changes.

Trigger: Work item transitioned, for Decision work items moving to Replaced.
Branch to the related work items linked by Governs.
Action: Comment on work item on each one: the decision this ticket follows has been replaced, see the linked new decision.

Rule 3: don't let decisions sit in Proposed.

Trigger: Scheduled, every weekday, with the JQL type = Decision AND status = Proposed AND created <= -7d.
Action: Send Slack message to the team channel listing them.

Rule 2 matters most. A changed decision that nobody working on the affected tickets hears about is the most common way a decision log fails.

A filled-in example

DEC-12  Free workspaces are capped at 3 projects
Status:           Accepted
Description:      Free accounts with 10+ projects cost us more than the
                  upgrade rate earns back.
Reason:           Most free workspaces use fewer than 3 projects, so most
                  users never see the cap.
Rejected options: Soft cap with warnings (users ignored them in the test);
                  cap at 5 (too few upgrades in the model).
Decision owner:   Priya (PM, Growth)
Approved by:      Head of Product, Billing tech lead
Review date:      1 February
Source:           PRD "Free plan limits", section 3
Links:            governs GROW-201, GROW-207, BILL-88

Where a Jira decision log falls short

A Decision work type solves where decisions live. It doesn't solve how they get there. Someone still has to notice that a decision was made in a Slack thread or a review comment and file it, and under deadline pressure that is the first thing to slip.

It also doesn't reach the agents writing code. An AI coding agent working on GROW-207 sees the decision only if something hands it the ticket and its links. Most agent sessions start from the repository, not from Jira.

Where Lockstep fits

Lockstep handles the two gaps above. It captures decisions where they are made, including Slack threads, PRDs, Jira, and pull requests, and drafts them for the owner to approve in one click, so filing doesn't depend on someone remembering. Approved decisions brief Claude Code at the start of each session, and any MCP agent can query them. When a decision is replaced, the old version stays visible as replaced.

It does not replace your Jira setup. Keep the Decision work type if your team lives in Jira; Lockstep works alongside it. Jira capture is one of the newer integrations, and session briefings work with Claude Code today. See Lockstep for Jira.

Sources checked 4 November 2026

For a tool-agnostic version, use the decision log template. For a Confluence register, see the Confluence decision log template. To compare tools, see the best decision log tools for product and engineering teams.

Frequently asked questions