Confluence decision log template (free) + ADR template

This page is the template I'd hand any team that wants a decision log in Confluence and wants it set up by this afternoon. There are three parts: a page template for each decision, a register page that updates itself, and an ADR variant for architecture decisions. Everything is copy-paste.

If you're still deciding whether Confluence is the right home for your log at all, start with our comparison of decision log software. If you already run on Jira and Confluence, it usually is. For the documents around a decision, there are companion templates for an ADR, an RFC or design doc, and a DACI decision.

How the setup works

Confluence has three decision features, and they're easy to mix up:

• Decision items. Type /decision in the editor and you get a highlighted one-liner. Good for small calls inside meeting notes. Too thin for anything that constrains future work, because there's nowhere to put the reasoning or a status.
• The Decision report macro. It collects decision items across pages in a space. Useful as a quick index of those one-liners, nothing more.
• Page Properties + Page Properties Report. This is the pattern that holds up. Each decision gets its own page with a small properties table. A report macro on a parent page reads those tables from every page with a given label and shows them as one sortable register.

So the setup is: one page per decision, labeled decision, with a properties table at the top. One register page that pulls them all together.

Template 1: the decision page

Create a page, add a Page Properties macro (/page properties), and put the table below inside it. Everything below the macro is the body. Confluence converts most markdown when you paste it. If a table arrives as plain text, insert it with /table and fill the rows.

Title: DEC-014: [One-line verdict, e.g. "Ship v1 without SSO"]

| Property   | Value                                       |
| ---------- | ------------------------------------------- |
| Status     | Proposed / Accepted / Superseded / Rejected |
| Owner      | @person who made the call                   |
| Decided on | 2026-10-25                                  |
| Review by  | 2027-01-25 (or "none")                      |
| Area       | Pricing / Platform / Onboarding / ...       |
| Supersedes | link to earlier decision, if any            |

## Decision
One or two sentences, written as an instruction someone could follow.

## Why
The reasoning and the constraint that forced it. Link the Slack thread,
meeting notes, or PRD where it was decided.

## Options we rejected
- Option A: why not
- Option B: why not

## Who agreed
@names, and anyone who disagreed but committed.

## What this changes
PRDs, tickets, or code that must now follow this. Link the Jira issues.

Then add the label decision to the page. The label is what the register reads.

Four rules make this template work. Most teams that say their Confluence log died skipped them.

1. The verdict goes in the title. "DEC-014: Ship v1 without SSO" is findable. "Auth discussion" is not.
2. A decision is never edited away, it's superseded. When a call is reversed, set the old page's status to Superseded, link the new page, and leave the old reasoning intact. The history is the point.
3. Every page has one owner. Not a team: a person.
4. Temporary calls get a review-by date. "We'll use Postgres for the queue until Q2" without a date becomes permanent by accident.

Template 2: the register page

Create a parent page called Decision log and nest the decision pages under it, or just keep them in the same space. Add a Page Properties Report macro with:

• Label: decision
• Columns to show: Status, Owner, Decided on, Review by, Area
• Sort by: Decided on, newest first

That's the whole register. It updates every time someone publishes a labeled page. Nobody maintains a list by hand.

Two optional additions earn their keep. Put a second report above the main one filtered to label decision plus status Proposed: that's your review queue. And put a short note at the top of the page saying how to file a decision and who owns the log. A log without an owner is the first thing to die.

Template 3: ADR (architecture decision record) for Confluence

Architecture decisions follow the format Michael Nygard proposed in 2011: context, decision, consequences. The version below adds the same properties table so ADRs show up in the register too. Label these pages decision and adr, then filter by adr for an architecture-only view.

Title: ADR-007: [Decision, e.g. "Use Postgres as the job queue"]

| Property   | Value                                                    |
| ---------- | -------------------------------------------------------- |
| Status     | Proposed / Accepted / Deprecated / Superseded by ADR-0xx |
| Owner      | @engineer                                                |
| Decided on | 2026-10-25                                               |
| Review by  | when load passes 5k jobs/min                             |
| Area       | Infrastructure                                           |

## Context
The forces at play: requirements, constraints, what's true about the system
today. Write it so someone joining in a year understands the pressure.

## Decision
"We will..." in active voice.

## Consequences
What becomes easier, what becomes harder, and what we're now committed to.
Include the trade-offs we knowingly accepted.

## Alternatives considered
- Option: why it lost

Should ADRs live in Confluence at all? If your engineers write and review them, the repo is a better home: they get versioned and reviewed in the same PRs as the code. Confluence wins when PMs, designers, or other teams need to read them too. I go deeper on that trade-off in the ADR guide, and the glossary entry on ADRs has the short version.

Saving these as space templates

So nobody has to come back to this page, save Templates 1 and 3 as space templates. Space admins can do that from the space's template settings (Atlassian moves the menu between Cloud releases; search "create a template" in Confluence help if it's not where you expect). Set the label in the template itself, so every new decision page arrives pre-labeled and appears in the register automatically.

If you'd rather start from Atlassian's own material, the DACI template in the Confluence template gallery covers the making of a decision: driver, approver, contributors, informed. It pairs well with this setup. Use DACI while the call is open, then file the outcome with Template 1.

Where Confluence decision logs fail

This template fixes structure. It doesn't fix the reason most decision logs die: somebody has to notice a decision happened, leave the conversation, and file it. The big calls get filed. The "let's cut that from v1" in a Slack thread doesn't, and that's the kind of decision that later gets silently violated. I wrote about that failure mode in why engineering decision logs starve.

That's the gap we built Lockstep for. It drafts decision entries from Slack, Jira, and Confluence itself, routes each one to its owner for one-click approval, and briefs engineers and AI coding agents on the approved ones. You can keep this template as your format and let Lockstep do the filing. If you're weighing the two directly, there's an honest Lockstep vs Confluence comparison.

Either way: create the register page today, file the last three decisions your team made, and see who reads them.