Reqflo Docs
Permissions

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.

ActionMeaning
viewSee the resource, metadata, configuration summary, or evidence
useUse a resource as a dependency in another resource or run
runExecute a runnable resource
editModify the resource
administerManage settings, access, ownership, scopes, secrets, billing, SSO, SCIM, or integrations

View access is separate from use, run, edit, and administer access.

Default behavior

AreaDefault behavior
Normal resourcesVisible to org members
Normal reusable workflowsRunnable by org members unless dependencies are restricted
Service-owned resourcesManaged by service owners and maintainers
Production credentialsRestricted
SecretsRestricted
OAuth scope changesRestricted
BillingAdmin-only
SSO/SCIMAdmin-only
Integration configurationAdmin-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.

On this page