What this template is for
A decision log is the project artefact most often promised and least often maintained. The blocker is usually friction: people will not write a long narrative for every decision. This template solves that by making each entry a small, structured Jira issue with explicit fields - decision, options, consequences - rather than a free-form document.
It is built for PMs, tech leads, and program managers who want a durable answer to “why did we do it that way again?”.
When to use it
Use this template for any decision that future-you will need to remember the rationale for - choices of vendor, framework, scope, sequencing, or trade-off. Skip it for low-stakes operational choices (which conference room to book, what colour the chart should be).
How to set it up in Jira
Add the custom fields above to a decision-log project or component. Use
Custom Fields for the Status select list (Proposed / Accepted / Superseded /
Reversed). Link each decision to the work it affects via Jira issue links of type constrains or
informs.
Sub-task breakdown
- Capture context and options is the writing pass.
- Run the consultation ensures the right people were heard.
- Document and circulate is the formal decision step.
- Communicate to broader team turns a decision into shared knowledge.
- Set a review date acknowledges that some decisions need to be revisited.
Use STM Issue Templates to auto-create these sub-tasks on every new decision-log entry - see /stm-overview/.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Decision - Adopt Postgres for payments service | Yes |
Decision Title (custom) | Use Postgres as payments service primary store | Yes |
Decision Date (custom) | 2026-05-22 | Yes |
Decision Maker (custom) | Engineering lead | Yes |
Stakeholders Consulted (custom) | SRE, security, platform PM | No |
Context (custom) | What problem prompted the decision | No |
Options Considered (custom) | Bulleted list with pros and cons | No |
Decision (custom) | What was chosen and why | No |
Consequences (custom) | Trade-offs accepted; what this commits us to | No |
Status (custom) | Proposed / Accepted / Superseded | No |
Component/s | decision-log | No |
Labels | architecture, payments | No |
Attachments | Supporting data, RFC link | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Capture context and options
- Run the consultation with affected stakeholders
- Document and circulate the decision
- Communicate the decision to broader team
- Set a review or revisit date
Common questions
What is a Jira decision log entry template?
It is a Jira task that records a single decision with the context, options considered, decision made, consequences, and owner. One issue per decision creates a searchable, auditable history of how the project arrived at its current shape. Without it, decisions live in Slack threads, get forgotten, and get relitigated.
How do you keep a decision log in Jira?
Create a decision-log project (or use a component within an existing program project). File one Jira issue per decision using this template. Use Status to mark Proposed, Accepted, or Superseded so the log stays useful as decisions evolve. Link each decision to the work it constrains - an Epic, a feature-request, an architecture document.
Should a Jira decision log replace ADRs?
No - they complement each other. ADRs are narrative documents that live in the codebase for long-lived architectural decisions. A Jira decision-log-entry is the lighter-weight artefact for project-level and team-level decisions that may not warrant a permanent code-resident document. Use Jira for the workflow and audit trail, ADRs for foundational architecture.
What custom fields belong on a decision log entry?
Decision title, decision date, decision maker, stakeholders consulted, context, options, decision text, consequences, and status. Configure Status via Custom Fields as a select list (Proposed / Accepted / Superseded / Reversed) so you can filter for live decisions only. Required-on-create for decision maker and date.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →