Convince My Boss
Project-scoped custom fields, with the option to restrict who can see or edit each field.
Native Jira custom fields are global and visible to anyone who can see the issue. That leaves two problems: the custom field list grows without limit because every team adds their own, and there is no way to put something sensitive on a ticket without showing it to everyone on the project.
Below are two emails you can copy, adjust and send.
Informal Email
Subject: A fix for our Jira custom field sprawl
Hi [Recipient’s Name],
Hope you’re doing well.
Two things about our Jira fields have been bothering me. First, the custom field list keeps growing because fields are global, so every team’s fields show up for everyone. Second, there are things we genuinely should not put on a ticket right now, like budget figures or anything personal, because everyone on the project can read them.
There is an app called Custom Fields for Projects from Redmoon Software that covers both:
- Fields scoped to a project. A field can exist only where it is actually used, which stops the global list becoming unusable.
- Per-field permissions. You can make a field readable or editable only by a specific group or role, and hidden from everyone else.
- Still searchable. Fields remain available in JQL for the people entitled to see them, so reporting is not affected.
More here: Custom Fields for Projects.
It would let us stop keeping some of this data in spreadsheets outside Jira.
Best,
[Your Name]
Formal Email
Subject: Recommendation to adopt Custom Fields for Projects for field-level access control in Jira
I hope this message finds you well.
I am writing to recommend Custom Fields for Projects from Redmoon Software to address two limitations in our current Jira configuration.
The first is field proliferation. Native Jira custom fields are global objects, so fields created for one team appear in the configuration of all others. This degrades performance, complicates screen configuration and makes governance of the field set difficult over time.
The second, and more significant, is that Jira has no concept of field-level permissions. Any user who can view an issue can view every field on it. This means commercially sensitive or personal data cannot safely be recorded against a ticket, and is instead held in spreadsheets and shared drives outside our controlled environment. That is a worse position from both a security and a records-management perspective.
Custom Fields for Projects addresses both:
- Project-scoped fields. Fields exist only where they are required, keeping the global configuration maintainable.
- Read and write permissions per field. A field can be restricted to a named group or role and hidden entirely from other users, independent of issue-level permissions.
- Data returns to a governed system. Sensitive attributes can be held in Jira under our existing access controls and audit trail, rather than in uncontrolled spreadsheets.
- JQL support retained. Authorized users can still search and report on the fields.
Further detail: Custom Fields for Projects.
For a security review, the app is Cloud only and is built Forge-native, so field configuration and values remain inside our own Atlassian Cloud site. Our Cloud Security Statement and Data Processing Agreement set out the detail.
I would suggest a trial scoped to one project holding sensitive data.
Best regards,
[Your Name]