Issue fields [Private preview]

[ebndev]

This discussion has moved. Head over to the public preview discussion for the latest updates, to request access, and to share feedback.

We are excited to introduce the private preview of issue fields, a new way for your teams to capture and manage structured data directly in GitHub issues. Issue fields make it easier to add, organize, and standardize important information across your repositories using custom fields such as priority, impact, effort, or any other category your team needs.

About issue fields

What are issue fields

Issue fields are customizable fields you can add to issues, enabling you to collect consistent metadata and details relevant to your workflow. Fields can be managed centrally at the organization level by organization admins, making it simple to apply the same structure across multiple repositories.

Why use issue fields

• Make issue tracking more organized by using standardized fields across repositories and projects
• Help your team quickly find and prioritize issues by field values
• Reduce manual work and data duplication when triaging or planning work
• Ensure important information like priority or dates is always visible and consistent

Project custom fields can still be used to track information relevant to a specific project.

How to request early access?

If you would like to try Issue fields in private preview, simply post a comment in this discussion with a brief description of your use case and the Organization you would like this enabled for. Our team will get back to you about getting you sorted with access.

Features included in the private preview ✅

Please expand this section to see the details:

Details

The following features are available as part of the private preview:

Managing issue fields

By default, three issue fields will be added to your Organization to help you get started: Priority, Start date and Target date. These fields are fully customizable and can be configured in your organization's settings in the "Issue fields" section under "Planning".

Organization admins can add up to 25 issue fields to the organization as a way of standardizing issue metadata collection.

Admins can choose from several field types to meet the organization's needs:

• single-select fields let you choose one option from a predefined list for quick categorization and standardization;
• text fields capture free-form text with automatic URL detection and clickable links;
• number fields accept numeric input, including decimals, to track values and measurements;
• date fields provide a date picker for easy selection, with the ability to clear the field or edit directly from the issue sidebar.

Pinning issue fields to types

Admins can associate issue fields with specific issue types, so only the most relevant fields appear when viewing or creating issues of that type. For instance, priority and severity can be linked to bugs, while impact and effort can be linked to epics. When a type is selected, the relevant fields automatically show up.

Applying issue fields to issues

Issue fields are prominently displayed when you view or create issues, making it easy to capture key information for each issue. Their appearance is consistent with system fields such as assignees, labels, and type, so they blend seamlessly into the issues sidebar.

Only users with triage and above roles are able to modify issue fields on the issue.

Search

Issue fields are fully integrated into issue search within repositories. You can filter, sort, and find issues based on issue field values, enabling new and powerful use cases for your team. For example, you can identify high-priority issues that are overdue by combining searches for priority and target date fields.

You can also search for issues by effort estimates, impact scores, owner, or any other issue field your team uses. This makes it easy to monitor progress, prioritize work, track deadlines, and surface actionable insights across all your repositories.

Projects support

Issue fields are fully integrated with projects across your organization, providing a seamless experience for managing and analyzing work. All issue fields are available for use in any project, and you can choose which fields to add to each project view based on your team's needs. This flexibility allows you to group, filter, and search issues by issue field values, making it easier to prioritize, track progress, and uncover insights.

You can tailor each project to your workflow by selecting the most relevant issue fields. Keep in mind that projects support up to 50 fields in total, and issue fields will count toward this limit.

Timeline events

Issue field updates are shown in the timeline, so viewers can see exactly what metadata changed, when it changed, and who made the change.

API support

Issue fields have full REST and GraphQL API support for managing settings and values across repositories. You can automate creation, updates, bulk edits, filtering, and sync with external tools.

REST:

• Issue field settings
• Issue field values

GraphQL: add header GraphQL-Features: issue_fields to fetch schema and run queries or mutations.

🆕 Webhooks and Actions:

• Issues webhook actions: field_added, field_removed
• Updating field values currently emits field_added with previous values in changes
• GitHub Actions trigger example:

on:
  issues:
    types:
      - field_added
      - field_removed

Migrating to issue fields

If you are using labels or project custom fields to track information, you can migrate to using issue fields by:

• Bulk editing values in a project table by copying/pasting or dragging and dropping values. Check out the documentation and the video below.
• Leveraging the REST or GraphQL API

