A Jira field that cannot be changed without approval. Contract value, budget, cost estimate — the numbers people quietly overwrite. FieldLock makes every change go through request → approval → write, and writes each event into an append-only log in which later edits are detectable.
Jira has no way to make a single field read-only for everyone but a chosen group. The request for it was filed in 2003 and closed in 2007 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.
Read this before choosing. The difference is not cosmetic.
| Locked | Guarded | |
|---|---|---|
| Which field | the app's own field, added by FieldLock | your existing Jira custom field — number, or single-line text |
| 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 within a minute or two — Forge product events arrive from ~1 s to ~4 min |
| Migration | values have to be entered in the app once, one issue at a time (no bulk import) | none — the value already in the field is adopted as the starting point; while a field has no approved value, the first value it gets (even from an edit) is adopted |
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.
Single-line text is a Guarded-only feature. Guarded works on a custom field
you already have, holding a number or single-line text — a contract number, for example. Text is
compared exactly as written (UM/2026/014 and um/2026/014 are two
different values), leading and trailing spaces are ignored, and a value can be at most 255
characters. Locked always uses its own field, which is numeric by design. Multi-line text, dates,
select lists and built-in Jira fields (including Due date) are not supported in either mode.
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.
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.
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.
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.
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.