Custom Fields for Project Managers

Project-scoped fields and field-level security for PMs - so structured project data lives on Jira issues without polluting the global field schema.

Product: Custom Fields Audience: Project Managers
Get Custom Fields on the Marketplace ↗

Why this matters for project managers

Project managers live and die by structured data. Status, RAG, sponsor, steering-committee approval, budget variance, dependency state - the discipline of PM is, in large part, the discipline of keeping that data current. Jira is the natural home for it, because the work itself lives in Jira.

Native Jira pushes back, though. Adding a PM-specific custom field bleeds the field into unrelated projects. Field contexts are global by reference. Field-level security doesn’t exist. PMs end up choosing between three bad options: lobby the admin to add fields that affect the whole site, reuse fields that don’t quite fit, or maintain the data outside Jira in a spreadsheet that drifts.

Custom Fields gives PMs a fourth option: project-scoped fields with field-level security. The PMO project gets the fields the PMO needs. Engineering screens stay clean. Sensitive fields stay restricted. The global schema stays disciplined. PMs get the structured data their reporting depends on without the cross-project pollution that makes Jira admins say no.

Where this fits in the PM workflow

  1. Project setup - PM-specific fields go on the project at kickoff, scoped to that project, without admin negotiation about the global field schema.
  2. Weekly cadence - sponsor, RAG, and steering-committee status update on a single field set; exports drop straight into the weekly report.
  3. Closeout - structured field data exports cleanly to the PMO archive. No retro-extraction from comment threads.

What “good” looks like

Good is the PM adding ‘Steering committee status’ to a project on Monday and pulling it into a steering-committee report on Friday, without an admin ticket and without polluting any other project. Custom Fields exists so PMs can run their projects on Jira without fighting the global field schema.

What project managers are dealing with today

  • Adding a custom field in native Jira often makes it visible on every project's screens - polluting unrelated schemas with PM-specific fields.
  • Jira's global custom-field model means PM-only fields like 'Steering committee status' bleed into engineering, design and QA screens.
  • Field-context configuration in native Jira is shared across projects, making per-project tailoring fragile.
  • Field-level security is not native - sensitive PM fields like 'Executive sponsor concerns' are visible to everyone with issue access.
  • Reporting at the project level requires PMs to either lobby the admin for new global fields or reuse fields that don't fit.
  • Project closeout requires field exports that include PM-specific metadata - which often doesn't exist in a structured form.

How Custom Fields helps project managers

Per-project field scoping

Define fields that live on a single project (or a small set) without exposing them to the wider Jira site. PM-only fields stay in the PM project.

Field-level security

Restrict who can view or edit specific fields - so 'Executive sponsor concerns' or 'Budget variance' can be PM-only without restricting the issue itself.

Structured project metadata

Add PM-relevant fields - sponsor, steering-committee status, budget variance, risk RAG - to project issues in a structured form that reports cleanly.

Closeout-ready exports

Export the project's structured field data at closeout for the steering committee or PMO. No re-extraction from comments and descriptions.

Schema discipline

The global Jira field schema stays clean. PMs get the fields they need on their projects; admins keep the site-wide schema manageable.

Use cases

  1. PMO steering-committee fields. PMs add 'Steering committee status,' 'Sponsor approval date,' and 'Budget variance %' to project tickets. Fields exist only on PMO projects; engineering screens stay clean.
  2. Executive-sponsor restricted notes. PM captures executive-sponsor concerns on the project epic in a field visible only to the PMO. The ticket remains broadly visible; the sensitive field is not.
  3. Project closeout dashboard. At closeout, PM exports the project's structured field data - status, RAG, variance, sponsor approvals - directly to a steering-committee report.
  4. Per-project risk register. Each project has its own risk-register field structure. Custom Fields scopes the fields to that project so other PMO projects can have their own configurations.

Common questions from project managers

Why not just use Jira's built-in custom fields?

Native Jira custom fields are globally defined and contexts are shared by reference. Adding a PM-specific field for one project often makes it visible across the site, and field-context tailoring is fragile. Custom Fields scopes fields to the projects that need them, keeps the global schema clean, and adds field-level security that native Jira does not have.

Can we restrict who sees a custom field?

Yes - field-level security is the main differentiator. Permission can be set per field, by user, group, or project role. The field is hidden from users who don't have view permission - they don't see it on the screen, in JQL results, or in exports. The surrounding ticket remains visible normally.

How does this help with project reporting?

Project reporting depends on structured data on the right tickets. Custom Fields lets PMs add the fields they need - sponsor, RAG, budget variance, steering-committee status - to project issues in a structured form. Reports and exports then have real data to draw on, rather than depending on parsing free-text comments and descriptions.

Will adding these fields slow Jira down?

No. Custom Fields stores values in its own tables and indexes them efficiently. There's no measurable impact on Jira's search or issue-view performance. Because the fields are project-scoped, they don't appear on screens or in field-context configurations across the wider site - which actually reduces Jira admin load over time.

Try Custom Fields for your team

Custom Fields works for project managers on Jira Cloud and Data Center. Install from the Atlassian Marketplace, or read the main Custom Fields page for the full feature list.

Try Custom Fields on the Atlassian Marketplace ↗   See the full Custom Fields overview →

Also built for

Custom Fields solves a different problem for each team: