FieldLock for Jira

A Jira field that cannot be changed without approval. Contract value, budget, agreed deadline — the numbers people quietly overwrite. FieldLock makes every change go through request → approval → write, and writes each event into a log nobody can edit afterwards.

What the app actually does

Jira has no way to make a single field read-only for everyone but a chosen group. The request for it has been open since 2003 and is resolved as Won't Fix. FieldLock fills that gap on Jira Cloud with a Forge app: the protected field can only be written by the app itself, and the app writes only what an authorised person approved.

Direct edit in the issue view, REST API, bulk edit and Jira automation are all rejected.
Anyone with access to the issue can request a change and give a reason.
Project admins — or a project role you choose — approve or reject it.
Every request, approval, rejection, withdrawal and automatic correction goes into an append-only log chained with SHA-256 hashes.
The log can be exported as a proof document that also detects later deletion of the newest entries.

Two modes — they promise different things

Read this before choosing. The difference is not cosmetic.

	Locked	Guarded
Which field	the app's own field, added by FieldLock	your existing numeric Jira field
What happens on an outside change	the change is refused — Jira rejects the write immediately	the change goes through and is then reverted
How fast	instant, no window at all	usually tens of seconds — Forge product events arrive from ~1 s to ~4 min
Migration	values have to be entered in the app once	none — the value already in the field is adopted as the starting point

Guarded is the no-migration way in, not an equivalent of Locked. Between the edit and the revert there is a window in which the field shows the wrong value. If you need the change to be impossible rather than undone, use Locked.

Guarded currently supports numeric fields only. Locked has no such limit — its own field is numeric by design.

Setup

Install the app from the Atlassian Marketplace.
Open the project you want to protect → Project settings → Apps → FieldLock.
Turn on Field protected in this project and pick the mode:
- Locked — add the FieldLock field to the screens where it should be visible (Project settings → Issues → Screens).
- Guarded — pick the numeric field you already use.
Choose who approves: project administrators, or a project role. Administrators can always approve — otherwise a misconfigured role would lock the project out.
Optionally turn on A request is not approved by its author (four-eyes rule).
On any issue, open View app actions → FieldLock to show the panel.

Daily use

Setting the first value

A protected field is not editable on the create screen — that is the point. The first value is entered by an authorised person in the FieldLock panel on the issue, or requested by anyone and approved.

Requesting a change

Anyone who can browse the project can propose a value and must give a reason. A request changes nothing on its own. One issue holds one open request at a time; the author can withdraw their own request at any moment.

Approving

An approver sees the proposed value and reason and either approves — the value is written to Jira — or rejects it. Both outcomes go into the log with the account, timestamp and reason.

Checking the log

The panel verifies the hash chain every time it opens and says how many entries were checked. Check log re-verifies on demand. Issue proof exports the log in two forms: a readable document and JSON. Keep both — only the JSON can be verified later by pasting it back into Verify proof.

Why the proof matters: a hash chain detects an edited or removed entry in the middle, but a shorter chain is still a valid chain. The proof document remembers how many entries there were, so deleting the newest ones is detected when the proof is compared with today's log.

Known limits — stated up front

Issue creation. The Jira REST API can put a value into a protected field while creating an issue, even though the field is not on the create screen. FieldLock detects this and clears the unapproved value — median 1.8 s, under 10 s including a cold start. This is why the promise is „cannot be changed", not „cannot be set". CSV import creates issues the same way and is handled the same way.
Bulk edit lists the protected field in the form, then fails on execution. That is Jira's screen, not a FieldLock error.
Guarded revert delay — see the table above.
Guarded and numeric fields — other field types are not supported yet.
Without an active licence the app switches to read-only: values cannot be changed, requested or approved and project settings are locked, while the log and proof export keep working so your audit data can always be taken out. In Guarded mode protection stops entirely — the field is yours, not ours, and it goes back to normal Jira behaviour.

Data and security

FieldLock is a Forge app with no external backend. Approved values, project settings and the log live in Atlassian-hosted storage inside your instance's app installation. Nothing is sent to us or to any third party, and we have no access to your issue data. Details: privacy policy.