Fermata: Field Locking for Jira

Lock the Jira fields that matter so only the right people can change them, and put back edits that slip through.

Fermata locks the fields you already have. A rule makes chosen fields read-only for everyone except the people, groups and project roles you pick, and applies always, in chosen statuses, during an active sprint, or while a JQL filter matches. Changes that arrive some other way, such as bulk edit, the list view, the API, imports or automation, are put back within seconds, logged, and explained in a comment on the work item.

Getting started

Open Jira settings › Apps › Fermata: Field Locking. Only Jira administrators can see this page.
Select + New rule and start from a template, or from scratch.
Choose the projects, optionally the issue types, and the fields to lock. Each field is marked Enforced (read-only on screens, and put back if changed another way) or Screens only.
Choose when the lock applies and who can still change the fields, then Save rule.

When a lock applies

Always. Also applies when work items are created: values that others set on locked fields while creating, including imports and the API, are reset to the field's default.
In certain statuses, for example once work is Done. A change made in the same update as a status change is judged by the status the item came from.
During an active sprint, for example to freeze estimates once the sprint starts.
While the work item matches JQL, for example labels = approved. The query is checked against the item's values after the change, and Jira must accept it when you save.

Status and sprint rules never lock the create screen, so new work items can always be filled in.

Who can still change locked fields

Exempt people, groups and project roles. Company-managed projects share roles such as Administrators; each team-managed project has its own roles, which appear with the project key once that project is in the rule. By default, automation rules and other apps can still change locked fields; untick Let automation rules and other apps change these fields to lock them out too.

Locking only certain values

For a single priority or option field, tick Only certain values and choose the values only exempt people may set, such as Highest priority. Everyone else can still pick the other values; the locked ones are hidden from them on screens, and setting one another way is put back.

What people see

Locked fields are read-only on the create, view and transition screens, and hidden fields disappear from them. When a change is put back, Fermata comments on the work item, mentions the person, and names the rule and who can make the change (turn this off per rule). The Fermata panel on each work item lists the locks in force, the reason, and who can change the fields.

Audit-only rules

Set a rule to Audit only to log what it would put back without changing anything or locking any screen. Use it to see a rule's effect before enforcing it.

Activity

The Activity tab lists the most recent 500 put-backs and audit-only matches: when, the work item, the field, who changed it, what they tried to set, what it was restored to, and the rule. Filter by field, person, rule or result, and download or copy the list as CSV. The work item's own history shows the same changes.

What Fermata cannot do

Hiding is not secrecy. Hidden fields stay readable in search results, filters, exports, notifications and the API. Fermata controls who can change a field, not who can see its value.
Put-backs happen after the fact. For a few seconds the other value exists, and notifications or automation may react to it.
Rich text fields (description and paragraph fields) are locked on screens only; they are not put back, because restoring them could lose formatting.
Jira's own admin screens, such as field configuration, are outside Fermata's reach.

Permissions and data

Rules can only be created or changed by Jira administrators. Fermata reads work items and user, group and role membership to decide whether a change is allowed, writes field values back and posts comments only to put back a change, and registers screen rules for the projects you choose. It stores the rules (including the account IDs, group IDs and role IDs they exempt), a log of the most recent 500 put-backs (work item key, field, the values involved, and the account ID and display name of the person who made the change) and site settings, all in Atlassian Forge hosted storage. The app declares zero external network egress; no data leaves Atlassian's infrastructure.

Support

Questions or problems: support@helzbrand.com