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

Features included in the private preview ✅

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 ❌

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.

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

[tellisnz]

for the mapping to type it would be cool to just have a flag that sets the field to apply to all types

[labudis]

@tellisnz great feedback! Regarding field-type mapping, are you mainly interested in making certain fields appear on untyped issues, or is it more about speeding up the pinning process in Types?

On status: since issues can be part of multiple projects and status values can differ from project to project, we consider status a project-specific field. However, we are aware of cases where synchronising status across projects might be desirable. Would you be happy to share more about how you would like this to work for your setup?

[tellisnz]

@labudis - little of both - how do i apply fields to untyped issues? or i can't atm?

then pinning, i'm just being a bit lazy really in that if you are setting up and you have got a few issue types then pinning each field takes a fair amount of clicking.

The pinning is also a little unintuitive if you are unaware of it - when you add the field you kinda expect it to already be on all issue types already.

Maybe it could be switched around in that instead of getting user to add the new fields everywhere, you could exclude the field from certain types if you needed to? Or a flag on a field type to 'require pinning'. If those ideas are no-gos, then you'd save some clicks if you offered to pin to types at the same time as you were creating the field.

[labudis]

Great suggestions, thanks!

We're currently mulling over two potential approaches:

• Extend pinning to untyped issues (best for flexibility, and works for folks who do not use Types heavily but requires careful type management)
• Default pin certain fields to all issue types (assuming lots of shared fields
• Combination of both

Another way to add fields to issues without types is to do it via a Project view. You would first need to add some issue fields to your Project and create a view where these fields are visible as columns.

[tellisnz]

nice!

Default pin certain fields to all issue types (assuming lots of shared fields

+1

Is there a way to set the new issue fields via issue templates & make them mandatory?

Another way to add fields to issues without types is to do it via a Project view. You would first need to add some issue fields to your Project and create a view where these fields are visible as columns.

These are still just the project custom fields right? These are the ones we are migrating from

And sorry just going back to feeding back on status:

So we pretty much just use a single project to drive everything in our org - maybe we're using it wrong but this works really well for us.

Appreciate others might using multiple projects with status fields with different states - are they the majority?

Otherwise it'd be amazing if we could use the project custom fields to also search for issues in the main issues filter, or be able to bulk close issues from the project view.

E.g. at the moment I can't bulk close a bunch of issues with a status of x iteration (custom field) and status (custom field) because I can't use those to search in the issues filter, and there is no bulk close functionality in the project views (unless i'm blind, let me know if i'm mistaken here :D - appreciate i could use a workflow to close when we get into a status but this isn't quite what we want due to various reasons)

[Eve-Yesodot]

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

[labudis]

Thank you for your interest in issue fields. We’d love to learn more about your use case, including how you intend to use issue fields in your organization. In the meantime, I will add your organization to the waitlist.

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

[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

[labudis]

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.

[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