What the auto-add workflow does
A GitHub Project can fill itself with issues the moment they are created, or you can add each one by hand.
Both approaches work.
The right choice depends on how much noise you can tolerate and how much control you want over what reaches your board.
This guide walks through what the auto-add workflow actually does, how to configure it, and the situations where manual adding is the better call.
GitHub Projects include a built-in workflow that can automatically add items from a repository as they are created or updated.
You define a filter, and any new item matching that filter lands in your project without you lifting a finger.
You can also create multiple auto-add workflows, each with its own filter and target repository, according to GitHub's documentation.
One detail catches many people out: when you enable the auto-add workflow, existing items that match your criteria are not added.
Only items created or updated after the workflow is turned on will flow in.
If you want older issues on the board, you add them manually.
The workflow supports a subset of filters.
You can filter by state (open, closed, merged, draft), item type (issue or pull request), label, close reason, and assignee.
All filters other than the assignee's no variants support negation, so a filter like -label:bug would add issues that do not carry the bug label.
How many auto-add workflows you can run
The number of auto-add workflows is limited by your plan, per GitHub's documentation:
- GitHub Free: 1 workflow
- GitHub Pro: 5 workflows
- GitHub Team: 5 workflows
- GitHub Enterprise Cloud: 20 workflows
- GitHub Enterprise Server: 20 workflows
On a free plan you get a single workflow, so choose its filter carefully.
You can duplicate the default workflow to create additional ones, up to your plan's maximum.
Each duplicate can target a different repository, or the same repository if the filter is unique for each workflow.
Configuring the auto-add workflow
The setup is short.
Following the documented steps in GitHub's guide:
- Navigate to your project.
- In the top-right, open the menu.
- Click Workflows.
- In the Default workflows list, click Auto-add to project, or one of the workflows you have previously duplicated.
- Click Edit in the top right.
- Under Filters, select the repository you want to add items from.
- Next to the repository selection, type the filter criteria items must match before they are added.
- Click Save and turn on workflow to enable it.
To duplicate the workflow instead, open Workflows, click the menu next to Auto-add to project, choose Duplicate workflow, and type a name when prompted.
When auto-add makes sense
Auto-add shines when your project is a broad working view and you want nothing to slip through.
Consider it in these situations.
You are the only contributor
If you run a solo project and every issue you create belongs on the board anyway, a filter like is:issue is:open on your own repository saves you a step for every single issue.
There is no review friction because there is no one else to surprise.
You want a complete intake queue
Community builders and early operators often use a project as a triage inbox.
Auto-adding every open issue means new reports appear immediately, and you triage them by moving them across your views.
The risk of missing a fresh issue outweighs the cost of occasional noise.
Your labels already do the sorting
If your team is disciplined about labels, a filter like is:issue label:planned keeps the board clean while still automating the add step.
The label becomes the gate, and the workflow handles the rest.
When manual adding is the better choice
Manual adding gives you a deliberate gate.
Every item on the board is there because someone decided it should be.
Your repository mixes many concerns
If a repository holds bugs, feature requests, questions, and experiments, auto-adding everything floods the board with items you may never act on.
Adding manually means the board reflects decisions, not just activity.
You work across several repositories
On a free plan you have one auto-add workflow, which may not cover multiple repositories with different filters.
Manual adding, or a small set of duplicated workflows on a paid plan, gives you room to be selective.
You want to control timing
Sometimes an issue exists but should not appear on the roadmap yet, perhaps because it depends on an unfinished decision.
Manual adding lets you hold items back until they are ready.
A middle path: auto-add with a strict filter
You do not have to choose between all-or-nothing automation and full manual work.
A narrow filter gives you most of the convenience with most of the control.
For example, suppose you triage every new issue by applying either a triaged label or leaving it unlabelled while you investigate.
You could set the auto-add filter to is:issue label:triaged .
New issues stay off the board until you have looked at them and applied the label.
The moment you label one, the workflow adds it on its next update.
You get a curated board without ever clicking add to project.
This pattern works because the workflow adds items when they are created or updated and match the filter.
Labelling an issue counts as an update, so the gate opens exactly when you decide it should.
The tradeoff is that the automation depends on your labelling habit.
If you forget to label, items never arrive, and the board silently under-represents your work.
Pick a gate you will actually maintain.
Practical checks before you turn it on
Before enabling auto-add, answer these questions:
- What volume of new issues does the repository get? High-volume repos benefit most from automation but also produce the most noise without a filter.
- Do existing labels reliably separate what belongs on the board from what does not? If not, tighten your labelling first.
- How many workflows does your plan allow, and do you need filters across multiple repositories?
- Will people outside your team see this project? If so, lean toward stricter filters or manual adds.
If you are still designing the project itself, it helps to decide the view structure first.
Our guide to GitHub Project table vs board vs roadmap covers how the layout choice shapes what belongs on the project in the first place.
Common mistakes to avoid
Expecting a backfill.
The workflow does not add existing items, so a newly enabled filter will not populate your board with history.
Plan a one-time manual add for anything older.
Overlapping filters.
If you duplicate workflows and target the same repository, make sure each filter is unique, or you will add the same issue twice through different workflows.
Filtering too narrowly at first.
It is easier to start with a slightly broader filter and tighten it than to wonder why nothing is appearing.
Check the filter syntax, including negation, if items fail to arrive.
Confusing the project with the repository.
Auto-add controls what enters the project, not what happens to the issue itself.
Closing or deleting an issue is a separate decision, which we cover in should you close or delete an issue on GitHub.
The decision in one line
Auto-add when the board should mirror everything that happens in a repository, or when a reliable label can act as your gate.
Add manually when the board is a curated statement of what you intend to do.
Many teams end up with the middle path: automation plus a strict filter, reviewed whenever their labelling habits change.
Whichever route you pick, revisit the filter after a few weeks of real use.
The best configuration is the one that matches how you actually work, not the one that sounded efficient on day one.
If you are setting up a project from scratch, it may also be worth deciding whether to start from an existing repository structure.
Our guide on copying an existing GitHub project as a template covers that decision.
Breaking an issue into sub-issues explains how to structure the items your new workflow will catch.
Take the next step with Ideoreto. Use the ideas in this guide as a starting point for your next project.
Register for Ideoreto to get started.