Expand to see video

Screen.Recording.2025-11-21.at.4.38.58.PM.mov

Features not included in the private preview ❌

Please expand this section to see the details:

Details

There are several features that are not included in the private preview but might be added to the issue fields experience based on customer feedback and demand.

• Issue forms integration: It is not currently possible to embed issue fields directly into .yml issue forms
• Pull requests integration: Issue fields are limited to issues and cannot be applied to pull requests
• Mobile apps: Issue fields are not currently supported in GitHub iOS and Android applications.
• CLI support: Issue fields are not currently supported in CLI.

Recent improvements ✨

• Compact issue fields that are taking up 40-50% less vertical space in the sidebar
• Pin Issue fields to issues without a type
• See pinned field counts when selecting a Type

Feedback

We want to gather feedback, learn from your use cases, and continuously improve issue fields. Please share any feedback, issues, or suggestions you have. Your input helps us shape the future of issue fields and deliver features that best support your workflows.

[tellisnz]

hey team - how can we access this private preview? org:asvla

[labudis]

ok except going back to my use case - I can't have Status and there is no iteration field type for issue fields?

We are exploring a way to make status an org-wide construct - watch this space!

[beingminimal]

ok except going back to my use case - I can't have Status and there is no iteration field type for issue fields?

We are exploring a way to make status an org-wide construct - watch this space!

@labudis Any ETA or confirmation on this feature? And in case this will be coming then it will be part of issue fields or separate feature like issue type and issue field and issue status?

[labudis]

@beingminimal Unfortunately, I don't have an ETA for this but it will most likely be a separate feature which spans Issue fields and Projects, creating a new mechanism for managing status and keeping it in sync.

[beingminimal]

We would love to try and give feedback so please let us know when it's ready to test even if in alpha. Thanks

[uziyona]

Is there a plan to release an Iteration type to the available (limited) list of project custom fields?

[Eve-Yesodot]

How can I access the privet preview? Thanks! org:melta-team

[Eve-Yesodot]

Hello! We are using Github for both product managers, designers and the Dev teams.
With workflows and automation to plan the tasks, to show management roadmaps and planning, and to also monitor the dev teams.
Besides getting messy in the custom fields view because we have a lot (estimations vs real time, design fields, pm fields, dev fields) with the custom fields, some automation cant be triggered because custom fields don't trigger changes, but issue fields should, as far as they do today.
I'm rebuilding all of our work flow and views, and this will give me so much flexibility for this complex management.

[labudis]

Thank you for sharing! We have just enabled Issue fields for the melta-team organization. You can head to your Organization settings to start configuring them. Let us know if you have any feedback or need assistance.

[Eve-Yesodot]

First of all I wanted to thank you it is a game changer for me as I am the new product manager and I am rebuilding the board in the best of my ability and the issue fields are Game Changer due to the API and the events!!

I find myself that I have to put everything there so it will trigger, which is slightly besides the point but greatly helpfull!

For issue types I use epics and users stories and tasks and bugs and features and then I have different fields for each which is amazing and it helps me declutter a bit the project fields... but the one thing I miss most is the status update which I am now thinking of trying to integrate into the issue fields anyway instead of having a trigger that runs once in x time...
If you have any points of you on that subject that will help!!

other features I'd love to have

1. I would love to have a default value (forgort to write it in the docs review)
2. Grouping for all or.some of the fields to make it look more like the project custom fields to take up less space on the screen
3. General issue fields- even if an issue type was not selected...

Thanks again!! 🙏🏼🙏🏼

[labudis]

That's fantastic feedback, thank you @Eve-Yesodot!

1. That's an interesting suggestion - would you mind expanding on the use case there?

2. I have good news regarding "grouping" as we are already working on a much more compact "grouped" version of issue fields in the sidebar which will look and feel much more like Project fields.

3. We are also working on the ability to pin issue fields to issues without a type.

Please continue sharing feedback as it really helps us make the experience better :)

[Eve-Yesodot]

