In this post, we'll discuss the differences between teams vs. groups and when to use them.
Teams vs. Groups
In Opal, a team typically reflects actual teams in your organization, like the DevOps team or Design team. Teams can own a resource, meaning the admins of teams can approve or reject access requests to the resources it owns.
Opal shows you which collections are teams.
A group defines a group of permissions that are related to each other and doesn't correspond with your organizational structure (although it certainly can—it's flexible to meet your organization's needs). Unlike teams, however, they can't own or approve access to any permissions or groups.
Opal shows you which collections are groups.
✏️ NOTE: Teams have two key roles—admins and members. Both roles have access to resources within the group, but admins of teams have the critical role of approving and denying requests to the team or permissions/groups the team owns.
To summarize, teams own resources and groups do not. The admin users in a team can reject or approve requests to any resources the team owns.
Why Use Groups?
You can think of Groups as a second layer of organization. Although users in groups can't approve or deny requests, they have access to a set of resources. If someone adds a user to a group, Opal automatically gives that user access to resources within the group. This is useful if your team has varying levels of access. For example, you can easily create different groups for access to more sensitive resources like production or staging environments.
👥 On-Call Groups
You can also integrate groups with on-call rotations. These types of groups have a different icon, and users can't directly request access to these special groups.
Instead, Opal integrates with your on-call provider, only giving access to users on-call. Once users are no longer on-call, Opal automatically removes their access.
Opal shows you which collections are on-call groups.
NEXT UP ➡️
Congrats! You've mastered groups in Opal. Next, let's learn about the Opal CLI.