GitHub’s pull requests dashboard is now a real home for review work instead of a list you visit only when someone sends you a link. The refreshed dashboard at github.com/pulls became generally available on July 9, 2026, with an inbox, saved views, and more expressive search.
That matters if you work across several repositories. A repository-by-repository habit makes review requests easy to miss. A global inbox lets you start from the work that needs attention, then narrow the list by organization, repository, author, or review state.
Start with the inbox, not a giant saved query
Open the pull requests dashboard and keep the inbox as the first stop. GitHub’s inbox groups work that needs a decision, including direct review requests, pull requests with updates or failing checks, and items that are ready to merge or waiting in a merge queue. You can reorder or hide sections to match the way you actually work.
Do not try to encode every possible state into one filter on day one. Use the inbox for triage, then create saved views for recurring questions that deserve their own name.
Three saved views worth creating
A useful saved view answers one question without asking you to remember the query that produced it. Start with these:
The exact filter names depend on the dashboard’s current search syntax, but the point is stable: a view should reduce a repeated decision to one click. GitHub’s [dashboard guide] covers creating, editing, and organizing saved views.
Use the new review filters carefully
The July dashboard release added filters that are easy to confuse. `review-involves:@me` finds pull requests where you have been asked to review, regardless of whether somebody else has already approved it. `team-review-requested-user:@me` finds pull requests where you are included through a team review request. The [general availability announcement] documents both filters and their intended behavior.
is:pr is:open review-involves:@me
is:pr is:open team-review-requested-user:@me
is:pr is:open author:@meThis distinction helps when your team uses CODEOWNERS or team review requests. A direct request and a team request can look similar in a busy list, but they imply different ownership. Treat the query as a starting point and confirm the required reviewer in the pull request itself.
A simple daily review loop
1. Triage the inbox
Clear the newest blocking items first. Pull requests with a failing check, a new author reply, or a direct review request usually need a decision before older informational updates. Hide inbox sections you never use so the page stays short.
2. Work from one saved view
When you are ready for a review block, open Needs my review instead of browsing repositories. Review in an order that matches your team’s work, such as urgent fixes first, then changes that unblock another layer.
3. Close the loop
After you review, leave a clear state behind. Approve, request changes, comment with a decision, or remove yourself when the request is no longer yours. An inbox is useful only when it reflects current ownership.
Where search fits
The dashboard search is useful for cross-repository questions that do not deserve a permanent view. Try a temporary query when you need to investigate a release, organization, or author. Save it only when you expect to use the same question again.
Do not let saved views become another backlog
Saved views are not a replacement for ownership. Ten views with unclear names create a second navigation problem. Give every view a verb or a decision in its name, such as Needs my review or Ready for release. Delete views that no longer answer a question.
Also remember that a saved view is a query, not a snapshot. The results change as pull requests move, checks finish, and people review. That is the reason to use one for a live queue, and the reason not to treat it as a historical report.
How the dashboard works with other habits
The dashboard is best for discovery and triage. Notifications are still useful for urgent events. Repository pages are still the place for detailed review. A good workflow uses the dashboard to decide where to go next, rather than trying to turn the dashboard into the full review experience.
A five-minute setup
The new pull requests dashboard is most useful when it answers a small set of recurring questions: what needs my review, what needs fixing, and what can move next. Start there. The more selective your views are, the less time you spend scanning GitHub for a signal that should have been obvious.