Permissions overview
Understand Reqflo's open catalog, controlled execution access model.
Permissions Overview
Reqflo uses an access model built around one principle:
Open catalog, controlled execution.Most internal users should be able to discover normal resources, understand what exists, and reuse safe workflow building blocks. Permissioning should protect risky actions without making the product annoying to use.
That means Reqflo separates discovery from execution. A user may be able to view a journey, request template, service, or component, but still be blocked from running it, using it, editing it, or changing its access when the action depends on restricted credentials, production systems, sensitive components, privileged OAuth scopes, secrets, or destructive behavior.
Why normal resources are visible by default
Reqflo is most useful when teams can see the workflows, services, request templates, mocks, environments, and validation evidence that already exist.
Open discovery helps teams:
- Reuse existing journeys instead of duplicating them.
- Understand which services and workflows are covered.
- Find examples before creating new templates.
- Review validation evidence across teams.
- Coordinate API workflow ownership.
Normal internal resources should be easy to find unless there is a specific reason to hide them.
Why risky execution paths are controlled
Some actions create real risk. Reqflo applies tighter controls when a workflow or component can access sensitive systems, credentials, production data, external integrations, billing, security settings, or privileged scopes.
Controlled execution protects:
- Production credentials and production environments.
- Secrets and secret-backed components.
- OAuth scopes and external integration privileges.
- Destructive or mutating production runs.
- Billing, SSO, SCIM, and user administration.
- Permission delegation and access management.
Discovery vs execution
View access answers: "Can I see that this exists?"
Execution access answers: "Can I use this to do something?"
A user can often view a resource without being allowed to use it. For example:
- A user can view a production OAuth config exists without being able to use it.
- A user can view a journey without being able to run it in production.
- A user can inspect an approved component without being able to edit its scopes or secrets.
Actions
Reqflo evaluates access by action.
| Action | Meaning |
|---|---|
| view | See the resource, metadata, configuration summary, or evidence |
| use | Use a resource as a dependency in another resource or run |
| run | Execute a runnable resource |
| edit | Modify the resource |
| administer | Manage settings, access, ownership, scopes, secrets, billing, SSO, SCIM, or integrations |
View access is separate from use, run, edit, and administer access.
Default behavior
| Area | Default behavior |
|---|---|
| Normal resources | Visible to org members |
| Normal reusable workflows | Runnable by org members unless dependencies are restricted |
| Service-owned resources | Managed by service owners and maintainers |
| Production credentials | Restricted |
| Secrets | Restricted |
| OAuth scope changes | Restricted |
| Billing | Admin-only |
| SSO/SCIM | Admin-only |
| Integration configuration | Admin-only or integration-admin-only |
Practical rule
Keep normal catalog resources open. Restrict the actions that create risk.
This keeps Reqflo useful for discovery and collaboration while protecting sensitive execution paths.