Feature Request: Advanced Slack Subscription Filtering for Pull Requests

[bodenloszt]

Select Topic Area

Product Feedback

Body

Hello,

First, thank you for building and maintaining the GitHub–Slack integration — it’s a huge help and definitely streamlines the interaction with repositories.

I’d like to request a feature enhancement for the Slack subscription commands.

Currently:

• /github subscribe owner/repo commits:<branch>
• /github subscribe owner/repo pulls
  work well for filtering by branch name or by type (issue, pull request).

However, it would be extremely useful if we could filter Pull Requests based on commit message (and or title) content and their type (opened, closed, and/or merged).

Example usage:

• /github subscribe owner/repo pulls:opened,merged commits:team-name → This would send notifications only for Merged and Opened pull requests whose commits contain "team-name" in the message (no complex regex required)
• /github subscribe owner/repo pulls:opened,merged title:word → This would send notifications only for Merged and Opened pull requests whose PR title contain "word"
• /github subscribe owner/repo pulls:opened,merged title:word commits:team,backend → Merged and Opened pull requests & "word" inside the title of the PR and requires matching either "team" or "backend" inside one of the commits; if not matched, the PR would not be published to Slack.

Benefit:
This feature would make Slack notifications far more relevant for teams that use commit message tags to indicate features, tickets, or deployments — reducing noise and ensuring important updates are highlighted.

Additional Context:
The organization I work for has around 5,500 repositories and some projects have hundreds of contributors. Having this level of customization would enable each team to follow their requested changes effectively without being overwhelmed by unrelated notifications. This would massively improve productivity and clarity across such a large organization.

Is this type of filtering something that could be considered for a future release?

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[rasquith]

Any updates on this? It's a feature I my team would use every day. Including labels adds an extra step with every PR in every repo we subscribe to.

[ThomasMasak]

Additional request

Also, being able to filter labels negatively would have been a very useful.

We can filter notifications only for PRs that HAVE a label, however, we cannot filter them for PRs that do NOT have a label.

Example

We would like to keep two Slack channels for PR notifications:

1. One specifically for noisy regularly scheduled bot automated PRs such as Dependabot & various custom autoupdate PRs like pre-commit autoupdate etc. We can already do this by filtering for PRs that have "automated" label.
   These ones are often automerged by our PR manager GitHub app on approval.

2. Another one for the rest, eg "human" PRs, bugfixes, features, releases etc.
   But currently we cannot pass a flag like /github subscribe ORG/REPO pulls -label:"automated" to indicate any PRs that do NOT have "automated" label.
   This ends up with our main PR notification channel being flooded with Dependabot PRs and such.

I am in process of adding our own labeling flow to differentiate, but it requires touching every single repository with a caller workflow to a centralized reusable workflow. Lots of repetition, not ideal.

Or we could create our own Slack notification Action, but that would still require touching every repo, so.. not ideal

[theodoroskoutanis-tomtom]

+1. ADO has this, it's a shame we don't get this feature in the github app

[shane-matthews-vizio]

Would really love this feature! Automated PRs in my org have a label that we would love to exclude notifications for.

[sindre-henriksen]

+1. Would love to see the full filtering in this request land. If it helps as an incremental step, there's a lighter version that might be quick to ship on its own: Dependabot already applies a dependencies label to every PR it opens by default, so even just supporting a negative label filter — e.g. /github subscribe owner/repo pulls -label:"dependencies" — would kill the bot-flood for a lot of teams with no extra labeling setup. Could be a nice first slice while the broader type/title/commit-message filtering is in the works.