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. We're rolling out access gradually to select organizations. Not all organizations will have access immediately. If you'd like to be enabled sooner, request access in this discussion (see below).

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

"Our entire team is a power user of Notion and its databases, and we've been particularly eager for this feature after migrating 100% of our issue and task management to GitHub."
— beingminimal, StaytunedLLP

"This is the most perfect way to start my Monday. We have been needing this for ages to help separate out necessary information across engineering and marketing tasks."
— JenniferAssid, PlayCastDotIo

"We're exploring migrating from JIRA to GitHub, but a current blocker is not being able to store custom fields on issues where it can persist across different projects."
— mark-BannerSolutions, Banner Solutions

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

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

Note: Issue field visibility settings are not currently supported in Projects. Support is coming in a future update.

📝 Timeline tracking

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

⚡ API and automation

Full REST 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

🙋 How to request access

Want to try it? Post a comment in this discussion with your organization slug and a brief description of how you'd use it. We'll get back to you.

✨ 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
• 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 repository support

Issue fields now work on public repositories. Organization admins can set each field to Public (visible to everyone) or Organization only (visible to organization members and repository collaborators only). All fields default to Organization only, so nothing is exposed unless you choose to make it public.

Visibility is enforced in the issue sidebar, issue creator, timeline events, search, and APIs. Learn more about setting field visibility.

🔄 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]

Enabled for wavera! Check your org settings to get started. Let us know how it goes!

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

