Service Teams

Service teams model ownership of services in Reqflo.

A service team represents the people or groups responsible for maintaining a service and the resources owned by that service.

What service teams do

Service teams help determine who can:

• Manage service settings.
• Maintain service-owned journeys.
• Edit service-owned request templates.
• Attach approved components.
• Manage service-scoped configurations.
• Run approved service workflows.
• Review service access and evidence.

Membership

Service teams can include:

• Users
• Groups
• SCIM-managed groups

Using groups inside service teams is recommended when membership is managed by an identity provider.

Service-team roles

Service teams can assign roles such as:

• Owner
• Maintainer
• Runner
• Viewer
• Auditor

These roles apply to the service and service-controlled resources.

Permission inheritance

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

Examples:

• A Checkout journey can inherit edit access from Checkout service maintainers.
• A Checkout request template can inherit view access from Checkout service viewers.
• A Checkout diagnostic workflow can inherit run access from Checkout service runners.

Restricted dependencies still apply. A Service Runner may be able to run an approved staging workflow but not a production workflow that requires a restricted credential.

Checkout ownership

The Checkout service is owned by the Checkout service team.

Checkout service owners can:

• Manage service settings.
• Edit service-owned journeys.
• Manage service-owned components.
• Manage access for service-scoped resources.

Checkout service maintainers can:

• Edit normal Checkout resources.
• Attach approved components.
• Maintain journeys and templates.

Support access without ownership

Support Tier 2 can receive run access to selected Checkout diagnostic journeys without becoming a Checkout service owner.

This is useful when support needs to operate specific workflows but should not manage Checkout service settings or edit Checkout-owned resources.

Security access without ownership

Security Admins can manage OAuth scopes or secrets for Checkout-related configs without being part of the Checkout service team.

Security access is separate from service ownership because security-sensitive controls often need central governance.

Recommended practices

• Use service teams for ownership and maintenance.
• Use groups for membership where possible.
• Keep service ownership separate from cross-functional operational access.
• Let support, QA, release, and security groups receive targeted grants without making them service owners.
• Review Service Owner and Service Maintainer assignments regularly.