[Private preview] Issue fields

[ebndev]

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

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!

[linde-ibis]

I just saw the Fields section show up on the right-hand side of issues, but I don't have access to add fields in my org Planning settings section. Can you please enable for org:IBISTechGroup? I'm sooo excited about this feature, I would just ask to add a multi-select type field too please and thank youuuu!!!

[shenanigansd]

We'd love to try this too! org:impressdesigns

[ram-ektar]

We'd like to try as well, please enable it for org:ektar-tech

[firsou]

Hey, would love to try this as we have different projects we need to keep consistency for different issue types.

Please enable it for org:acp-io

Thank you

[mfsbo]

please enable it for org:bookingonline

[acolchagoff]

@labudis We need this as well, I'm pushing for adoption of github projects and the lack of org-level custom issue fields is really making the transition difficult.

Please enable us! org:RivetWork

thank you!

[shenanigansd]

Please enable this for org:untw-vnd

[gstokkink]

Please enable this for the bookingexperts organization, would love to participate.

[amenity]

We're excited to try this out. We're just migrating from Zenhub and in the process of configuring projects for all our teams, so it's perfect timing.

✨cityofaustin✨

[amenity]

@labudis -tysm for the quick reply! Moving this here so I can ⌘+f find it without expanding every accordion. :P

...we are targeting to release public repo support mid-March. Would you be looking to create Projects visible to the public as well?

We anticipate that all our Projects will be public. In fact, this was a major motivation in our decision to migrate from Zenhub to Projects. We also use the GitHub (and, for the time being, Zenhub) API to drive our website.

That said, we were planning to configure custom fields in all the repos individually before I turned up this feature last week, and we've already migrated Zenhub values into custom fields for a couple Projects. That code is already written, but since custom fields need to be called via the project id, we'll have to modify the script for each project, whether or not they're configured identically. Still, that's not as big a lift for our devs, so nbd. This would just really help (PM) me standardizing the configurations across Projects. I wish we'd used templates from the beginning.

tl;dr we look forward to mid-March, but this isn't a blocker. Do let us know if you need guinea pigs for an earlier public repo roll-out! Promise that we'll give helpful, patient feedback. ;)

[labudis]

New feature: Pin issue fields to issues without a type

We have added the ability to pin issue fields to issues that do not have a type selected. This helps you capture critical metadata even when an issue type has not been chosen yet, so issues stay actionable from the moment they are created.

For example, you can pin a “Severity” or “Customer impact” field so that when someone files a quick bug without selecting an issue type, the team can still triage it immediately and route it to the right owners.

In addition, previously, issue field pinning could only be managed from the type editor. Now, you can also manage field pinning from the field editor, which lets you see how a field relates to different issue types from a single, field-centric perspective. This makes it easier to spot gaps and keep pinning consistent across types.

Pinning.issue.fields.to.typeless.issues.mp4

[hadarziv-army]

Hi👋🏻

I see that Issue Fields can be defined at the organization level. Is there a way (or a plan) to support Issue Fields scoped to a single repository?
In some cases, we need structured metadata that is specific to one repository and not relevant to the entire organization.

Thanks🙏🏻

[labudis]

Thank you - that was very insightful!

If your primary use of Issues is through Projects you could still define some key Fields at the Org level, even if not all of them apply to the whole organization. If you don't pin fields to Types, they will not show up in the Issue creator/sidebar. However, you will be able to add the needed Fields to all of your Projects as needed without impacting other Projects.

[hadarziv-army]

Hi,

Thank you, this is a very interesting approach.

I’d like to experiment with this feature in a sample organization I manage (ZSoftSystems) to better understand how it behaves.

That said, I still think the feature you mentioned earlier, supporting multiple type-field mapping schemas that can be applied per repository, sounds excellent and could be a great fit for our large organization in the long term.

Thanks again for the guidance!

[labudis]

We added Issue fields to ZSoftSystems so you can experiment ;)

[hadarziv-army]

Hi Again👋🏻

Thank you so much. I’ve experimented with this in ZSoftSystems, and it works great. I really like this approach.
I have two follow-up questions regarding the potential schema feature:

1. If we could define a schema and select which schema applies per repository, would repositories be able to override certain field values?
   For example, if a schema defines fields like Status or Priority as single-select, could each repository customize the available options? In our organization, each team works independently and uses different statuses, priorities, and other field values.

2. Would it be possible to include Iterations in this model, where the iteration field is defined at the organization schema level, but the actual iteration values are configured at the repository level?
   That way, multiple Projects could share a single source of truth while still allowing repository-level flexibility.

If such a feature were available, our organization could centrally manage different “methodology schemas” that teams opt into and customize as needed.

I think this could make Projects significantly more powerful while keeping large organizations structured and flexible.

Thanks again for the support 🙏🏻

[labudis]

1. We looked at the option of providing repo-level overrides for further flexibility but please keep in mind that this was just a design exploration at this point.

2. It's an interesting idea but our point of view is that Iterations are more of a Project focused field than something that spans the entire organization. In our experience, teams tend to run things on different schedules and cadences and a Project field gives the right amount of flexibility for each team to set their process.

[msxdan]

We'd love to try this feature as well! org:luceraenergia

[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

[gawertm]

please enable for org: giantswarm

[jkgerig]

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