2 3 woohoo, amazing!🙏🏼🙏🏼👏🏼👏🏼 Any timeframe?
In 1 I meant lets say, as I use the issue fields for basically EVERYTHING 🫣 even status (cuz of the events) so if my issue type (out of Epic, User story, Task, Bug, feature suggestion) is user story or epic my default status will mostelly be let's say backlog.
Or, If it's a bug it goes to To Do...
Or let's say Phase  - Specs/Design/Dev.
If it's a user story, it's automatically sets Specs...
Just makes stuff slightly faster 😃

[beingminimal]

@ebndev @labudis We would be incredibly grateful if you could enable this feature in the following organisations. We’ve been eagerly waiting for this feature for the past six months. 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. We eagerly await your response. Thanks.

CodecycleLLP
MahakaalGH
StaytunedFoundation
StaytunedLAB
StaytunedLLP
Z1-Test
Z2-Test

[beingminimal]

I have also logged your feature requests for multi-select fields, text field validation options (mobile, email) as well as PRs support. At this point we can't provide any estimates as we are still in the early stages of gathering feedback and don't yet have a full picture of the emerging feedback themes.

Thanks a lot! I’m aware there won’t be an ETA, but I appreciate you’re listening. Thanks!

[beingminimal]

@labudis Any chance we can get access for this also in case its available? Please let us know. Thanks github/roadmap#1086

[labudis]

That feature is planned but not yet in development. When it is there will be a similar discussion post to request access and share feedback.

[beingminimal]

That feature is planned but not yet in development. When it is there will be a similar discussion post to request access and share feedback.

Eventually issue fields can help to achieve this milestones across repositories, so is this feature also intended to support this? should we use in that manner also or not advisable? Please help to conclude. Thanks

[labudis]

Technically you could use an issue field in the place of milestones to achieve what cross-repo milestones would solve.

Create a new issue field of type "single-select" to track versions/milestones. Create a list of milestones as single-select values. When working on issues, apply the appropriate value based on which milestone the issue relates to. You can then find issues related to a milestone by filtering results in the Issues Dashboard search. You can also create saved views for each milestone in the Issues Dashboard for quicker access.

By no means this is the perfect solution, but might be worth trying out in the meantime.

[beingminimal]

@labudis If we can improve date field with optional time as same as notion then it can be really helpful in many ways.

1. To manage release date and time for teams
2. To track social media marketing management with scheduling
3. To plan many thing with specific time also
4. Can be used as reminder also in github which can lift up so many workflows

See this docs for date and other fields of notion.
https://www.notion.com/help/database-properties#types-of-database-properties

Here is the image also

[labudis]

Thank you for the suggestion - I noted this for our team.

[beingminimal]

@labudis If we can gain an organisational-level insight into issues and PR, it would be incredibly beneficial for organisations and teams. For example, we already have action metrics at the organisational level, so similar insights could be applied to areas like cycle time and value stream analytics.

I’d love to hear your thoughts on this. Could you please raise an internal feature request? I’m eagerly awaiting your response. Thanks!

[beingminimal]

@labudis This is the feature we need. Thanks

[tlabeeuw]

@ebndev @labudis can we be added to the preview. Org perrystreetsofware. Use cases:

1. We use a lot of automations for projects and not being able to search / filter by issue fields in the graphql has been very limiting. Need to do hacks and are thus sometimes are rate limited.
2. Issue fields tied to types. Estimate should only be an issue type feature for example. This would greatly improve usability.
3. Editing project fields never showed in the timeline so was very hard to audit changes. Having these issue fields will help us understand issues history better.
4. We have been trying but not able to add a GitHub action when a project field changed. We had to do a crazy hack of having a mini serverless app which would listen to webhooks to trigger the GitHub action. Looks like this will finally allow us to run a GA directly whenever an issue fields changes.

[tlabeeuw]

[Feature Request] GraphQL Issues

@labudis Currently it looks like there is support for Issue.issueFieldValues(first: number) in GraphQL. But there doesn't seem to be a Issue.issueFieldValuesByName(name: string) like there was for ProjectV2Item.fieldValueByName(name: string). Will this be added to the GraphQL API? Without it, making a good typescript API is harder.

Also for the IssueFieldSingleSelectValue there does not seem to be an optionId or value that points to the ID of the selected option. There is only a name. Since the name can change but the ID is permanent it would make sense that it is added. It is also weird that it is the only one with no value, while all the others do.

