Reqflo Docs
Permissions

Permission examples

Practical examples for configuring common Reqflo access patterns.

Permission Examples

These examples show how Reqflo applies open catalog, controlled execution in practice.

Example 1: Open normal journey

Access:

  • View: everyone in org
  • Run: everyone in org
  • Edit: creator and service maintainers
  • Manage access: creator and service owners

Explanation:

This is appropriate for normal internal workflows that do not use restricted credentials, production environments, or destructive actions.

The journey is easy to discover and reuse. Editing and access management still stay with the creator or owning service team.

Example 2: Production refund journey

Access:

  • View: everyone in org
  • Run: Payments Support Leads
  • Edit: Payments Service Owners
  • Manage access: Payments Service Owners and Security Admins

Risk level:

  • Production
  • Destructive or mutating

Explanation:

The journey is discoverable, but execution is restricted because it can affect production payment data.

Users can understand the workflow exists without being allowed to trigger refunds.

Example 3: Restricted OAuth component

Access:

  • View metadata: everyone in org
  • Use: selected groups
  • Attach: service owners
  • Manage scopes: Security Admins
  • Manage secrets: Security Admins

Explanation:

The component can be understood and referenced without exposing privileged use, scopes, or secrets.

Security Admins retain control over sensitive OAuth scope and secret management.

Example 4: SCIM-managed support access

Mapping:

  • IdP group: support-tier-2
  • Reqflo group: Support Tier 2

Access:

  • Run selected diagnostic journeys.
  • Use selected read-only production configs.
  • View related service resources.

Explanation:

SCIM handles membership. Reqflo handles what the group can do.

When a support engineer joins or leaves the identity-provider group, their Reqflo access follows automatically.

Example 5: Service-controlled Checkout resources

Checkout service team:

  • Owners can manage service access.
  • Maintainers can edit service-owned resources.
  • Runners can execute approved service workflows.
  • Viewers can discover and inspect resources.

Explanation:

Service-controlled access follows ownership of the related service.

This keeps Checkout maintenance with the Checkout team while still allowing targeted access for support, QA, security, or release groups.

Example 6: Blocked run due to restricted dependency

Situation:

  • User can view a journey.
  • User has run access to the journey.
  • The journey uses a restricted production credential.
  • User does not have use access to that credential.

Result:

The user cannot run the journey.

Message:

You can view and run this journey, but this run requires a restricted production credential that you do not have access to.

Explanation:

The parent journey is not the only thing being checked. Reqflo also evaluates dependencies required for the selected run.

This keeps the catalog open while preventing unauthorized production execution.

On this page