Permission Concepts

Reqflo access is calculated from users, organizations, roles, groups, service teams, resource settings, and restricted dependencies.

User

A user is a person with an account in Reqflo. Users can belong to one or more organizations.

Users usually receive access through roles, groups, and service teams instead of individual exceptions.

Organization

An organization is the top-level tenant boundary. Users, groups, service teams, resources, integrations, secrets, environments, and billing settings belong to an organization.

A user must be an active member of the organization before Reqflo evaluates access inside it.

Role

A role is a reusable bundle of permissions.

Roles can exist at different scopes:

• Organization-level roles, such as Org Admin or Member.
• Service-level roles, such as Service Owner or Service Runner.
• Resource-level roles, such as Resource Maintainer or Resource Viewer.

Group

A group is a collection of users. Groups are the recommended way to manage access at scale.

Groups can be:

• Created locally in Reqflo.
• Provisioned and managed through SCIM from an identity provider.

Groups can receive roles, service-team assignments, and resource grants.

Service team

A service team models ownership for a service.

Service teams can include users and groups. They can receive service-level roles such as owner, maintainer, runner, viewer, or auditor.

Service-controlled resources can inherit access from the related service team.

Principal

A principal is anything that can receive an access grant.

Common principals are:

• User
• Group
• Service team
• Role

Resource

A resource is something in Reqflo that can be viewed, used, run, edited, or administered.

Examples:

• Service
• Journey
• Request template
• Environment
• Auth config
• Secret-backed component
• Mock
• Integration connection
• Billing setting

Grant

A grant gives a principal permission to perform one or more actions on a resource or resource scope.

Examples:

• Give Support Tier 2 run access to diagnostic journeys.
• Give the Checkout service team edit access to Checkout-owned templates.
• Give Security Admins manage-scopes access to OAuth configs.

Visibility

Visibility controls whether a resource can be discovered.

Reqflo supports:

• Org-visible resources, visible to organization members.
• Restricted visibility resources, visible only to selected principals.

Visibility does not automatically grant use, run, edit, or admin access.

Access mode

Access mode controls how permissions are evaluated for a resource.

Reqflo supports:

• Open
• Service-controlled
• Restricted

Risk level

Risk level describes the sensitivity of a resource or action.

Reqflo uses risk levels such as:

• Normal
• Sensitive
• Production
• Destructive

Risk level affects whether a resource can be used or run by default.

Effective permissions

Effective permissions are the final permissions a user has after Reqflo combines:

• Organization role
• Group membership
• Service-team membership
• Direct grants
• Resource visibility
• Resource access mode
• Resource risk level
• Restricted dependencies

Restricted dependency

A restricted dependency is a required resource that has tighter access than the thing the user is trying to run or use.

Examples:

• A journey that uses a production credential.
• A request template that depends on a restricted OAuth config.
• A runbook that attaches a secret-backed component.
• A workflow that targets a destructive production action.

A user may have access to the parent resource but still be blocked by a restricted dependency.

How the pieces fit together

Users belong to organizations. Users may belong to groups. Groups may be local or SCIM-managed. Service teams model ownership of services and can include users or groups. Principals receive grants. Resources define visibility, access mode, risk level, and required permissions.

Reqflo calculates effective permissions from all of those inputs, then checks restricted dependencies before allowing risky actions.