Hi @uziyona,

Currently, the Iteration field type is unique to GitHub Projects and is not yet available as a standalone Issue Custom Field (at the repository or organization level).

While you can create Text, Number, Date, and Single Select fields directly on Issues (visible in the right sidebar even outside a Project), the "Iteration" logic—which automatically handles date ranges, "current," and "next" scopes—is still tied specifically to the Project infrastructure.

Workarounds:

Use the Projects sidebar: If you link the Issue to a Project, you can see and edit the Project's Iteration field from the "Projects" section of the Issue sidebar.

Single Select Field: If you need a "sprint" field that lives natively on the Issue (independent of a Project), the closest alternative right now is creating a Single Select custom field, though you lose the automatic date logic.

To track if this is coming, I recommend keeping an eye on the GitHub Public Roadmap.

Hi @Thiago-code-lab
Thank you for the prompt respond!

I thought Issues field is defined at org level and then applicable to all projects and pinned Issues.

Can you add it as feature request? Iteration is a key element in planning, and as it is available in project level, i think it should be also on org level.

Not sure i understand your workaround:

Workarounds:

Use the Projects sidebar: If you link the Issue to a Project, you can see and edit the Project's Iteration field from the "Projects" section of the Issue sidebar.

To add to the previous reply:

At the moment, the Iteration field type is tightly coupled to GitHub Projects and isn’t available as a standalone Issue custom field.

If your goal is to replicate iteration behavior outside a Project, a few workarounds are:

• Use a Single Select issue field (e.g., Sprint 1, Sprint 2, etc.) and manage values manually.
• Use Milestones if you want date-bound grouping tied to releases.
• Use labels for lightweight iteration tagging (e.g., sprint-24, sprint-25).

However, none of these options replicate the automatic date-range handling and “current/next” logic that Iteration fields provide inside Projects.

If iteration logic at the Issue level is important for your workflow, it may be worth submitting this as a formal feature request via GitHub Feedback.

Right now, Iterations remain a Project-scoped feature.

At the moment, Projects (new) custom fields don’t support an “Iteration” field type, and there hasn’t been an official announcement confirming that this specific field type is on the public roadmap.

The currently available custom field types are limited to things like:

• text
• number
• single select
• date
• iteration (only for built-in system use, not as a user-defined custom field)

So while you can use the built-in Iteration field, you can’t create your own custom field that behaves the same way as the native Iteration type for Issues.

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

Short answer: no public roadmap item for an Iteration field type at the Issue/org level. If it shows up, it'll land on the Projects public roadmap (github.com/orgs/github/projects/4247). Dropping your use case there as a comment tends to help more than you'd think for prioritization.

The pattern that actually works today for org-wide iteration planning is one top-level Project v2 at the org level that pulls in issues from every repo you care about. The Iteration field on that project becomes your de facto org iteration, because every issue lives in it.

Setup:

1. Create a project at the org level (not inside a repo).
2. Settings > Workflows > enable "Auto-add to project" with a filter like is:open is:issue and pick the repos in scope. New issues drop in automatically.
3. Define your Iteration field once on that project.

Open an issue in any of those repos afterward and the Projects section in the sidebar shows this org project with the iteration dropdown right there. That's the "Projects sidebar" workaround the earlier replies pointed at, the missing step being the auto-add workflow so it actually scales beyond manual adds.

If you also run repo-specific projects for status/priority tracking, add the same issues there too. A single issue can belong to multiple projects and each project keeps its own field values, so iteration on the org project and status on the repo project don't step on each other.

For the feature request itself, you're already in the right place. Community Discussions is the official feedback channel for Projects. Post under "Projects and Issues" with a concrete use case (e.g., "I want shared iterations across 12 repos without manually replicating the field in each project"). Comments and upvotes are what the PM team reads when prioritizing.