Before
Teams likely had to inspect GitHub pull request events, identify the requester, reviewer, team, or author, and determine whether the event required action. They then had to look up corresponding Slack users, copy the pull request details, and manually post a channel announcement or direct message, with failures and queue changes creating additional follow-up work.
How it works
- Receive and filter GitHub pull request webhook events to identify review requests, submitted reviews, and relevant merge-queue outcomes.
- Resolve GitHub identities through the Slack roster and Notion mappings, then determine whether the request targets an individual reviewer or a team.
- Publish the appropriate Slack announcement or direct message, including the pull request link, title, requester or author, and review or failure status.
Workflow details
- Event filtering: The workflow starts with GitHub webhook data and continues only for relevant pull request review requests, submitted reviews, or merge-queue outcomes. Unrelated events and requests without a relevant reviewer or team are ignored.
- Identity resolution: It retrieves the Slack team roster and matches GitHub usernames to Slack user IDs. It also queries the Notion user mapping database for GitHub IDs and corresponding Slack IDs, using the GitHub identity as a fallback when a mapping is unavailable.
- Review request routing: For an individual review request, the workflow looks up the reviewer and posts a Slack announcement that identifies the requester, reviewer, pull request link, and title. For a team request, it posts a similar announcement addressed to the requested team in the configured Slack channel.
- Review result notifications: When a pull request review is submitted, the workflow identifies the pull request author through the mapping database and sends that person a direct Slack message containing the review state, pull request link, and title.
- Queue and failure handling: When a merge-queue event indicates a continuous-integration failure or a dequeued pull request, the workflow sends the author a direct Slack message explaining that the pull request was rejected or removed from the queue. Successful branches complete without additional escalation.
What changed
Relevant pull request events are now evaluated and routed automatically as they arrive. Identity lookups, individual-versus-team checks, pull request message construction, and Slack delivery happen within the workflow, while irrelevant events are ignored and unmapped users can use the available GitHub identity as a fallback.
Work removed
Reviewing pull request events one by one, looking up GitHub users in the Slack roster, checking Notion for GitHub-to-Slack mappings, copying pull request links and titles, composing channel announcements, sending review-result or failure direct messages, and deciding whether a request targets an individual or a team.
Expected outcome
Each qualifying event receives one automated routing decision and one targeted Slack notification, removing at least two recurring identity lookups and the associated manual message handoff from the process.
