Issue fields: Structured issue metadata is in public preview

[ebndev]

issue.fields.public.preview.mp4

If you've ever used labels like priority/p0, severity/high, or team/frontend to track structured data in issues, you know the pain: no types, no validation, no consistency across repositories, and no way to report on them. Issue fields fix all of that. Define typed, org-wide fields once and they show up on every issue, in every repository, automatically. Search by them, report on them, automate with them.

Issue fields are now in public preview for all organizations on GitHub.com and GitHub Enterprise Cloud. No invite or waitlist needed. Manage them in your org settings under Settings > Planning > Issue fields. Changelog

We've been running a private preview since November 2025 and have been iterating based on feedback. Here's what teams are saying:

"This is fantastic. Probably my top GitHub pain point. I had even drafted a custom app in the past to manage these labels, which I'd be happy to ditch."
— LeaVerou

"We've completely abandoned Atlassian products and moved our whole planning/backlog/iteration work into GitHub, and not having the fields has been a large pain point."
— syntaqx, aspyn-io

"Scoped labels in GitHub!? Is this reality?! 🤯 Scoped labels are the core reason we remained on GitLab."
— alystair, pagedriver

📦 What you get out of the box

When issue fields are enabled for your organization, you get a ready-to-use setup.

Default fields

Every organization starts with four fields:

Field	Type	Values
Priority	Single-select	Urgent, High, Medium, Low
Effort	Single-select	High, Medium, Low
Start date	Date	-
Target date	Date	-

Pinned to the right issue types by default

Field	No type	Bug	Task	Feature
Priority	x	x	x	x
Effort		x	x	x
Start date				x
Target date				x

Create a bug and you'll see Priority and Effort right there in the sidebar. Create a feature and you get all four. No setup, no config, just works.

🔧 Make it your own

The defaults are a starting point. Organization admins can customize everything.

Add new fields

You can add up to 25 fields per organization. Four field types to choose from:

• Single-select - pick from a predefined list (e.g., Severity, Impact, Team)
• Text - free-form text with auto-detected URLs (e.g., DRI, Notes)
• Number - numeric values including decimals (e.g., Story points, Staffing)
• Date - date picker (e.g., Ship date, Review date)

Pin fields to issue types

Decide which fields show up for each type. Pin severity to bugs, impact to features, your custom types, or whatever combination works for your team. You can also pin fields to issues that don't have a type.

Customize options and colors

Rename fields, add descriptions, create and reorder options, pick colors. Changes apply across the entire org instantly.

Control visibility on public repos

Issue fields work on public repositories. Set each field to Public (visible to everyone) or Organization only (visible to org members and collaborators only). All fields default to Organization only, so nothing is exposed unless you choose. Learn more.

🔍 Search by field values

Some things you can do:

• Find all urgent issues past their target date
• Surface high-effort features that haven't been started
• Filter by DRI to see someone's workload

📊 Works with Projects

Add any issue field as a column in your project views, then group, filter, and slice by field values. Unlike project custom fields, issue fields travel with the issue across projects and views, so your data stays consistent everywhere.

Issue fields count toward the 50-field limit per project.

Issue fields are fully supported in public and internal Projects. Field visibility settings are respected: only fields set to Public appear in public projects, while Organization only fields are automatically excluded.

📝 Timeline tracking

Every field change shows up in the issue timeline with what changed, when, and who did it.

⚡ API and automation

Full REST API and GraphQL API support for both field settings (create, update, delete fields) and field values (get, set, clear values on issues). Automate field management, do bulk updates, filter by fields, and sync with external tools.

Webhook events (field_added, field_removed) let you trigger GitHub Actions on field changes:

on:
  issues:
    types:
      - field_added
      - field_removed

✨ What's new since private preview

Since the private preview, we've fixed over 50 bugs and shipped several improvements:

