Feature spotlight
In This Blog
Every project that adopts secured fields eventually generates its own steady trickle of permission requests: add this group, remove that user, adjust who can edit a field after a team reshuffle. When only the system admin can make those changes, each request becomes a ticket in someone else’s queue, and the admin becomes the approval bottleneck for dozens of teams who just want to manage their own project.
Secure Custom Fields for Jira lets a system admin turn on project-level configuration for any secured field. Once enabled, project admins can manage view and edit permissions for that field from their own project settings; but only for fields the system admin has explicitly opened up, and only within the context already applied to that field. The system admin sets the guardrail once; project admins operate inside it from then on.
Picture a platform owner at a company running secured fields across thirty projects. Every week brings a handful of permission-change requests: a new hire needs edit access, a departing contractor needs to be removed, each one routed through the platform owner because that’s the only person with the keys. After enabling project-level configuration for the relevant fields, those same requests get handled by the project admins who already own that context, same day, without a ticket to central IT.
This doesn’t loosen anything centrally; fields stay locked to whatever context the system admin applied, and project admins can only touch fields they’ve been explicitly given the option to manage. It just moves the day-to-day requests to the people already closest to them.
For the full setup steps for both system admins and project admins, see Global and project-level secure fields configuration.
Not using Secure Custom Fields for Jira yet? Start a 30-day free trial to see how permission delegation works for your org.