Practical guide and editable worksheet · Sources checked November 9, 2026
Decision Log Template with Examples and Review Checklist
A decision log records a decision, why it was made, who approved it, what work it affects, and when the team should revisit it. Use the editable CSV for a searchable index, then link each significant entry to its supporting evidence. The example below follows a product-export decision from its first approval to a later change.
Start with the editable resources
CSV files work in Excel and Google Sheets. The example is fictional. Use the blank file for your own records and the Markdown worksheet for the reasoning behind them.
Decide what deserves a record
Record decisions that constrain future work or are likely to be questioned later. Examples include choosing a permission model, excluding a requested capability, selecting a rollout approach, or accepting a known limitation. Routine implementation details can remain in the ticket when they do not create a wider commitment. The test is whether a future teammate would need the reasoning to make a safe change.
A log should let someone find the current decision quickly, then recover the earlier thinking without guessing which meeting mattered. A meeting note captures what happened in a conversation. A decision record captures the outcome, considered alternatives, rationale, consequences, and responsibility. You can link the meeting note as evidence without asking everyone to read the entire transcript.
Start with an index and one decision record
The blank download is a plain CSV index with fields for ID, question, decision, status, driver, approver, date, evidence, affected work, review trigger, and superseding ID. Use one stable identifier per decision, such as D-014. Keep the ID when the title changes. A descriptive question is easier to search than an entry named “Thursday discussion.”
For a decision with substantial tradeoffs, link the index row to a fuller record. The accompanying Markdown supplies an editable structure for context, options, rationale, consequences, and follow-up work. Atlassian's DACI guidance separates the person driving a decision from its approver, contributors, and people who need to hear the outcome. Apply those responsibilities in a way that fits your team's authority.
A complete illustrative decision
The example is fictional. A software team needs to export account activity without making the interface unresponsive. D-014 asks whether the first release should create exports immediately or run them as background jobs. The PM gathers support notes and an engineering estimate. The engineering lead checks operational implications. The designated product approver chooses a synchronous first release with a documented size limit.
The rationale is bounded: the initial export scope is small, the size limit is explicit, and the team can observe failures before expanding support. The consequence is equally visible: users above the limit cannot complete the export through this path. The record names the evidence IDs, links the impacted requirement R-103 and ticket ENG-43, and sets a review trigger if the limit blocks an eligible customer.
A later review creates D-019, approving background jobs and completion notifications after the trigger is met. D-014 is marked Superseded and points to D-019. D-019 points back to D-014. Someone investigating an older release can now understand why it behaved differently, while someone planning current work can identify which decision applies today.
| Decision ID | Question | Decision | Status | Driver | Approver | Date | Evidence IDs | Affected work | Review trigger | Supersedes | Superseded by |
|---|---|---|---|---|---|---|---|---|---|---|---|
| D-014 | How should initial exports run? | Synchronous export with an explicit size limit | Superseded | PM | Product approver | Illustrative first review | E-01; E-02 | R-103; ENG-43 | Eligible customer blocked by limit | — | D-019 |
| D-019 | Should exports move to background processing? | Background job with completion notice | Accepted | PM | Product approver | Illustrative later review | E-03; E-04 | R-103; ENG-43; AT-03 | Job completion or failure experience changes | D-014 | — |
Compare alternatives before writing the conclusion
Write the decision question first. For the export example, alternatives are synchronous processing with a size limit, background processing, and deferring the feature. Compare them against the same criteria: user outcome, implementation effort, operational risk, support burden, and reversibility. A table where each option receives a different criterion can disguise an opinion as analysis.
Separate evidence from estimates. “Engineering estimates two days” is a planning input that may change. “The current export fails on the attached test case” is an observation that can be reproduced. A customer quote is evidence of that person's experience, not proof of a universal need. Keep links to the originals so later reviewers can challenge the interpretation without rewriting history.
Avoid inventing precision. If the team has not tested export performance, record that uncertainty and plan a check before committing to a threshold. The purpose of the log is to expose the basis for the decision. It should not manufacture certainty so the approval looks more polished.
Define statuses and authority
Use a small status set such as Proposed, Accepted, Rejected, and Superseded. Add Deferred only if it describes a meaningful state in your process. Proposed means the team is still gathering evidence. Accepted means the authorized person made the choice. Rejected preserves a considered option or decision that was not adopted. Superseded identifies an earlier choice replaced by a linked later decision.
An owner maintains the record and follows up on its consequences. An approver has authority to make the call. They may be the same person in a small project, but record the role clearly. Assign contributors when their expertise is necessary, such as security review for permissions. Inform the people whose documents, tickets, customer commitments, or operations must change as a result.
Turn the decision into linked work
After approval, update the affected requirement and delivery work. Put the decision ID in those artifacts and add their identifiers to the record. For D-019, the completion-notification requirement and operational retry behavior need review alongside the export implementation. A decision that says “approved” while every downstream ticket still describes the old behavior has not been operationalized.
Make follow-up work explicit. Each action needs an owner and a completion condition. Keep approval separate from action completion, so the log can show an accepted decision whose migration work is still open. If an artifact is intentionally unchanged, document the reasoning rather than leaving the reviewer to infer whether it was missed.
Review without rewriting the past
Use event-based triggers where possible. A changed assumption, failed experiment, incident, customer constraint, or new product direction may justify review. A calendar review can catch neglected records, but a recurring meeting alone does not establish that a decision remains valid. Ask which evidence and constraints have changed since the last review.
Correct simple errors transparently. For a changed choice, create a new record and preserve the earlier one with a superseded link. Do not overwrite the old rationale to make the current decision appear inevitable. Historical context matters when debugging an older release or explaining a previous commitment. This also makes disagreement safer because contributors can see their concerns represented accurately.
Choose a home and keep access usable
The CSV can be opened in Excel or imported into Google Sheets. Put the working log where affected teams can read it, and store supporting evidence according to its access restrictions. Customer research or sensitive security details may need a restricted source link and a carefully written summary. Test that reviewers can access the references they are expected to approve.
Start with this tool-neutral record, then implement the workflow in your team's existing system. The related Notion and Confluence guides cover those specific setups. Do not create a separate decision log for every tool if that leaves teams unable to identify the authoritative record. One index can point to records and evidence wherever they legitimately belong.
Sources and method
Primary guidance checked November 9, 2026. The worked scenario, field choices, examples, and review recommendations are editorial synthesis. The linked sources explain the underlying practices.