How Access Is Evaluated

Reqflo calculates effective permissions for the requested action, resource, and user. It then checks whether restricted dependencies block the action.

Decision flow

1. Confirm the user is an active member of the organization.
2. Identify the requested action.
3. Identify the target resource.
4. Check whether the action is administrative or security-sensitive.
5. Check org-level roles.
6. Check group-based access.
7. Check service-team access if the resource is service-controlled.
8. Check direct resource grants.
9. Check the resource's visibility, access mode, and risk level.
10. Check restricted dependencies.
11. Return allow or deny with a clear explanation.

Organization membership

Reqflo first verifies that the user is an active member of the organization.

If not, access is denied before resource-level rules are evaluated.

Action and target

Reqflo evaluates access for a specific action on a specific resource.

Examples:

• View a journey.
• Run a journey.
• Use an auth config.
• Attach a component.
• Manage OAuth scopes.
• Manage billing.

Administrative and security-sensitive actions

Some actions require org-level administrative privileges or security-specific roles.

Examples:

• Billing management.
• SSO configuration.
• SCIM configuration.
• OAuth scope changes.
• Secret administration.
• User role changes.
• Permission delegation.

Org roles, groups, service teams, and direct grants

Reqflo combines access from:

• Organization roles.
• Local and SCIM-managed groups.
• Service-team membership.
• Direct resource grants.

The result is the user's effective permission set.

Resource settings

Reqflo then evaluates the resource itself:

• Visibility
• Access mode
• Risk level
• Required permissions
• Owning service
• Attached components
• Required environments
• Required credentials

Restricted dependencies

A restricted dependency can block an action even when the user has access to the parent resource.

Examples:

• A journey depends on a restricted OAuth config.
• A run targets production.
• A template uses a secret-backed component.
• A workflow performs a destructive operation.

Journey execution checks

Running a journey may require access to:

• The journey.
• The related service.
• The selected environment.
• Required components.
• Required auth/config objects.
• Required OAuth scopes.
• Required secrets at runtime.
• Production or destructive execution privileges.

Each dependency is checked before execution starts.

Example denial messages

Reqflo should explain why an action is blocked.

Examples:

• "You can view this journey, but you cannot run it because it uses a restricted OAuth config."
• "You can run this journey in staging, but not production."
• "Only Security Admins can edit OAuth scopes."
• "This component is restricted to the Support Tier 2 group."
• "You have access to the journey, but not to one of its required components."

Allow or deny

Reqflo allows the action only when:

• The user belongs to the organization.
• The user has the required action permission.
• The resource's access mode allows the action.
• The resource's risk level does not require a missing privilege.
• All restricted dependencies allow the action.

If any required check fails, Reqflo denies the action and returns an explanation.