Pull requests become hard to manage when review requests, failing CI, and merge-ready work are spread across repositories. GitHub’s refreshed dashboard provides one inbox and reusable views for that cross-repository work.
Quick answer
Open github.com/pulls, customize the inbox sections, and save two or three views around actions you actually take. Start with “review requested,” “needs fixes,” and “ready to merge” instead of building one giant query.
(org:your-org AND review-requested:@me)
OR (org:your-org AND author:@me AND status:failure)what changed
The generally available dashboard adds an inbox, saved views, advanced AND/OR searches, nested expressions, and autocomplete. It also handles in-progress CI and merge states more clearly and supports keyboard navigation with j and k.
This is a current platform change, so confirm availability for your plan, organization, and installed client before changing a production workflow. Preview features can also change faster than generally available controls.
who should use it
Developers working across several services gain the most. Managers can save a view for blocked pull requests without replacing team ownership, while reviewers can isolate requests that still need their specific attention.
The practical question is whether the feature removes a real bottleneck or security gap in your workflow. A new control is not valuable merely because it exists; it needs an owner, a narrow purpose, and an observable result.
a safe implementation
- Hide inbox sections that do not drive an action.
- Create a narrow review-requested view.
- Create a second view for your failing or stale pull requests.
- Review saved searches monthly so they do not become another ignored inbox.
Make the first rollout small enough to reverse. Record the previous behavior, the setting or command that changed it, and the person responsible for deciding whether the experiment expands.
the mistake to avoid
Do not measure productivity by the number of pull requests visible in a dashboard. Large queues often reflect unclear ownership, oversized changes, or slow CI rather than individual effort.
Convenience features still operate inside your existing trust model. Repository permissions, protected environments, review rules, test accounts, and audit logs remain important even when the new workflow removes manual steps.
how to verify it
Compare the dashboard with two repositories you know well. Confirm review requests, CI failures, agent-authored work, and ready-to-merge items appear in the expected view before relying on it as your daily queue.
Keep the verification evidence in the pull request or rollout ticket. That gives reviewers something concrete to evaluate and gives the next person a known baseline when the platform changes again.
rollout checklist
- Confirm the feature and client version are available.
- Test with non-production data and minimum permissions.
- Capture expected success and failure behavior.
- Document rollback and ownership.
- Recheck the official announcement before a wide rollout.
official reference
The announcement is the source of truth for availability and product behavior. This article focuses on the implementation decisions teams should make around it.