Roles
Understand organization, service, and resource-level roles in Reqflo.
Roles
Roles are reusable bundles of permissions. They make access easier to reason about than assigning many individual permissions directly to users.
Reqflo uses roles at multiple scopes:
- Organization roles for tenant-wide administration and default access.
- Service roles for ownership and maintenance of service-scoped resources.
- Resource roles for specific resources.
Organization roles
Organization roles apply across the organization.
| Role | Intended use |
|---|---|
| Org Owner | Full administrative ownership |
| Org Admin | User, group, and organization administration |
| Security Admin | SSO, SCIM, secrets, OAuth scopes, and security-sensitive settings |
| Billing Admin | Billing and plan management |
| Integration Admin | External integration setup and configuration |
| Member | Standard internal user |
| Viewer | Read-only internal user |
Org Owner
Org Owners have full administrative control. They can manage organization settings, users, groups, roles, billing, integrations, and access delegation.
Use this role sparingly.
Org Admin
Org Admins manage organization administration, including users, groups, and broad workspace settings.
Org Admin does not have to imply full control over every security-sensitive function if Security Admin is separated.
Security Admin
Security Admins manage high-risk security settings such as:
- SSO
- SCIM
- Secrets
- OAuth scopes
- Secret-backed auth configs
- Security-sensitive access policies
Billing Admin
Billing Admins manage billing, plan, usage, and payment configuration.
Integration Admin
Integration Admins manage external integrations such as Jira, GitHub, Linear, Harness, and other providers.
They can configure connections and integration settings, but should not automatically receive unrelated billing or security administration rights.
Member
Members are standard internal users. They can discover normal catalog resources and use normal resources unless restricted dependencies block the action.
Viewer
Viewers are read-only internal users. They can inspect normal visible resources but cannot run, edit, or administer them unless separately granted.
Service-level roles
Service roles apply to a service and service-controlled resources.
| Role | Intended use |
|---|---|
| Service Owner | Own service settings, access, and service-scoped administration |
| Service Maintainer | Maintain normal service-owned resources |
| Service Runner | Run approved service workflows |
| Service Viewer | Discover and inspect service resources |
| Service Auditor | Review service configuration, evidence, and access without changing it |
Service Owner
Service Owners can manage service settings, access, ownership, and service-scoped resources.
They are responsible for who can edit, run, or attach service-owned components.
Service Maintainer
Service Maintainers can edit normal service-owned resources, attach approved components, and maintain journeys, request templates, mocks, and service-owned configurations.
Service Runner
Service Runners can execute approved service workflows. Restricted dependencies may still require separate access.
Service Viewer
Service Viewers can discover and inspect service resources.
Service Auditor
Service Auditors can review service configuration, evidence, access, and change history without changing resources.
Resource-level roles
Resource roles apply to a specific resource.
| Role | Intended use |
|---|---|
| Resource Owner | Own the resource and manage access |
| Resource Maintainer | Edit and maintain the resource |
| Resource User | Use or run the resource when dependencies allow it |
| Resource Viewer | View the resource and metadata |
Role design principle
Use broad roles for common access patterns, then apply resource-specific grants only when needed.
Prefer groups and service teams over individual role exceptions.