Team Management
Scitor uses GitHub’s own access controls to manage who can work on support tickets. There is no separate Scitor user list — if someone has the right level of access on your GitHub repository, they can use Scitor commands.
How access works
Slash commands run through GitHub Issues or Discussions. Who can do what is determined entirely by their GitHub repository role:
| GitHub role | What they can do in Scitor |
|---|---|
| Admin | Everything — including billing and configuration commands |
| Write (Maintainer) | Full command access — /send, /close, /label, /assign, etc. |
| Triage | Can label, close, and reassign issues — but cannot use /send |
| Read | Can view issues but cannot use any commands |
The key distinction: /send requires Write access because it sends an email on behalf of your organisation. Triage-level collaborators can manage the queue but cannot reply to customers.
Adding a team member
- Open your support repository on GitHub
- Go to Settings → Collaborators and teams
- Click Add people
- Search by GitHub username or email address
- Select the appropriate role — Write for agents who reply to customers, Triage for queue managers who only route and label
- Click Add [name] to this repository
GitHub emails the invitee. They must accept the invitation before they can access the repository.
Tip
For GitHub organisations, add a team (e.g. support-agents) to the repository rather than individual users. Onboarding and offboarding become one step: add or remove someone from the team.
Removing a team member
- Go to Settings → Collaborators and teams in your support repository
- Click the × next to the team member’s name
- Confirm removal
Access is revoked immediately. Issues they were assigned to remain assigned — use /assign @newperson on those issues to hand them off.
Recommended roles
Support agents — people who read tickets and reply to customers — need Write access. This allows:
/send— reply by email/close,/reopen— manage ticket state/label,/unlabel— apply labels/assign,/followup,/schedule— route and manage/analyze,/summarize,/generate-report— AI commands
Queue managers or leads — people who triage and route tickets but don’t reply directly — can use Triage. They can label, close, and reassign but cannot send outbound emails.
Observers or stakeholders — people who need visibility without acting on tickets — use Read.
Command permission reference
| Command | Minimum role |
|---|---|
/send |
Write |
/close, /reopen |
Triage |
/label, /unlabel |
Triage |
/assign, /unassign |
Triage |
/followup, /schedule |
Write |
/block-sender, /unblock-sender |
Write |
/csat skip |
Write |
/analyze, /summarize |
Write |
/generate-report |
Write |
/reply (saved replies) |
Write |
/billing, /upgrade, /cancel |
Admin |
/docs commands |
Admin |
/authenticate-domain, /set-from-address |
Admin |
If a collaborator uses a command above their access level, Scitor posts a comment explaining the required role.
Using GitHub Teams (organisations)
GitHub Teams are the cleanest way to manage support access at scale:
- Create a team in your GitHub organisation — e.g.
support-agents - Grant the team Write access to your support repository
- Add individuals to the team to give them access; remove them to revoke it
Repository permissions update immediately when team membership changes. No need to touch the repository settings directly.
Transferring ownership
If the person who installed Scitor leaves:
- Billing via Stripe: update the billing email in the Stripe billing portal. The
/billingcommand shows which provider manages your subscription. - Billing via GitHub Marketplace: GitHub’s billing is tied to the organisation account, not an individual user — no change needed.
- GitHub App installation: the installation is linked to the organisation, not a person. Manage it at
github.com/organizations/[your-org]/settings/installations.
As long as the repository and organisation remain active, Scitor continues working regardless of team changes.
Was this article helpful?