Require an approver and a reason before a Jira field value changes

The situation

A Jira user described it on Atlassian Community: "I would like the change to transition to an approver before it actually committed" — with a reason picked for every change. That is the whole requirement: a proposed value, a reason, a decision, and only then a write. (Their field was a date, which FieldLock does not support today — it protects numbers, and in Guarded mode single-line text — but the flow is the same.)

Why workflow approvals don't cover it

Approvals in Jira — in Jira Service Management and, more recently, in Premium and Enterprise plans — are attached to workflow transitions. They answer "may this issue move to the next status?", not "may this field hold a new value?". You can emulate a field approval with a dedicated status, a screen and an automation rule, but the field itself stays editable for anyone with edit permission while all that is going on.

How the approval flow works in FieldLock

1. Protect the field in the project settings and choose who approves: project administrators or a project role.
2. Request. Anyone who can browse the project proposes a value and must give a reason. The request changes nothing on its own; one issue holds one open request at a time.
3. Decide. An approver sees the proposed value and reason and approves or rejects. With the optional four-eyes rule, nobody approves their own request.
4. Write. Only the app writes the value: after an approved request, or when an approver sets it directly in the panel — which is logged as well.
5. Record. Request, approval, rejection and withdrawal go into an append-only log chained with SHA-256.

Meanwhile the field refuses direct edits from the issue view, the REST API, bulk edit and automation — so nobody can change the value around the panel. The four-eyes rule applies to requests; approvers setting a value directly are recorded in the log with their account.

That refusal is Locked mode, which uses the app's own numeric field. If you want to keep a field you already have — including a single-line text field such as a contract number — that is Guarded mode, and there an outside edit goes through and is restored to the approved value shortly after, usually within a minute or two. The request and approval flow above is identical in both modes; only the strength of the block differs. Compare the two modes.

Proof you can show outside Jira

The panel verifies the log chain every time it opens. Issue proof exports the log as a readable document and as JSON; pasting the JSON back into Verify proof later detects both edited entries and deleted newest entries. Useful when a client, auditor or finance team asks who agreed to a value and when.

Good fits and poor fits

• Good: contract value, budget, cost estimate, agreed price — values that should change rarely and deliberately. Contract and agreement numbers work too, as single-line text, in Guarded mode (the change is undone rather than refused).
• Poor today: dates (including the built-in Due date), multi-line text and built-in Jira fields; text values where only the hard refusal will do — text is Guarded only; values that automation must keep updating; hiding values from viewers.