• Effort field - added as a fourth default alongside Priority, Start date, and Target date
• Public repository support - issue fields now work on public repos with visibility controls. Set each field to Public or Organization only. Details
• REST API parity - set field values when creating issues via the REST API, matching existing GraphQL support
• Migration Copilot skill - bulk-copy values from labels or project fields into org-level issue fields. Details
• Compact layout - fields use 40-50% less space in the sidebar
• Pin fields to no-type issues - fields can show on issues without a type
• Diacritics support - field names support accents, umlauts, and other special characters
• Public project support - issue fields now work in public and internal Projects, with visibility settings fully respected. Only fields set to Public appear in public projects; Organization only fields are automatically excluded
• MCP remote server support - list, filter, set, and clear issue field values via the GitHub MCP remote server (https://api.githubcopilot.com/mcp/). Works with any MCP-compatible client. Details

🔄 Migration tool

Already using labels or project fields for structured data? We built a Copilot skill to help you migrate. It bulk-copies values from labels or project fields into your new org-level issue fields.

💬 Feedback

We'd love to hear from you! Share feedback, report issues, or suggest ideas in this discussion. Your input directly shapes what we build next.

To learn more, check out the issue fields documentation.

[kutsan]

We use issue-only repositories internally to track tasks and manage everything through GitHub Projects. A single repository can have issues for multiple platforms and teams. This feature would help us streamline our workflow, so I'd like to request it be enabled for the @wavera org.

[labudis]

@rodneyjoyce you should now have access, could you please confirm?

[rodneyjoyce]

Yes, thank you - it is working very well

[albertoblue87-netizen]

Estoy tratando de todavía implementar espérenme el paso . 🙏🏻

[sapidin1]

Good luck

[alexanderniebuhr]

We use labels to track over 500 issues for our innovation lab, would be great to get access to the preview @frickegroup

[labudis]

Enabled for frickegroup! Head to your org settings to configure fields. Would love to hear how it goes!

[alexanderniebuhr]

@labudis quick initial feedback. So far it looks quite promising, however sometimes we do add pull requests to our projects board and give them a priority. In the past it worked with project priority field, but there doesn't seem any option to set the new global priority field on pull requests. do you have any idea or insight?

[labudis]

For now Issue fields are an Issues feature so you will not be able to apply Issue fields to PRs but we are monitoring requests for PR support so your feedback is noted!

[aaronsteers]

@labudis and @alexanderniebuhr

+1 for support for custom fields for pull requests. One idea to implement would be to align "pull request" as an "issue type" - so that fields could have an affinity to be leveraged in pull requests (or not) in the same way that fields might be applicable to bugs-type issues or not.

[MrLesk]

Would like to explore storing Backlog.md's tasks directly as Github issues. This new feature would drastically simplify the integration
https://github.com/MrLesk/Backlog.md

[labudis]

Thanks for the interest! Issue fields are an organization-level feature, so they need to be enabled on a GitHub organization (not a personal account). Do you have an organization where you'd like us to enable it?

[DerZade]

Currently at @arma-events we use fields in projects and issue type, but the integration of issues and projects always lacked a bit imo. Atm we move all isses to a single project to allow setting some metadata like size, status etc. Would love to try out the more issue-centered approach.

Also: Is there any chance of multi select coming as a field type? I always missed that in projects and the only reason why we still use good old labels for some things (for example affected components) 😕

[setchy]

+1 for multi-select.

I'd like to migrate from custom labels to Issue Fields for Platform: [macOS, Windows, Linux]

[msune]

+1 for multi-select

[JuusoCajan]

+1 for multi-select. Has there been any progress with this? We'd like to use this for platforms as well.

[mitch-ortenburg]

+1 for Multi-Select!

[amenity]

+1 (as if y'all don't know 🙈) for multi-select. We're also going to continue using Workgroup:[division name] labels while we wait.

[kutsan]

It would be really nice if these and other fields (like type, milestone etc.) could be marked as required at the time of issue creation.

[labudis]

Required fields are on our horizon! Can you share a bit more about your use case? Understanding which fields you'd want to enforce and in what scenarios would be really helpful.

[kutsan]

@labudis Sorry for my extremely late answer. Generally, we want to make fields required to ensure integrity across issues. For example, issues opened by product management should have a minimum set of fields they must fill in. As an example, in our project we link every issue to a milestone, and there shouldn't be any issue without a milestone. Required fields would ensure this.

[mitch-ortenburg]

Required fields would be excellent for the exact same reason as @kutsan articulated previously. It's honestly something that, migrating over 6 months ago from Azure DevOps, I thought would already be natively present here.

[fnesveda]

This looks great! Can we get it for the apify organization? 🙏

[labudis]

Access has been enabled for apify. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[pedro-vbai]

We'd love to try these! Org is voicebrain. We're just setting up project management in github and want to use Projects as a flexible, light-weight, de-centralized way to track, manage, and visualize groups of related issues. But we need certain metadata to be consistent across new Projects, such as priority, estimates, resolution reason, etc. It'd be awesome to have org-level metadata fields like these to handle this, since some of these fields won't work well as labels (and would make our labels much too crowded). Thank you!

[labudis]

Access has been enabled for voicebrain. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[labudis]

Hi @pedro-vbai! Just a heads up, we also just shipped visibility settings so issue fields now work on public repositories too. Organization admins can choose which fields are visible publicly and which stay internal. Details here.

[h-m-f-t]

These look like great additions! We'd love to try them out @cisagov.

We have some fields (priority, effort) in Project metadata that really make more sense on the issue. Structured issue metadata is likely the nudge we'd need to start actually using Issue types.

[labudis]

Access has been enabled for cisagov. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[amenity]

🎉 Congrats, @labudis! You've done a fantastic job moving this forward and collecting such thorough feedback.
I assume that since @cityofaustin already has private preview access, we don't need anything switched on, but if not, please hook us up. 🙏🏻

Are y'all still thinking that you'll be opening these to public repos by next week? We're in a bit of a holding pattern since migrating from Zenhub and are very eager to get our product ops reporting up and running again.

[labudis]

Access has been enabled for cityofaustin. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[labudis]

Great news, @amenity! Issue fields now work on public repositories. Organization admins can control which fields are visible to everyone and which are restricted to organization members. Details in this comment. No more holding pattern!

[nicosammito]

We’d love to request access for the @code0-tech organization. We are currently in the process of building our community and want to ensure a structured workflow from the start. Moving away from label-based workarounds to typed, org-wide metadata like Priority and Effort would be a huge help in streamlining our issue management and reporting.

[nicosammito]

Amazing, thank you very much 🔥

[labudis]

Access has been enabled for code0-tech. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[chriswnek]

As the PM for the argc org, a consistent way to add priority and effort across our repos would be amazing.

[labudis]

Thanks for the interest! I wasn't able to find an organization matching argc. Note that issue fields is only available to GitHub Organizations, not personal accounts. Could you double-check the org slug and share it here? Happy to get you set up.

[chriswnek]

@labudis Sorry, had a typo in there, it's agrc

[chriswnek]

@labudis Just bumping up this request for agrc so it doesn't get lost. Thanks!

[labudis]

thanks, I added this to be enabled tomorrow!

[labudis]

Access enabled for agrc! Priority and effort fields are now live across your repos. Enjoy!

[noraa-junker]

I personally do not understand why these are bound to an organization and not per repo. In an organization with many different repos the need for different issue fields can be very big. Please make this bound to repos and not organizations!

[kwin]

Same need for large organizations like apache, where each repo is run by a different team usually with different demands for issue fields

[kutsan]

Completely agree with @noraa-junker, we also need this for the same reason.

[phifuh]

When reading this i thought about the 2 most upvoted feature requests inside the repo discussion:

https://github.com/orgs/community/discussions/4174
https://github.com/orgs/community/discussions/41348

Grouping repos could work very well with "global" issue fields

[NoNameProvided]

We also have a few repo-specific fields, such as the module field, which we currently track using labels. It would be useful for us to support both global and repo-specific fields.

A setup similar to GitHub Actions secrets could work well, where values can be defined at the organization level or per repository.

[setchy]

Would love to try this for gitify-app 🙏 🚀

[labudis]

Access has been enabled for gitify-app. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[labudis]

Hey @setchy! Issue fields now work on public repositories. Your organization admin can control which fields are visible publicly and which stay internal. Details here. You should be unblocked now!

[setchy]

Awesome, thanks @labudis.

Is there plans on the roadmap to support filtering repository Issue Lists using the Issue Fields? ie: show me all Priority: High issues

[labudis]

Yes, this is on our radar. In the meantime you can filter by typing "Priority" in your search bar and picking "High" from the dropdown.

[waterplea]

@labudis any forecast as to when those would appear in the UI so we don't have to manually type it? I love this new feature, it would be great to drop custom labels in favor of built-in fields, lack of UI is hindering.

[ViewFromTheBox]

This looks great! Would love to use it with ArtisanPack-UI!

[ViewFromTheBox]

@labudis It's been a day and I missed the part about an explanation. Right now I have a lot of labels that start with Priority::, Type::, Status::, Area::, etc., and being able to use this would be a much better way for us to organize those instead of using an absolute ton of labels.

[labudis]

Access has been enabled for ArtisanPack-UI. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[labudis]

Hi @ViewFromTheBox! Just shipped public repo support for issue fields. You can now use them on public repositories with visibility controls. More info here.

[dodyg]

Please enable them for silverkeytech. We keep track of everything using GitHub Issues.

[labudis]

Enabled for silverkeytech! Let us know how it goes.

[tay1orjones]

Will issue fields be supported on draft issues?

[labudis]

Draft issues in projects don't support issue fields today since they aren't full issues yet. Once a draft is converted to an issue, fields become available.

[roshhellwett]

The org-wide definition is the right call. Defining it once and having it show up everywhere automatically is exactly how it should work. We had an internal tool doing something similar just to keep label schemas in sync.
A few things I'm curious about / hoping gets addressed...

• PR support — a lot of triage workflows live on PRs too, would be great to not have a split system

• Field ordering without pinning — the current workaround of needing to pin to an issue type just to control order is a bit clunky

• Org admin requirement — for larger orgs this creates a bottleneck, team-level or repo-level field management would go a long way

The MCP integration is a nice touch though, filtering and updating fields via AI agents is going to save a lot of project management overhead.

[labudis]

Thanks for the thoughtful feedback. PR support and field ordering without requiring pinning are both on our radar. On the admin bottleneck, we've heard this from others too; noted. Glad the MCP integration is landing well.

[TheBoneJarmer]

I just noticed this today and I absolutely love it! This is something I am used to work with in Azure DevOps as well and it really makes organizing issues for sprints so much easier now. Thanks a lot guys and keep up the good work!!

[amenity]

🐛 ❓ Most of our team's day-to-day issues are either currently missing an issue type or are assigned the Task issue type. We have not pinned any (org-level) issue fields to that type to prevent confusion with project fields for the time being.

However, issue fields that aren't assigned to Task are still appearing in the sidebar on Task issue types.

[amenity]

And now... we're good — not seeing non-pinned fields. 🙃

I'm leaving this posted because it's the second time it happened, and I verified with multiple co-workers that they saw the same thing. So maybe some sort of caching issue? 🤷🏻‍♀️

[labudis]

Hi @amenity, fields are visible in the sidebar under two conditions:

• they are pinned
• they have a value set

In the screenshot above I can see that DTS Status has a set value hence why it appears on that issue.

[amenity]

@labudis - you're absolutely right. Turns out someone added the issue fields to a project and populated them from within the project board. Thanks!

[smileBeda]

A metadata by which cannot be searched, or filtered. 👍

[labudis]

Could you share more about what you're trying to do? Filtering by field values is supported in the Issues Dashboard, the repo Issues list, and in project views today. Happy to help if you're running into something specific.

[ialko007]

Not a fan of it. I prefer basic per-project fields more because, as a student, I need to create every project repository under our university organization, and therefore I can't hide or edit fields that we have under our organization. My university haven't touched the issue fields yet, having just the default ones there (Priority, Effort, Start date, Target date). But I want to create my own "Priority" fields, with my own select options! And with that issue field, the "Priority" field is now duplicated: per-project, and per-organization.

I can't hide it? I can't disable it for my repository? I can't set up my own per-repo issue fields? I am only in power to edit my project fields, so this unexpected addition of issue metadata is rather bloating Github's UI up, than lets me organize my university project work.

Also, kinda contradicts GitHub Project templates, that were already adding Priority, Start date and Target date fields to the project once you create it.

[labudis]

We hear you. Today, issue fields are managed at the org level and individual members can't hide or override them per-repo. For your case, you could ask your university org admin to delete the default fields they're not using. We're aware that the overlap with project field defaults creates confusion, especially when you don't control the org settings.

[aungkyamoe2908-a11y]

issue.fields.public.preview.mp4
If you've ever used labels like priority/p0, severity/high, or team/frontend to track structured data in issues, you know the pain: no types, no validation, no consistency across repositories, and no way to report on them. Issue fields fix all of that. Define typed, org-wide fields once and they show up on every issue, in every repository, automatically. Search by them, report on them, automate with them.

Issue fields are now in public preview for all organizations on GitHub.com and GitHub Enterprise Cloud. No invite or waitlist needed. Manage them in your org settings under Settings > Planning > Issue fields. Changelog

We've been running a private preview since November 2025 and have been iterating based on feedback. Here's what teams are saying:

"This is fantastic. Probably my top GitHub pain point. I had even drafted a custom app in the past to manage these labels, which I'd be happy to ditch."
— LeaVerou

"We've completely abandoned Atlassian products and moved our whole planning/backlog/iteration work into GitHub, and not having the fields has been a large pain point."
— syntaqx, aspyn-io

"Scoped labels in GitHub!? Is this reality?! 🤯 Scoped labels are the core reason we remained on GitLab."
— alystair, pagedriver

📦 What you get out of the box

When issue fields are enabled for your organization, you get a ready-to-use setup.

Default fields

Every organization starts with four fields:

Field Type Values
Priority Single-select Urgent, High, Medium, Low
Effort Single-select High, Medium, Low
Start date Date -
Target date Date -

Pinned to the right issue types by default

Field No type Bug Task Feature
Priority x x x x
Effort x x x
Start date x
Target date x
Create a bug and you'll see Priority and Effort right there in the sidebar. Create a feature and you get all four. No setup, no config, just works.

🔧 Make it your own

🔍 Search by field values

📊 Works with Projects

📝 Timeline tracking

⚡ API and automation

✨ What's new since private preview

🔄 Migration tool

💬 Feedback

C

[ManHatos]

It will be extremely useful to be able to quickly view fields from the "Issues" tab instead of having to open each issue individually.
At the very least, they should be visible when hovering over issues (on desktop) for the quick view/preview.

Having both options would be useful, really.

[jasell]

I just wish to bump the need for having GitHub project support for these new fields.
You also need a way to differentiate between GitHub-fields and project-fields, as both could have the same name.

[swarley]

I think that this is a good feature, especially timeline tracking since we have issues with process level observability with project fields. However the flow we want to observe the most happens on PRs so it's a bit of a nonstarter on our end. Voicing support for extending this to PRs as well