ScrumbeeSecurity
You grant access. Scrumbee does not invent a side door.
Scrumbee connects through the official authentication mechanisms those platforms provide. Access is limited to the permissions and scopes approved during setup. This page describes those requests as they exist in the product today — not as marketing guarantees about data Scrumbee “cannot ever see.”
Official connections only
Each integration uses the vendor’s own OAuth or app-install flow. Your administrators see the same consent screens they would for any other Jira, GitHub, Bitbucket, or Slack app.
- Jira Cloud: Atlassian OAuth 2.0 (3LO)
- GitHub: GitHub App installation when configured, otherwise GitHub OAuth
- Bitbucket: Bitbucket OAuth 2.0 consumer
- Slack: Slack app installation into the workspace
You approve what Scrumbee can read and do
Nothing is connected until a person in the workspace completes that vendor screen. Scrumbee then operates with the token or installation that results — scoped to what was granted, and to the sites, organizations, or repositories chosen during install.
The product is built around work information: projects, issues, pull requests, commits, and the Slack conversation needed to act on them. It is not a consumer app harvesting personal profiles for their own sake.
Jira permissions requested
The Atlassian authorization requests these scopes, which match how Scrumbee uses Jira: reading work, updating issues when the team asks (for example a status transition), reading user records needed to map people, registering webhooks, and refreshing the token over time.
| Scope | Why it is requested |
|---|---|
| read:jira-work | Projects, issues, status, assignment, sprints, and related work fields. |
| write:jira-work | Issue updates the team triggers from Slack, such as changing ticket status. |
| read:jira-user | Map Slack people to Jira accounts so standups and assignments line up. |
| manage:jira-webhook | Receive issue and sprint events instead of polling blindly. |
| offline_access | Refresh the connection so it keeps working after the first login. |
GitHub permissions requested
When Scrumbee is installed as a GitHub App, GitHub shows the app’s repository selection and permission set, and a person chooses which repositories to include. That is the preferred path.
If the deployment uses a GitHub OAuth App instead, the product requests repo and user:email. repo is a broad GitHub scope: it covers private repository metadata, pull requests, and commits the app needs for development signals. user:email is used to associate a GitHub identity. Treat the GitHub consent screen as the source of truth for exactly which repositories are included.
Bitbucket permissions requested
Bitbucket access is granted through Bitbucket’s OAuth 2.0 consumer. The privileges shown on Bitbucket’s authorization page are the ones that apply — typically enough to read workspace, repository, pull request, and commit activity so Scrumbee can observe development work the same way it does on GitHub.
Scrumbee uses that activity as work context. It does not present Bitbucket as a place to re-host your source.
Slack
Slack access is whatever the Scrumbee Slack app is configured to request at install time (messaging in channels it is invited to, commands, and the events needed to talk with the team). The Slack installation screen lists those scopes. Scrumbee’s product experience is that workspace — not a shadow copy of it.
What this page does not claim
We do not claim that granted scopes make other data “technically unreachable.” If a scope is broad (GitHub repo is the clear example), the vendor’s consent screen is the honest description. Revoking the app in Jira, GitHub, Bitbucket, or Slack removes Scrumbee’s access the same way it would for any other integration.
Connect the workspace your team already uses.
Scrumbee is installed into Slack. From there, the team authorizes Jira, GitHub, or Bitbucket using each platform’s official sign-in flow. There is no separate email signup.
Connect Slack workspace