Queues & intake
Queue channels (/qb setup queue) are where PRs live: every PR link pasted here is tracked into that queue. Intake channels (/qb setup intake) are busy front doors that route links onward to the right team queue instead of holding them. Either way the bot must be in the channel — setup joins public channels by itself; private ones need /invite @Queuebird first.
Both channel types have a pickup mode: every-link (any pasted PR link is picked up) or explicit (only an @Queuebird mention is picked up; a bare paste is ignored). The default is every-link — that’s what makes a queue channel the “everything here is a PR” surface — but a queue channel switched to explicit ignores bare pastes exactly like an intake channel does.
How a link finds its queue
When a link needs routing, Queuebird tries these in order:
- a team tag in the message,
- a GitHub team review request on the PR,
- the queue that owns the repo,
- the only queue there is.
A PR that only asks individual people — no team — doesn’t route on that alone; those become directed asks (see Asks & routing). If nothing resolves, or two queues tie, Queuebird posts a disambiguation prompt with one button per candidate queue. A link that can’t be resolved immediately is held briefly — invisible to everyone — until its GitHub snapshot arrives, then routed or disambiguated. Nothing lingers silently.
However a link resolves, the destination queue channel gets its own arrival card — 📥 with the PR and a 👀 Open & Review button — so the team that now owes the review sees it in their own channel, not only in App Home. The intake channel keeps its threaded “📥 Routed to team’s review queue.” confirmation.
The moment a workspace gets its second queue channel, the setup runner and every queue’s maintainers get a one-shot DM suggesting they configure the routing signals above — that’s the point where routing starts to matter.
Who can see a queue
A queue belongs to the people in its channel. That holds whether the channel is public or private. Being in the workspace is not enough — you have to be in the channel.
Three groups see a queue:
- Members of the channel.
- Its maintainers, named in that channel’s own
/qb config. A maintainer sees the queues they maintain without being a Slack member of them, and only those. It’s keyed on the Slack user, so it works even for a maintainer who hasn’t linked GitHub. - Workspace admins, who see every team PR.
People involved with a PR see it wherever it lives, membership or not: the author, anyone GitHub requested, anyone asked by @-mention, past reviewers, and whoever is currently reviewing it. GitHub or the asker already handed them that PR. It lands in their NEEDS YOU and they get its DMs, while the rest of that channel’s queue stays invisible to them.
This is why joining a team’s channel is how you start seeing their queue. If you’re being asked to review things for a team you’re not on, you were probably @-mentioned or requested on GitHub.