Overview
PRFlow delivers GitHub pull request notifications to Slack. For each pull request it posts one Slack message that updates in place as the PR progresses — CI check status, reviews, and merge state all appear on the original message, and PR comments are synced into a Slack thread under it. Unlike the GitLab integration, there is nothing to configure on the GitHub side beyond installing the PRFlow GitHub App: the App delivers webhook events automatically and grants PRFlow its (read-only) API access in one step. PRFlow works with github.com organizations and personal accounts; GitHub Enterprise Server is not supported.Setup
- In PRFlow, open Settings → Connections and select GitHub as the source provider. A workspace connects one source provider — GitHub or GitLab, not both at once.
- Click Install GitHub App. GitHub asks you to pick the account or organization and which repositories the App may see (all, or a selected list), and shows the read-only permissions it requests.
- Back in PRFlow, connect Slack if you haven’t yet, then map repositories to Slack channels from the dashboard.
How it works
Events PRFlow reacts to
The GitHub App subscribes to pull request activity. Events for repositories you haven’t mapped to a Slack channel are acknowledged and discarded.| Event | What PRFlow does |
|---|---|
pull_request | opened, reopened, and ready_for_review post the PR message; edited, synchronize, review_requested, and converted_to_draft update it in place; closed marks the PR merged or closed. Other actions (labeled, assigned, …) are ignored. |
pull_request_review | A submitted review updates the message’s review state — approved or changes requested. |
issue_comment, pull_request_review_comment | Conversation comments on a PR and inline review comments on the diff are posted as threaded replies under the PR message. Edited comments are updated in place; deleted comments are removed from the Slack thread. Comments on plain issues are ignored. |
check_suite / check_run | Update the CI status shown on the PR message, aggregated across check suites — GitHub Actions and any other check provider. Only the newest run of each check counts, so a re-run that passes flips the card to ✅ even if an earlier run failed. |
installation, installation_repositories | Track the App’s lifecycle: installing, uninstalling, and changing the repository selection. Uninstalling the App from GitHub cleanly disconnects the integration. |
Slack message model
The Slack side is identical to the GitLab integration: a 1:1 mapping between a pull request and a Slack message, updated in place viachat.update, with
merge-requirement rows that flip from 🔴 to 🟢 as CI, approvals, and
mergeability are satisfied. On GitHub the merge requirements are read from
the repository’s branch rulesets; repositories using classic branch
protection (which the App’s read-only permissions cannot inspect) get a
conservative fallback that never overstates what is required.
Comment sync: each PR comment becomes a threaded reply under the PR
message, quoting the comment text (truncated to 500 characters) with the
commenter’s username. Comment edits on GitHub update the existing thread
reply; comment deletions remove it. Comment bodies are not stored — PRFlow
keeps only the comment ID and the Slack message reference so it can edit or
delete the reply later.
Permissions & data
The App requests three read-only permissions:| Permission | Why PRFlow needs it |
|---|---|
| Pull requests: read | PR metadata for notifications, and review state when rendering the message. |
| Checks: read | CI status from check suites and check runs. |
| Metadata: read | Repository names for the repository picker, and branch rulesets for the merge-requirement rows. |
X-Hub-Signature-256) before it is
processed. As with GitLab, only pull request, review, comment, and check
metadata is handled — see the GitLab page’s
data handling section for the storage
and Slack-delivery details, which apply equally here.