Who Approved This? Decision Tracking That Answers the Question

You can only answer "who approved this?" if the approval was recorded as a named person, with the authority they held, on a specific date, alongside the reasoning at the time. Everything else is reconstruction: reading a Slack thread, guessing from a merged pull request, or asking three people who each remember it differently. A decision tracking system exists to turn that reconstruction into a lookup.

The question usually surfaces at the worst moment. An audit, an incident review, a customer escalation, or a new hire asking why the architecture works the way it does. If the answer takes a week of archaeology, the cost is not just time. It is the credibility of every decision the team claims to own.

Who approved this? The direct answer

The answer is: whoever the decision record names as the approver. If no record names an approver, then no one approved it in any defensible sense, and that itself is the finding. A decision without a named approver was not governed. It happened.

This is the mental shift. "Who approved this?" is not a search problem you solve by finding the right message. It is a data problem you solve by capturing approval at the moment it happens. The teams that answer the question in seconds are the ones who wrote it down on purpose, not the ones with better search.

Why approval gets lost

Approval disappears because it is almost never a discrete event in the tools where work happens. It is inferred from a thumbs-up emoji, a "sounds good," a merged branch, or silence in a channel. None of those survive contact with time. Six months later, the emoji is buried, the person who reacted has left, and the thread has 200 replies.

• Approval is implied, not stated. A reaction or a brief reply reads as approval in the moment but carries no authority, scope, or reasoning when you revisit it.
• The record lives in the wrong system. Jira tracks the task, not the judgment. As we cover in whether Jira captures decisions, the ticket tells you what shipped, never who decided it should.
• Context evaporates. The why behind an approval is the first thing to go, and it is exactly what you need when the decision is questioned.
• People leave. When the approver departs, the only copy of the reasoning often leaves with them. This is the core of capturing decision context before people leave.

What a decision record must capture

To answer "who approved this?" reliably, a decision record needs a fixed set of fields, captured once, at the time of the decision. The point is not bureaucracy. It is that each field answers a question someone will eventually ask.

Field	Question it answers
Decision	What was actually decided?
Approver	Who approved this?
Authority	Under what mandate could they approve it?
Date	When was it approved?
Reasoning	Why, given what we knew then?
Reversibility	Can this be undone, and at what cost?

The reversibility field matters more than people expect. An approval for a reversible decision needs far less ceremony than an irreversible one, and knowing which is which changes how much scrutiny "who approved this?" deserves. We go deeper in reversible versus irreversible decisions.

Where teams try to track approvals

Most teams reach for a tool they already have before they adopt anything new. Each partially works, which is why the gap persists for years.

• Slack: real-time and where approvals actually happen, but approvals are ephemeral and unsearchable at the field level. Great for the conversation, useless as the record.
• Jira or Linear: good for tracking that work happened, silent on who authorized the direction. A closed ticket is not an approval trail.
• Confluence or Notion: can hold a proper decision log if you enforce it, but nothing stops the page from going stale or the approver field from being left blank. See using Confluence as a decision log.
• A dedicated system of record: treats the decision, its approver, and its authority as first-class data rather than prose. This is where StandIn fits: every declared decision names an owner and the authority behind it, so the answer is a lookup, not a hunt.

Approval versus authority

Here is the subtlety that trips teams up: knowing who clicked approve is not the same as knowing who was allowed to. "Who approved this?" is only a satisfying answer when the approver actually held the authority to make that call. Otherwise you have found a signature, not a decision.

That is why serious decision tracking pairs approval with an authority map: a declared statement of who owns which classes of decision. When the two line up, the record is defensible. When they do not, you have surfaced a governance gap worth fixing. StandIn keeps approval and authority in the same declared record, so accountability is never separated from the person who held it.

Common Questions

How do you find out who approved a past decision?

Look for a decision record that names the approver, the date, and the authority. If one exists, the answer is immediate. If it does not, the honest answer is that the decision was never formally approved, and reconstructing it from chat history will give you a guess, not a fact.

Does Jira track who approved a decision?

Not reliably. Jira records that a task was created, assigned, and closed, but approval of the underlying decision is usually implied through comments or status changes rather than captured as a named, timestamped field. For approval accountability you need a decision record layered alongside the ticket.

What is the difference between an approver and a decision owner?

The approver signs off on a specific decision; the owner holds ongoing accountability for the area the decision affects. They are often the same person, but not always. A good record captures both so you know who to ask when the decision is later questioned or needs revisiting.

Why does approval need reasoning attached?

Because "who approved this?" is usually followed by "and why?" An approval without reasoning tells you a name but not whether the call still holds given what you know now. Capturing the reasoning at the time turns a defensive audit into a straightforward review.

Stop reconstructing approvals after the fact. StandIn records each decision as a declared source with a named owner and the authority behind it, so "who approved this?" is always a question with an answer.