[tlabeeuw]

@labudis More feature request:

[Feature Request] Issue Fields Grouping

• Group a set of Issue Fields together. E.g. we have a bunch of Review fields which are all nearly identical:
  • Design Review, QA Review, and Product Review
  • All of these have the same SingleSelectOptions: Accepted, Rejected, In progress, and Requested
• It would be great if they appeared as one box like how Project fields are all in one box in the Issue Viewing UI
• It would be great if they could be added to pinned as a group to an IssueType

[Feature Request] Issue Filed Types

• Custom Numeric
  • For estimating points etc, it is nice having custom sequence: Fibonacci (1, 2, 3, 5, 8, 13), Powers of 2 (2, 4, 8, 16), Linear (default: 1, 2, 3) etc
  • These more naturally reflect how points are assigned in teams.
  • Often these should have a min, max. What does a negative estimate or really large one even mean?
• Multi-select
  • Allow multiple options to be selected

[Feature Request] XP iterations

• As stated above it would be great to have proper XP (eXtreme Programming) iterations like Pivotal Tracker used to provide.

[tlabeeuw]

@labudis Sorry for the long thread. One small bug found:

[Bug] Editing a Pinned Issue Field in Table View

1. Pin an Issue Single Select Field called $IF_A$ to a specific Issue Type called $IT_{pinned}$ but not to $IT_{not pinned}$.
2. Go to a a table view of project.
3. Ensure that an $IF_A$ is one of the visible columns and there are multiple issues of both $IT_{pinned}$ and $IT_{not pinned}$ in the table.
4. Use the inline table dropdown editor to set the value on $IF_A$ for $IT_{pinned}$
5. Try to do the same on $IT_{not pinned}$:
   • It should not work
   • BUT it does. Opening the ticket now shows the field on the right hand field values incorrectly
   • You can change it again in this view if you want
   • Removing it and the reloading makes the field dissapper

[labudis]

Thanks for the thorough report and for outlining the steps in detail! Just to clarify how the system is intended to work:

Pinning a field (like “Priority”) to an issue type is designed as a convenience for surfacing relevant fields during issue creation and when viewing issues—it’s not a restriction. Pinned fields make it quicker to access what’s important for a given type, but don’t prevent users from adding or updating any field on any issue within Projects.

So, even if a field isn’t pinned for a specific issue type (like “Priority” for “Task”), users can still edit and populate it via the table view, API, or GraphQL. This is expected behavior and allows for flexibility in how fields are managed across issues.

If you notice the UI behaving inconsistently (such as fields briefly appearing/disappearing after edits and reloads), that may still be a bug in the way field visibility or refreshing is handled—but not in the ability to set fields themselves. Please let us know if you have any questions or see something that doesn’t align with this intended approach!

[labudis]

Also thank you for sharing these feature requests. We will keep those in consideration!

Hello everyone, happy new year!

Thank you all for trying out issue fields and for your valuable feedback and bug reports so far. We want to hear how things are going, so please take a few minutes to fill out this quick feedback survey. We will use the survey to inform and prioritize the next set of enhancements.

Feel free to share the survey with other users, both admins and those using issue fields in their day-to-day work. We appreciate perspectives from every role.

Thanks again for your collaboration!

[MasteraSnackin]

This Issue fields feature looks great! The ability to standardize metadata across repositories is exactly what teams need for better organization.

A few pieces of feedback:

1. Field types: The variety of field types (single-select, text, number, date) is comprehensive. Would love to see support for multi-select fields in the future for scenarios like tagging issues with multiple categories.

2. Type-specific pinning: The ability to pin fields to specific issue types is brilliant - it prevents clutter and keeps the interface clean.

3. API access: Having REST API endpoints for both settings and values is essential for automation. Great to see this included from the start.

4. Discovery: It would be helpful to have better discoverability of available fields when creating issues, perhaps with tooltips explaining what each field is for.

Overall, this is a solid foundation for structured issue management. Looking forward to seeing this move to GA!

[labudis]

Thank you, I'm glad you are enjoying it!

[pamarc]

