Security & Compliance
In This Blog
When Jira administrators think about security, they usually think in two layers: who can access the project, and who can access the issue. Those two layers cover a lot of ground. But there’s a third layer that most Jira instances don’t have, and for teams managing sensitive data, it’s the one that matters most.
That layer is field visibility control: the ability to define, at the individual field level, who can see a value and who can edit it; independently of the issue and project permissions already in place.
Most Jira environments don’t have this. Not because it isn’t needed, but because it isn’t native.
This post covers what field visibility control looks like in practice, how it fits into Jira’s existing permission model, and what it takes to implement it without disrupting the workflows already running.
Jira’s three-layer security model, and the missing piece
Think of Jira’s security architecture as a set of concentric layers:
Layer 1: Project permissions. Controls who can interact with a project at all. Who can view it, create issues, edit issues, manage workflows. This is where most admin configuration lives.
Layer 2: Issue security schemes. Allows you to restrict visibility of specific issues to defined users or roles. Useful for sensitive tickets, but coarse-grained: it hides the entire issue, not individual parts of it.
Layer 3: Field-level permissions. Controls what individual users can see or edit within an issue they already have access to. This is the missing layer for most Jira instances.
Without Layer 3, any user who can view an issue sees every field on it; regardless of whether that data is relevant to them, appropriate for them to see, or restricted under your organization’s data governance policies.
Adding field-level control doesn’t replace Layers 1 and 2. It works alongside them. A user still needs project and issue access before field permissions become relevant. Once they have that access, field-level controls determine exactly what they see within the issue.
What field visibility control looks like in practice
The mechanics are more straightforward than the architecture discussion might suggest.
Each custom field can be assigned a set of view permissions and a separate set of edit permissions. Those permissions are defined by user, group, or role — the same constructs already used in Jira’s permission schemes. For example:
- A Salary field is viewable by the HR Manager group and the HR Director role. Everyone else who opens the issue sees no salary field at all.
- A Settlement Amount field is viewable by the Legal team group. Other stakeholders working on the same case can see the issue, track progress, and update their own fields without ever seeing the restricted value.
- An Internal Diagnostic Notes field in a JSM ticket is visible to agents but not to requesters or external vendors with portal access. The ticket remains a single source of truth for all parties, with each party seeing only what’s appropriate to their role.
The key behavior worth noting: by default, unauthorized users see the field label but the value is withheld — replaced with a clear permission message. Admins can alternatively configure the field to display a masked value instead, which is useful when acknowledging that a value exists without revealing it. Either way, the actual data is never exposed to unauthorized users.
View permissions and edit permissions are separate controls
This is a detail that matters more than it initially seems.
It’s common to need asymmetric access on a field — someone should be able to see a value but not change it.
Example: a line manager reviewing a performance rating should be able to see the score, but only the HR business partner should be able to update it.
Example: a finance director should be able to view approved budget figures in a project, but only the project controller should be able to modify them.
With field-level security, view and edit permissions are configured independently. You’re not limited to “can access” or “cannot access”. You can define read-only access at the field level, giving the right people visibility without giving them control.
Dynamic rules and role-based configuration
Static field permissions (applied once, applied everywhere) handle most use cases. But some workflows need conditional logic.
Dynamic field rules allow visibility to change based on context: issue type, project, workflow status, or user role. For example:
- A Compensation Change field is visible only when the issue type is “HR Request” and the user belongs to the Compensation team.
- A Vendor Quote field is hidden until the issue transitions to the “Procurement Review” stage.
- A Legal Risk Level field is visible to Legal roles across all projects, but to project managers only within the Legal Operations project.
This kind of conditional configuration keeps field permissions aligned with how work actually flows, rather than requiring admins to maintain an exhaustive static ruleset for every edge case.
What stays intact when you add field-level security
This is where a lot of admins have reasonable concerns. Jira environments at any significant scale have automation rules, scheduled jobs, CSV imports, REST API integrations, and third-party apps that all interact with custom field data. Adding a new security layer raises a fair question: does this break anything?
With a properly implemented field-level security solution built on Atlassian Forge, which runs within Jira Cloud’s infrastructure rather than routing data to external systems, the answer is no. Specifically:
- Jira Automation rules that read or write secure fields continue to function. The automation engine operates under admin-level permissions and isn’t subject to the same field visibility rules as end users.
- CSV import and export handles secure fields as part of the standard field set. Bulk operations work as expected.
- REST API calls made by authorized integrations continue to return field data. Field-level permissions apply at the user level, not the API level, so programmatic workflows aren’t disrupted.
- Existing permission schemes remain in place. Field-level security adds a layer; it doesn’t replace or interfere with project or issue-level permissions already configured.
The result is that rolling out field-level security across a Jira instance doesn’t require a workflow redesign. Existing automations keep running. Existing integrations keep working. The change is additive, not disruptive.
Where to start
For most Jira administrators, the sensible starting point is identifying the fields that are already causing access control problems — the ones that prompted the duplicate projects, the offline spreadsheets, or the informal “don’t share this” conventions.
Those fields are the proof of concept.
Apply field-level view and edit permissions to them, verify the behavior across the relevant user groups and roles, and confirm that existing automation and integrations still function as expected. That validation process is straightforward and reversible.
Once the pattern is established, rolling field-level security out to additional fields, and delegating local configuration to project admins under global guardrails, scales without significantly increasing central admin overhead.
Secure Custom Fields for Jira adds field-level view and edit permissions to your Jira custom fields. No scripts, no duplicate projects, just the security layer Jira is missing.
