Roles
The six built-in roles, what each one can do, and how members with several roles work.
Every member of a Prodgator organization has one or more roles. A member with several roles can do what any of them allows. Roles are sets of permissions, not a ladder: Security and Compliance are separate functions, and neither one includes the other or Developer. Release manager covers what Developer can do, and Org admin holds every permission.
The six roles
| Role | Who it is for | In short |
|---|---|---|
| Viewer | Stakeholders, auditors and anyone who only reads | Reads dashboards, pipelines, deployments, security findings and compliance results. Changes nothing. |
| Developer | Engineers who push code and run pipelines | Viewer, plus cancel and re-run runs, read failure logs, upload scan reports and re-check pull requests. |
| Release manager | Release and platform engineers who own gates and deployments | Developer, plus approve and roll back deployments, approve pull requests, override release policies, and manage gates, approver groups and release policies. |
| Security | Security engineers | Viewer, plus triage findings, upload scan reports, manage security platform connections and tracked branches, and read failure logs. |
| Compliance | Governance, risk and compliance | Viewer, plus manage compliance policies, run evaluations, answer deployments a Block compliance policy governs, create break-glass overrides and read the audit log. |
| Org admin | Owners and IT | Everything, including members, roles, billing, SSO and directory sync, integrations and API keys. |
A member can hold several roles, for example Developer and Security. Invitations can carry several roles, and so can directory group mappings: someone in several mapped groups gets every mapped role, not just one of them.
What each role can do
Rows are actions, columns are roles. The table is generated from the same permission list the product uses, so it matches what the product allows.
| Action | What it covers | Viewer | Developer | Release manager | Security | Compliance | Org admin |
|---|---|---|---|---|---|---|---|
| Pipelines | |||||||
| Cancel runs | Cancel GitHub Actions, GitLab, Bitbucket and Azure Pipelines runs that are still running. | Yes | Yes | Yes | |||
| Re-run runs | Re-run failed jobs of finished GitHub Actions, GitLab and Azure Pipelines runs, and re-run one finished GitHub Actions or GitLab job. | Yes | Yes | Yes | |||
| Read failure logs | Read the logs of failed runs and jobs. | Yes | Yes | Yes | Yes | ||
| Deployments | |||||||
| Approve deployments | Approve, reject and re-evaluate deployment gates. | Yes | Yes | ||||
| Roll back deployments | Start a rollback to an earlier deployment. | Yes | Yes | ||||
| Security | |||||||
| Upload security reports | Upload scanner reports and start Wiz or Snyk connector syncs. | Yes | Yes | Yes | Yes | ||
| Triage security findings | Dismiss, reopen, split and rejoin alerts, scan results and findings. | Yes | Yes | ||||
| Manage tracked branches | Choose which branches are scanned and tracked for security findings. | Yes | Yes | ||||
| Manage security connections | Connect and disconnect security scanning platforms. | Yes | Yes | ||||
| Compliance | |||||||
| View enforcement | See enforcement decisions, settings and break-glass overrides. | Yes | Yes | Yes | Yes | ||
| Run compliance evaluations | Start a compliance evaluation. | Yes | Yes | Yes | |||
| Manage compliance policies | Turn policies on or off, set enforcement modes and settings, and re-evaluate decisions. | Yes | Yes | ||||
| Answer a deployment that a Block compliance policy governs | Approve or reject it with a stated reason. | Yes | Yes | ||||
| Create break-glass overrides | Skip a compliance block in an emergency. Each override is recorded. | Yes | Yes | ||||
| Release policies and gates | |||||||
| Inspect policies | Open the evaluation details and results of a release policy. | Yes | Yes | Yes | Yes | Yes | |
| Re-check pull requests | Run the release policies again on a pull request. | Yes | Yes | Yes | Yes | Yes | |
| Approve pull requests | Approve a pull request that is waiting on a release policy. | Yes | Yes | ||||
| Override release policies | Let a deployment or pull request through although a release policy failed. | Yes | Yes | ||||
| Edit release policies | Create, edit, import and bind release policies. | Yes | Yes | ||||
| Edit approver groups | Create and edit approver groups. | Yes | Yes | ||||
| Edit gates | Create and edit gates and the deployment environments they link. | Yes | Yes | ||||
| See the member list | See member names and emails, for example to pick approvers. | Yes | Yes | ||||
| Docs, analytics and exports | |||||||
| Generate AI results | Ask for AI summaries and explanations. | Yes | Yes | Yes | Yes | Yes | |
| View SPACE metrics | Open the SPACE developer metrics. | Yes | Yes | ||||
| Share AI widgets | Share AI widgets with the organization and edit shared ones. | Yes | Yes | Yes | Yes | ||
| Export data | Start data exports and download them. | Yes | Yes | Yes | Yes | ||
| Integrations | |||||||
| Work with Jira issues | Create, link and unlink Jira issues. | Yes | Yes | Yes | Yes | Yes | |
| Manage custom adapters | Create and edit custom adapters and processing rules. | Yes | Yes | ||||
| Audit | |||||||
| Read the audit log | Open the audit log of changes to members, roles and settings. | Yes | Yes |
Every role can open the Dashboard, Pipelines, Gates, run details, Pull requests, Security, Compliance, Analytics, Activity and Notifications pages and change its own profile, notification and preference settings. Some pages also depend on your plan. For example, Security needs the Team plan, Compliance and SPACE need the Business plan, and the audit log needs Enterprise. See Plans and features.
Org configuration lives on the Organization page (). Org admins open every section. Compliance opens only the Audit log section, because it holds the audit log permission. The Admin Console is a separate tool for the people who run the Prodgator platform and is not part of any role.
Org admin only
These stay with the Org admin role and cannot be added to a custom role:
- members, roles and invitations
- identity: SSO, directory sync, verified domains and the break-glass admin
- API keys and billing
- integrations and connections, other than security platforms (which Security manages)
- organization, AI, notification delivery and Slack settings
- release policy override settings, pull request gate settings, sync and status checks
- the SPACE survey switch
- acknowledging provenance changes and managing the provenance allowlist
- deleting another member's shared AI widget and deleting the organization
Break-glass
Two things carry the name, and they have different owners.
- Compliance break-glass overrides let blocked deployments to one repository and environment through for a limited time. Compliance and Org admin create them, and answer a deployment that a Block compliance policy governs. Release managers and Security can see them but cannot create them, so the person who ships a release does not also approve an exception to the compliance bar it failed. Release managers keep release policy overrides, which follow the organization's override settings. Only an Org admin changes those settings.
- The break-glass admin is the one Org admin who can always sign in without SSO when SSO is required. An Org admin chooses them under Organization > Identity. See Directory sync and verified domains.
Pull request approvals
Who can approve a pull request follows the policy bound to it. When a policy names approvers, those people and groups can approve. Otherwise Release manager and Org admin can, and so can a custom role with the approve pull requests permission. See Read and approve.