Hi,
We'd be very interested by this preview as well (org:elmy-team), as we have many usecases where this would save us a lot of time. Is the preview free of charge btw?
Thanks!

[labudis]

Thanks, we've enabled Issue fields for your org now! Let us know how you get on.

[stealthgate]

Hello,
Been thinking about something like this in the past so that we would not have to jump to other tools when managing issues with specific requirements. We would like to try out the preview if it is still possible to apply.

Thanks!

[labudis]

Sure thing! Please send me your org slug and I will get this enabled for you.

[stealthgate]

org;panin-sekuritas

Thank you.

[labudis]

Enabled now!

[labudis]

Thank you for all the feedback so far! We would like for a few more organizations to test Issue fields so if you are keen, please post a comment in this discussion and we will get you sorted out with access.

[cocoich]

Hi team, can i get access for preview? org:tapweb

[labudis]

Enabled Issue fields for your org, please be sure to share any feedback or questions!

[labudis]

@cocoich how are you finding issue fields so far?

[cocoich]

@labudis well, We are not using for now.
After discussing with my boss, my team decided to use it in this year's github Projects. We expect it to be easier to manage than the projects field I used before.

[phifuh]

We would like to join and test the feature.
Org: SUNDKdk

[labudis]

Enabled Issue fields for your org, please be sure to share any feedback or questions!

[labudis]

Honey, we shrunk the Issue fields! 🍿

Issue fields in the sidebar now take 40 to 50 percent less vertical space. Many of you have asked for grouping or a more compact way to display fields making it look more like project custom fields and clearing up screen space. With this new dense, inline layout, it’s much quicker to scan your fields while keeping the sidebar tidy, even if you have a lot going on.

Before	After

Check it out and let us know what you think!

[mcturner3]

we would love to get early access to issue fields. we are currently using github projects to manage these types of fields and were about to start writing code on our side so that data would sync across projects. having these fields exist across projects similar to milestones and types would be a huge boost to our overall productivity and alignment.

our organization is CalcuQuote

[labudis]

thanks - granted access. Let us know what you think!

[gawertm]

please enable for org: giantswarm

[labudis]

thanks - granted access. Let us know what you think!

[jkgerig]

We would love to try this feature as well, thanks. org:Recidiviz

[labudis]

thanks - granted access. Let us know what you think!

[bschmidt-sd]

Would love to test this feature out. org: softdocs

[labudis]

At the moment it is not possible to create shared views of the Issues Dashboard as this page is designed to be user-specific.

A workaround might be to create a shared Project view which contains issues from multiple repositories, however, the suitability of this workaround highly depends on your setup. If you can share more details about what sort of views you would like to create and how your repos and Projects are structured I might be able to advise further.

[bschmidt-sd]

The views we would be looking for would be driven by a need to see global totals for Issues that meet certain criteria. As in, "how many Issues matching X criteria do we have across all of the repos and projects"?

At this point, we're still determining the most logical way to structure our projects, but it would likely be one project per Team and the various repositories might need to be used in multiple projects.

[labudis]

Yeah, I totally get the use case, although you are discovering a separate gap in our Issues experience rather than something specific to issue fields.

This is very much a workaround rather than an ideal solution but if you have less than 10 repos theoretically you could set up a Global Project with "auto-add" workflows enabled for every repo that you want to roll up. That way you would have one big project that has all of your issues and you could then visualise the desired views there.

[bschmidt-sd]

The workaround won't work in our scenario, but I appreciate you making the suggestion. Thanks for all of the help so far, and I'll continue to keep my questions/feedback focused specifically on trying out the Issue Fields preview.

[labudis]

No worries, I have logged your feedback for the broader team.

[mark-BannerSolutions]

We would love to try this feature. 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.
org: Banner-Solutions

[labudis]

thanks - granted access. Let us know what you think!

[Mats-Jakobsson]

Awesome! I would love to try this out:

org: indpro-blr

Thanks

[Mats-Jakobsson]

Thanks @labudis!!

[labudis]

✨ New improvement: field counts in the Type selector

When creating an issue, it has not been clear how issue types relate to the fields you are expected to fill out, which can lead to confusion and missed structured data. To address that, the Type picker now shows a “+N fields” badge next to each issue type, giving you instant visibility into how many pinned fields are associated with each option, with counts that update automatically as fields are pinned or unpinned.

