Issue fields: Structured issue metadata

[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 generally available for all organizations on GitHub.com and GitHub Enterprise Cloud. 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
• 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
• Issues List and Dashboard - issue field values now display directly in the repository Issues List and Issues Dashboard. Up to 4 values shown after labels, with a +n indicator for more. Details
• Diacritics support - field names and option values now fully support diacritics and special characters
• 🎉 General availability - issue fields are now GA for all organizations on GitHub.com and GitHub Enterprise Cloud. 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.

[yonib05]

+1 for custom fields for pull requests

[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.

[JaffaKetchup]

In the issues list, the field values just appear as uncoloured tags without even the field name until hovered over - this is very confusing when using multiple fields with options having the same names. Some colouring (or maybe a coloured stripe to differentiate from a label?) or naming would be great.

[akenneth]

Thanks for your feedback @JaffaKetchup, i've passed it to the team ❤️

[cmeyer]

We compute Priority automatically with a RICE-style scoring algorithm, so it'd be great to have a way to lock the field from manual edits while still letting our automated script write to it — right now anyone with triage access can overwrite it by hand.

[amenity]

@cmeyer - I'm planning to set up something similar. Do you use a GitHub action to do those calculations based on the numeric value in custom fields?

[cmeyer]

We currently use a Python script, mostly built on top of gh api graphql. It's written manually but probably could be done these days using an LLM-assisted session as a GitHub action. It's internal and doesn't use RICE directly (no 'confidence' field, adds an 'audience' field, handles dependencies and issue age, etc.) so I can't share it, but there's nothing magic. The output goes to a GitHub project, custom Priority labels (soon to be the 'Priority' structured issue metadata instead of a label), and a generated HTML page that gets uploaded to an internal server. The only tricky bit is handling the paged output from gh api graphql.

[amenity]

Cool, I assume Python + GraphQL will be the route our devs go as well. 👍🏻

[labudis]

Issue fields are now generally available 🎉

Issue fields have moved from public preview to general availability for all GitHub organizations on Free, Team, Enterprise, and GitHub Enterprise Cloud with data residency plans.

Since public preview, more than 40,000 organizations have adopted issue fields. Here's what's new since the preview:

• Issue fields on the issues list: Field values now appear directly on the repository issues list
• Public project support: Issue fields work in public projects with visibility controls
• MCP integration: Issue fields are accessible through GitHub's MCP server for AI tools
• Internationalization: Field names support non-English characters
• Bug fixes and reliability improvements

Read the full changelog: https://github.blog/changelog/2026-07-02-issue-fields-are-now-generally-available/

Thank you to everyone who tested during preview and shared feedback here. Your input directly shaped what shipped. We'll continue iterating, so keep the feedback coming!

[oliverlalan]

@labudis Do you plan to make this feature available for personal accounts as well?

I think it could be very useful, especially with the rise of agentic workflows.

Thank you!

[broccolinisoup]

Hi @oliverlalan 👋🏻 Thanks for your question! It is in our radar and we are currently tracking feedback.

[fnesveda]

Hi, are there any plans to make issue fields available for pull requests too? This feature is something we've wanted for a looooong time, but without PR support it's virtually useless to us.

[aconsuegra]

Hi @fnesveda, thanks for your feedback! For now Issue fields are an Issues feature but we are monitoring requests for PR support so your feedback is noted!

[hadarziv-army]

Hi, are there any plans to support Issue Fields scoped to a single repository, rather than only at the organization level? Would love to know if this is on the roadmap at all?

[broccolinisoup]

Hi @hadarziv-army 👋🏻 Repo-level override is in our radar and something we are tracking feedback on. Thanks for highlighting it!

[amenity]

@broccolinisoup - do y'all define "repo-level override" as having an issue field configuration at the repo level that would apply across projects in that repo, regardless of org-level settings? So if they exist at all, org-level fields would disappear? Or does "override" mean that you can redefine an existing field at the repo level?

[lukas-w]

It'd be very helpful if we could assign field values to multiple selected issues at once in the issue list, just like you can do with labels, issue types or milestones. Is this on the roadmap?

Currently you'd have to either edit every single issue by hand or delegate/escalate this to an AI agent like the suggested migration tool. Both sound pretty cumbersome and seem like a waste of either time or computing power.

[aconsuegra]

Hey @lukas-w, thanks for your feedback! Bulk-actions on issue fields sounds like a very useful feature, indeed. We'll create an issue to keep track of it.

[amenity]

Not a complete fix, but you can edit many fields in bulk pretty quickly using the Projects table view. You drag the value up or down the column, as you would in a spreadsheet. I've found it super handy and intuitive.

It does get wonky when filtering by the field you want to update, e.g. you are looking for issues labeled "Team: Product" where your new custom "Team" field is blank so that you can set the value to "Product." The issues/rows disappear in real time as they're individually updated, so it's easy to drag the value further than you meant to.

[pdurbin]

Issue fields seem great but can "Field sum" be used with them?

Field sum is described at https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/customizing-the-board-layout#showing-the-sum-of-a-number-field and https://www.youtube.com/watch?v=rAxD42mAZhw&t=113s by @rileybroughten and here's a screenshot from that video:

Field sum works great for fields at the project level. I created an "Estimate" field at the project level. (just like in the video) and it shows up under "Field sum":

However, as you can see from the screenshot above, the following number "numTest" issue field I created at the org level doesn't appear under "Field sum":

Am I doing something wrong? Thanks!

[Rajulkr]

Hi, can priority be added to filter list in all Issues view ? This will help in bulk select and update.

[aconsuegra]

Thanks for reaching out @Rajulkr. It is already possible to search/filter for issue fields, like priority.

[Rajulkr]

searching is fine. We can bulk assign/update new priority field if that is added.

Since we were using a "Project priority" field under project, this will help to bulk update new field based on that custom field we had.

[Jack-McKalling]

Is it possible to render issue fields with their configured colour, in the timeline of the issue itself?
Originally posted here: https://github.com/orgs/community/discussions/9348#discussioncomment-17705549

I think it behaves as an overlooked consistency right now, when labels get their colours on the timeline but custom fields do not, eventhough they do have their own custom colour setting too.

[Advay17]

Apologies if my concerns have already been addressed, but I think it would be nice if there was some indication in the issues view of a repository what field pertains to which field value. For instance, instead of a high priority issue just being labeled "High", it was instead labeled "Priority: High". This just makes it easier to understand what these fields are communicating at a quick glance rather than needing to go into an issue and read through it. I understand that you can hover over the corresponding field value's label, however that's still not really ideal and differs from the behavior of traditional labels that instead show the description of the label (which would be more beneficial in understanding the value further).

[yshrsmz]

maybe related to repo-level orverride, but it would be great if we can read issue field ids with read:issues permission, as read:org is too much.

[yshrsmz]

never mind, I found Issue Fields permission in GitHub App configuration and it looks like enough

[dogadoga]

Is there (or are there plans for) an API to manage which Issue Fields are pinned to a given Issue Type ("pinned fields")?

I can read the relationship today via GraphQL:

{
  organization(login: "my-org") {
    issueTypes(first: 20) {
      nodes {
        name
        pinnedFields {
          ... on IssueFieldSingleSelect { id name }
          ... on IssueFieldMultiSelect { id name }
          ... on IssueFieldDate { id name }
          ... on IssueFieldNumber { id name }
          ... on IssueFieldText { id name }
        }
      }
    }
  }
}

But I couldn't find a way to write it. I checked via introspection and none of CreateIssueTypeInput, UpdateIssueTypeInput, CreateIssueFieldInput, or UpdateIssueFieldInput accept a parameter to associate an issue type with a field (or vice versa). Explicitly trying pinnedFieldIds on updateIssueType returns:

InputObject 'UpdateIssueTypeInput' doesn't accept argument 'pinnedFieldIds'

Grepping the full mutation list for anything pin-related only turns up pinIssue, pinIssueComment, and pinEnvironment — none related to issue type/field pinning. The only way I've found to set this is through the org settings UI (PATCH /organizations/{org}/settings/issue-types/{id} with pinned_issue_field_ids), which is a session-authenticated internal endpoint, not something usable from a PAT/GitHub App.

Use case: we're trying to fully template/automate initial org setup (issue types + issue fields) via REST API + a GitHub Action, and the pinning step is the one piece we currently have to do manually through the UI. Would love to see pinnedFieldIds (or similar) exposed on createIssueType/updateIssueType.

[guidezpl]

Strange that an issue field has one color on the issue page

but another on the issues page

[amenity]

The UI would look a lot cleaner if we could hide the default GHP "Status" custom field from the Project accordion in the issue sidebar.

As is, I've resorted to this mess:

[amenity]

& fwiw, here's a compilation of comments from others to whom this was, at one time, a painpoint.

• "The "Status" field is completely unused (and I actually wish I could remove it entirely). It would be useful to show the custom issue field here instead. Or perhaps nothing at all as the custom issue field is already displayed in the fields section above anyway." - @pd93
• "I would love the Status field to be a global field that can be used in project board automation. The current workaround of having something like "Status" and a global field called "Lifecycle" is unnecessary." - @phifuh
• "I need to synchronize the status of the issue between projects (if they appear in multiple projects). So I would appreciate it if the status were defined at the organization level, and I could use it as a single source of truth in the project, as well as issues. Otherwise, I'm thinking of having a status label for now." - @YuichiHamamoto
• "To me, it makes sense to have Status as a locked issue field, rather than a locked project field. In my experience, issues have a universal status, rather than different statuses that apply to individual projects." - @LaurenceSignaloid

Has anyone figured out an elegant workaround for this?

@broccolinisoup @aconsuegra - where does this sit on your radar these days?