Study guide
11.2 Configuring Projects, Labels, Milestones, and Workflows
GitHub Foundations GH-900
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Domains, Scoring, and Candidate Profile 1.3 Official Resources and Hands-On Prep
2 Version Control Fundamentals
2.1 Purpose and Benefits of Version Control 2.2 Git vs GitHub 2.3 Repositories, Commits, and History 2.4 Branches, HEAD, and the Default Branch
3 Working with GitHub
3.1 Accounts, Organizations, and Enterprise Options 3.2 GitHub Flow 3.3 Markdown for Issues and Pull Requests 3.4 GitHub Desktop and GitHub Mobile
4 Repository Structure and Key Files
4.1 Repository Structure and Community Health Files 4.2 Creating Repositories with Templates and Branches 4.3 Adding and Managing Files
5 Repository Insights and Maintenance
5.1 Insights, Stars, Dashboards, and Dependency Insights 5.2 Repository Maintenance and Collaboration Best Practices
6 Issues and Pull Requests
6.1 Issues 6.2 Pull Requests 6.3 Linking PRs, Templates, Filters, and Assignments
7 Discussions, Notifications, and Documentation
7.1 Discussions 7.2 Notifications and Workflow Management 7.3 Gists, Wikis, and GitHub Pages
8 GitHub Actions
8.1 Actions Purpose, Workflows, and Events 8.2 Jobs, Steps, Runners, Secrets, and Reusable Actions
9 GitHub Copilot
9.1 Copilot Suggestions, Agents, Agent Mode, and Multi-Model Support 9.2 Copilot for Individuals, Business, and Enterprise
10 Codespaces and github.dev
10.1 Codespaces, Customization, and Dev Containers 10.2 github.dev vs Codespaces
11 Manage Projects with GitHub
11.1 GitHub Projects and Layout Options 11.2 Configuring Projects, Labels, Milestones, and Workflows 11.3 Saved Replies and Assignees 11.4 Project Insights
12 Account Security and Access
12.1 Two-Factor Authentication and Passkeys 12.2 Access Permissions and Roles 12.3 Enterprise Managed Users and Copilot Policy
13 Privacy, Branch Protection, and Organization Admin
13.1 Privacy, Visibility, and Branch Protection 13.2 Organization Settings, Teams, and Roles
14 Open Source, Sponsors, and InnerSource
14.1 Open Source Benefits and GitHub Sponsors 14.2 How GitHub Supports Open-Source Projects 14.3 InnerSource
15 Marketplace, Discovery, and Collaboration Models
15.1 Following Users and Organizations 15.2 GitHub Marketplace 15.3 Forks, Templates, and Discoverable Repositories
11.2 Configuring Projects, Labels, Milestones, and Workflows
Key Takeaways Explain This Topic AI
A project can use up to 50 fields in total, counting built-in metadata plus custom fields of type date, number, single select, text, and iteration.
Built-in project workflows auto-add matching repository items, auto-archive items that match a filter, and set fields when items are added, closed, or merged.
New projects enable two default workflows: closed issues or pull requests get Status Done, and merged pull requests get Status Done.
Labels and milestones still live on repository issues and pull requests; you filter and group them in project views, but creating labels needs write access and triage can only apply existing labels.
Organization project templates copy views, custom fields, draft issues, configured workflows except auto-add workflows, and insights; org owners can recommend up to six templates.
Last updated: August 2026
Why configuration is its own GH-900 skill
Domain 5's second bullet is explain how to configure projects, labels, milestones, and workflows . D5.1 asked what Projects is . D5.2 asks how you make a blank table useful: custom fields, built-in automations, and the repository metadata (labels and milestones) that still sit on issues and pull requests. GitHub's About Projects page lists those pieces in one paragraph; the exam splits them because candidates mix project fields with issue labels , and mix project workflows with GitHub Actions .
A project starts with built-in metadata you already know from issues: title, assignees, labels, milestone, linked pull requests, and a default Status single-select. Configuration is how you add the metadata your process needs—target ship date, story points, priority, sprint—and how you stop doing that by hand.
Custom fields (and the 50-field cap)
You are not limited to built-in issue metadata. Custom fields attach extra attributes to issues, pull requests, and draft issues in this project. GitHub's documented examples match the exam wording:
- Field type Official example How you use it in a view
- Date Target ship date Roadmap placement; filter “due this week”
- Number Complexity or story points Sum in a group header; sort the backlog
- Single select Priority: Low, Medium, High Board columns; colored options with descriptions
- Text A quick note Searchable scratch metadata that is not a label
- Iteration Week-by-week (or sprint) plan, including breaks Board columns, roadmap, @current / @next filters
You can use up to 50 fields in a project, including built-in metadata and custom fields . That cap is a favorite numeric fact. “Unlimited custom columns” is wrong. Single-select fields themselves support up to 50 options , each with optional color and description, and you can set a default option so new items arrive pre-filled (removing the default does not rewrite existing items).
Iteration fields deserve extra attention because they are not dates with a nicer name. An iteration is a repeating block of time with a duration (days or weeks), a start date, editable names, and optional breaks for holidays. Creating the field auto-creates three iterations. Filter with the iteration name or with @current , @previous , and @next , plus operators such as iteration:<@current . Group a view by iteration to balance upcoming work; use Move items to... on a group to roll unfinished work into the next sprint. Roadmaps use iteration fields (and date fields) as the timeline. Breaks communicate “we are not scheduling work here”; they are not deleted sprints.
Issue fields, parent/sub-issue progress, pull request reviewers, and issue type can also appear as columns. For GH-900, memorize the five custom types in the official About Projects list and the 50-field total. Do not spend the domain memorizing every newer issue-type column.
Custom fields are project metadata . They do not replace repository labels . A Priority single-select on the project is not visible as a label in another repository's Issues tab. Labels remain the cross-cutting tags on the issue itself; custom fields remain the planning attributes for this project (or for org-level issue fields, which GH-900 does not center).
Built-in workflows (not GitHub Actions)
Projects include built-in workflows . You open the project menu, click Workflows , edit a workflow, then Save and turn on workflow . These are not YAML files in .github/workflows . If a question shows on: issues in a YAML file, that is Domain 4 Actions, even if the job adds the issue to a project via the API.
When a project initializes, two workflows are enabled by default : when issues or pull requests in the project are closed , Status is set to Done ; when pull requests in the project are merged , Status is set to Done . You can also set fields when items are added (for example Status → Todo on add) and close issues when project Status changes.
Three automation families show up on the exam:
Auto-add. Add new issues and pull requests from a chosen repository when they match a filter. Filters include is (open, closed, merged, draft, issue, pr), label , reason , assignee , and no (label, assignee, reason). Negation works ( -label:bug ). Existing items that already match are not added when you enable the workflow—only items created or updated afterward. You can duplicate auto-add workflows; each targets a repository (or the same repository with a unique filter). Plan limits apply: 1 auto-add workflow on GitHub Free, 5 on Pro and Team, 20 on Enterprise Cloud and Enterprise Server.
Auto-archive. Remove matching items from active views while keeping custom field data on the archive page, where you can restore them. Auto-archive filters are only is , reason , and updated (for example last 14 days, 3 weeks, or 1 month). GitHub marks an item updated when it is created, reopened, edited, commented, labeled, reassigned, milestoned, transferred, or when project field values change. Enabling auto-archive also archives items that already match , unlike auto-add. Archive is not delete: the 50,000-item cap still counts archived items; you delete only to free space.
Set fields. Item added → Status Todo; item closed → Status Done; pull request merged → Status Done. These keep the board honest without a person dragging cards.
You can go further with the GraphQL API and Actions, but GH-900 wants the built-in trio. Activity from built-in workflows shows as @github-project-automation on the issue timeline.
Loading diagram... Repository metadata versus project configuration
Labels still live on issues and pull requests
Labels classify issues, pull requests, and discussions in the repository where the label was created . Adding, editing, or deleting a label in one repository does not change labels in another. GitHub ships default labels ( bug , documentation , duplicate , enhancement , good first issue , help wanted , invalid , question , wontfix , plus accessibility ). Organization owners can customize default labels for new org repositories. Issues labeled good first issue populate the repository contribute page.
Permissions are a standard GH-900 trap:
Write access is required to create, edit, or delete a label.
Triage access is enough to apply or dismiss existing labels.
Deleting a label removes it from issues and pull requests. In a project, labels are built-in metadata you can show as a column, filter ( label:bug ), group, or slice. They are still repository objects. A project custom field named “Type” is not a label. Auto-add can key off labels ( label:"good first issue" ) so labeled work flows into the project without a person pasting URLs.
Milestones still live on issues and pull requests
A milestone groups issues and pull requests in a repository toward a date. The milestone page shows a description, due date , completion percentage , counts of open and closed items, and the item list. You can create new issues already associated with the milestone and drag to prioritize (prioritization stops if a milestone has more than 500 open issues).
Milestones are not iteration fields. An iteration is a project field with repeating length and @current filters. A milestone is a named repository bucket with a due date and a percent complete based on closed issues and pull requests. Roadmaps can draw vertical markers for milestones so the timeline shows both project iterations and repository due dates. You can group or filter a project view by milestone because that metadata syncs from the issue. You cannot attach a milestone to a draft issue until you convert the draft into a repository issue.
If a question says “show how much of version 2.1 is closed,” the answer is a milestone . If it says “plan the next two-week sprint across repos,” the answer is an iteration field (often plus a board grouped by iteration).
Organization project templates
You can create a project template for an organization, or set an existing project as a template, so members start from a known layout. GitHub copies views, custom fields, draft issues and their field values, configured workflows (except any auto-add workflows), and insights . Auto-add is excluded on purpose: it is bound to specific repositories and would surprise the next team. You cannot add status updates to a project that is set as a template.
Org owners can recommend up to six templates; those appear first in the create-project dialog. Admins can toggle Make template in project settings. Write or admin permission lets you Copy as template , which duplicates the current project and marks the copy as a template. Templates can also be added to teams and repositories for discovery.
Exam scenarios and traps
“Track story points and a ship date that issues do not have natively” → number and date custom fields, not a new label named 5-points .
“Every new bug issue in web should appear on the org board” → built-in auto-add workflow with label:bug , not an Actions workflow unless the question shows YAML.
“Closed items clutter the board but we might reopen them” → auto-archive , which keeps field data; not delete.
Enabling auto-add does not import the existing backlog; enabling auto-archive does archive items that already match.
Templates do not copy auto-add workflows. If the cloned project is empty, that is expected until someone turns auto-add on again.
50 fields includes built-in plus custom. 50 options is the single-select option cap—do not swap those numbers.
Labels: triage applies, write creates. Milestones: repository due-date buckets, not iteration sprints.
Project workflows ≠ Actions. .github/workflows is Domain 4.
Configure fields and automations first; communication features in the next section (saved replies and assignees) sit on the issues and pull requests those workflows pull in.