[tlabeeuw]

This is great, but why is it limited to 10 pinned fields. This seems an arbitrarily low number?

[labudis]

Thanks for your feedback, it's mostly to ensure that the Issue sidebar doesn't explode with an endless wall of fields. What would be a more appropriate limit for your use cases?

[tlabeeuw]

Not much more! We are migrating several Issue Fields so temporarily need 12 right now but then will go down again. But I can imagine anywhere between 10-20 would be the max. Though surely this is up to the company if they want to have way to many fields on an issue.

[labudis]

Got it, we will explore potentially lifting this limit.

[fostimus]

Any way to order the fields? For example, we have a type 'Engineering', this is what they see:

I'd like 'Size' to be first, so they think about the estimate before assigning dates

[labudis]

Yes, you can order issue fields by going to Organization Settings > Planning > Issue types. Then pick your "Engineering" type and under Pinned issue fields, move the fields as desired by the drag handles. This order will then be respected in the Issues sidebar.

[linde-ibis]

I do this, then click save, but it doesn't save?

[labudis]

Ah it looks like a regression, reported as a bug and we will work to fix this.

[fostimus]

Can we color custom fields in projects view? Both dates look the same, coloring them would help people quickly:

[labudis]

Are you using a single-select field type for storing dates or is this a date field? You can choose colors for single-select options but not for dates since they are dynamic.

[fostimus]

It's a date field :/

[labudis]

got it! what sort of behaviour would you expect in terms of colours?

[fostimus]

I'd expect different colors for different date fields. In our set up, we have 3 relevant dates: "Start Date", "End Date" and "Targeted Release Date". Having each be different and consistent throughout the project would be awesome, so people can inherently understand what each date is without hovering over them.

Customizing the colors would/could be nice, but doesn't really matter IMO - just that the colors are different

[tal-shani]

Hi @labudis! GitHub Projects is a core part of our team's daily workflow, and this feature would be a significant enhancement to how we operate day to day. We'd love the opportunity to try it out!

Org: OneLayerHQ

[labudis]

Enabled access! let us know how you get on

[anders-jagard]

Hello @labudis,
Our organization with multiple teams and projects use github as our core part of the teams daily work. To be able to structure fields for issues it would be way much easier to enhance our operations.
We would be really happy to try this feature and share our feedback!

Org: hedinbil

[labudis]

Access granted!

[fostimus]

Kind of a gnarlier ask, but I think would be really powerful: can single-select options change based on the field type they are pinned to? Here's our example:

'Domain' pinned to 'Engineering' makes a ton of sense for these options, but the 'Domain' options for something like 'Marketing', 'Product', etc will be wildly different.

Separately, adding some more colors to use for single-select options would be sweet as well, but not as needed!

[labudis]

Thanks for sharing these examples, @fostimus! Having field options adapt based on type and conditional fields that appear contextually are both interesting ideas we've been thinking about. No commitments yet, but the scenarios you've described help us understand the need better. We'll keep this feedback in mind as we evolve issue fields.

[juncas2205-debug]

Kind of a gnarlier ask, but I think would be really powerful: can single-select options change based on the field type they are pinned to? Here's our example:

'Domain' pinned to 'Engineering' makes a ton of sense for these options, but the 'Domain' options for something like 'Marketing', 'Product', etc will be wildly different.

Separately, adding some more colors to use for single-select options would be sweet as well, but not as needed!

[fostimus]

Another gnarlier ask... conditional fields? In the above example, it'd be nice to have a conditional 'Feature Type' field - if 'Domain' is selected to be 'Feature', we'd like another Field to appear and prompt the user to enter another single select

[pedro-vbai]

Hi, @labudis. 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, 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).

[labudis]

Thank you to everyone who participated in the private preview! Your feedback helped us fix over 50 bugs and ship several improvements, including the compact layout, default effort field, and diacritics support.

We're excited to announce that issue fields are now expanding to public preview. We're gradually rolling out access to more organizations.

Head over to the new public preview discussion for full details on what's included, how to request access, and to share feedback.