[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 change of multi select coming as a field type? I always missed that in projects and the only reason why we still use good all labels for some things (for example affected components) 😕

[labudis]

Enabled for arma-events! Check your org settings to get started. On multi-select, it's on our radar but not available yet.

[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

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

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

[labudis]

Thanks for the feedback! We chose the org-level approach because one of the biggest pain points we heard was inconsistency: every repo ends up with slightly different definitions of "priority" or "effort," making cross-repo reporting and triage really difficult.

Could you share more about your use case? Specifically, what makes it difficult to have a single set of fields across your organization? That context would be really helpful as we think about how the feature evolves.

[noraa-junker]

It's not having a single set of fields across my organization that's difficult. It's more that certain repositories have specific needs. For example I am a contributor and close collaborator in the Microsoft PowerToys project. This is an app that consists of many different modules and it would be useful to have an issue field "Module" where we can specify the module. But as this feature is only available on organization level (Microsoft) such a field will (very likely) not be introduced as it is of zero use for other repos.

Maybe a hybrid approach where both is possible could be an option?

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

[setchy]

Would love to try this for gitify-app 🙏 🚀

[setchy]

Thanks for enabling @labudis.

I've confirmed Issue Fields are enabled at my org level, but I'm strangely not seeing the fields in the right-hand pane for any existing issues.

Any tips?

[jamietanna]

Ah, we must have missed that in the original announcement - I didn't realise it would only work for private repos for now. Out of interest, why the split between public/private repo support?

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

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

[herbertroth]

Could we get access on the pimcore organization?

[labudis]

Enabled for pimcore! Let us know how it goes.

[Lulalaby]

Heya, that sounds super useful. We were already happy with the sub issues beta back then, but being able to do such fields would help insanely to prioritize our bugs / feature requests.
Could @Pycord-Development get access pretty please 💞

[labudis]

Pycord-Development is enabled! Fields should help with prioritizing bugs and feature requests.

[Lulalaby]

Thank you!

[labudis]

[muehz]

First thought after getting some initial fields set up is that it would be nice (and this is definitely just a nice to have) to be able to control the order in which the fields populate on issues via the same UI where you create the new fields. Maybe as a drag and drop similar to how the single select column reordering works.

Unless I'm missing a spot where I can configure that, it appears that it's currently in order of when it was created or more likely some sort of backend id.

[muehz]

First thought after getting some initial fields set up is that it would be nice (and this is definitely just a nice to have) to be able to control the order in which the fields populate on issues via the same UI where you create the new fields. Maybe as a drag and drop similar to how the single select column reordering works.

Unless I'm missing a spot where I can configure that, it appears that it's currently in order of when it was created or more likely some sort of backend id.

Disregard, I found the option under issue types based on one of your other responses. Thanks!

[Doc94]

Hi, its intended the all the fields for every org where i am are visible in issue filter?

Ex: Im Discord4J Admin ORG (Fields Enabled) and PaperMC Member ORG (Fields Enabled) and if try to filter in issues of PaperMC the field filter show from the two ORGs.

[Doc94]

Are you filtering in Issues Dashboard (/issues) or inside a repo in one of the orgs? If inside the Dashboad then this is intended because it's a global search that spans all issues available to you across GitHub.

The /issues from a repo ex: https://github.com/PaperMC/Paper/issues then feels confuse in the dashboard issue of a org/repo can filter by fields from another org

[labudis]

Hi @Doc94! On the filter question, fields from all your organizations showing up is expected behavior for now. Separately, we just shipped visibility settings for public repositories, so organization admins can now control which fields are visible to non-members. More details here.

[Doc94]

@labudis nice feature the visibility.
About the repo issue filter i hope can change because not make sense allow me filter in a repo fields they cannot even use because are from another org.
Thanks for the info 😊

[labudis]

@Doc94 upon a closer look I think it might be a bug since you are inside PaperMC org seeing fields for DiscordJ4. Previously I assumed you are on the Issues Dashboard. That's not right - we will investigate.

[labudis]

This has been fixed! The field filter in a repo's issue list should now only show fields from the org that owns the repo. Could you verify on your end that PaperMC issues no longer show Discord4J fields in the filter?

[TuomasTammi]

Hi! This is Screenful requesting access. We're eager to add support for global fields to our Analytics and Report product and need this enabled for development.

[labudis]

Access enabled for Screenful! Excited to see how you integrate issue fields into your analytics product. Let us know how it goes!

[waynemsmith]

Hi, can you enable Concurrent-Systems? We stopped using projects, due to exactly due to problem that this new feature resolves. Github kanban boards really coming along, so would like to try again.

[labudis]

Access enabled for Concurrent-Systems! Issue fields should address exactly the workflow gap you described. Hope this brings you back to a smoother experience.

[alystair]

Scoped labels in GitHub!? Is this reality?! 🤯
@labudis please provide pagedriver org access, scoped labels are the core reason we remained on GitLab. I'd test API integration as we made an importer in anticipation of something along these lines.

[alystair]

related to #16682

[labudis]

Access enabled for pagedriver! Fields are live on your org now.

[LeaVerou]

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.
It’s a little unfortunate that they can't be repo-specific, but oh well.
Q: Is there API access for these fields?

[labudis]

Yes! Issue fields have full REST and GraphQL API support. You can create/update/delete fields and set values programmatically. Docs: Adding and managing issue fields.

[nkolev92]

We'd love to get these enabled in the NuGet org. http://github.com/nuget/

We have been using labels for forever and this is a welcome change.

[labudis]

Access enabled for NuGet! Should be a nice upgrade from labels. Let us know how it goes!

[RickWinter]

I wish this was repo specific since org-wide its really hard to get anything added to my org.

[labudis]

Appreciate the feedback. Repo-level customization is something we've heard from several folks and we're tracking it. For now, fields are org-wide, but you can scope which fields appear on specific issue types if that helps narrow things down.

[probitcarwyn]

Can we have this on probit-io please. We have currently emulating this with namespaces labels that we also copy a subset of across all repos. This is exactly what we need. We also make use of Issue Types and Project Fields.

It would be nice to unify and possibly deprecate some of the old metadata options as this rolls out. Having all of labels, types, project fields and issue fields; each with their own scopes and limitations is a nightmare to explain to our diverse staff base.

[labudis]

Access enabled for probit-io! No more label namespace workarounds. Let us know how it goes!

[alystair]

Immediate feedback:

• Single select description length limitation should match custom project fields, they are pretty short at the moment.
• As it stands there is no way to display or filter issue fields within project listings nor repo issue lists, feels limited. Feels like a lot of duplication between this feature and custom project fields, maybe the two should be integrated in some way?
• Custom colors / hex options would be appreciated!

[labudis]

Thanks for the detailed feedback!

• Description length: The current limit is 100 characters for single-select option descriptions. We're open to increasing it. How many characters would work for your use case?
• Filtering in issue lists: You can filter by issue fields in repo issue lists and the issues dashboard using field.<name>:<value> syntax. Docs: Searching by field values.
• Issue fields in projects: You can add issue fields as columns in your project views, then filter, group, and sort by them. Just click the + column header and select your fields. Note that issue fields are not currently supported in public projects. Docs: About issue fields in projects.
• Custom colors/hex: Tracked, appreciate the suggestion.

[davesmits]

Would love to get this enabled on https://github.com/nxtsoftnl

[labudis]

Access enabled for nxtsoftnl! Let us know how it goes.

[patricksvgr]

This looks great! Can I get it for cti-factory? I'm desperately looking for ways to model some metadata in a more elegant way. 🙌

[labudis]

Access enabled for cti-factory! Fields should help clean up your metadata modeling. Let us know how it goes!

[labudis]

🌐 New: Issue fields now work on public repositories

Issue fields are no longer limited to private repos. Organizations with public repositories can now use issue fields with confidence, knowing that internal metadata stays internal.

When you enable issue fields on a public repository, organization admins control which fields are visible to external users and which are restricted to organization members and collaborators. Every field defaults to Organization only, so nothing is exposed unless you choose to make it public.

What you can do

• Set fields to Public so external contributors can see useful context like priority or severity when filing or triaging issues
• Keep fields Organization only to protect internal metadata like DRI, effort estimates, or strategic alignment from outside view
• Mix and match per field. Show priority publicly, keep staffing info private, all on the same issue

Where visibility is enforced

• Issue sidebar and issue creator
• Timeline events (organization-only field changes are hidden from non-members)
• Search suggestions and search results
• REST and GraphQL APIs

How to set it up

1. Go to your Organization settings > Planning > Issue fields
2. Click the menu icon next to the field you want to configure, then click Edit
3. Under Field Visibility > Permissions, choose who can see the field:

Setting	Who can see it
Organization only (default)	Organization members and repository collaborators with Read access
Public	Anyone viewing the issue

4. Click Save field

Quick example

Field	Visibility	Organization members	Repository collaborators	Public visitors
Priority	Public	✅	✅	✅
Severity	Public	✅	✅	✅
Team	Organization only	✅	✅	❌
Effort	Organization only	✅	✅	❌
Strategic Pillar	Organization only	✅	✅	❌

Current limitations

• Projects: Issue field visibility settings are not currently supported in Projects. This will be addressed in a future update.

If your organization only has private repositories, no action needed. All fields default to organization-only, so your data is already private.

📖 Documentation: Setting field visibility