Understanding users and teams

CloudBees Unify supports three authentication methods for user accounts: GitHub OAuth, Google social accounts, and CloudBees credentials. Each method provides a different approach to user identity management and has specific implications for how users manage their accounts.

GitHub OAuth and Google social accounts leverage existing external identities, allowing users to sign in with credentials they already manage. This approach simplifies the sign-up process and reduces password management burden for users. However, it also means that multifactor authentication and password policies are controlled by the external provider, not CloudBees Unify.

CloudBees credentials require users to create and manage a separate username and password specifically for the platform. This approach gives administrators more control over authentication policies, including the ability to enforce multifactor authentication directly within CloudBees Unify. Users who choose this method must manage an additional set of credentials but gain independence from external providers.

Once a user creates an account using one authentication method, they must continue using that same method to sign in. The platform does not support switching between authentication methods after account creation, as each method represents a distinct identity within the system.

Teams in CloudBees Unify group users with common permissions, providing a scalable approach to access control that grows with organizational needs. Rather than managing permissions for individual users across multiple projects and resources, administrators define teams with specific permission sets and assign users to appropriate teams.

This team-based model scales more effectively than individual permission management because it reduces administrative overhead as organizations grow. Adding a new user becomes a matter of assigning them to the correct teams, rather than configuring multiple individual permissions. Similarly, changing a user’s role typically involves moving them between teams rather than modifying numerous individual permission settings.

Teams connect directly to organizational structure and project needs, allowing administrators to mirror real-world reporting relationships and project assignments in the platform’s access control system. For example, a development team working on a specific application can have a corresponding CloudBees Unify team with appropriate permissions for that project’s resources.

CloudBees Unify automatically creates two system-generated teams for every organization: User (System) and Admin (System). These teams provide standardized permission sets that simplify user onboarding and ensure consistent access patterns across organizations.

User (System) teams grant read-only access to all functionality within the tenant organization. This permission level allows team members to view projects, monitor build status, and access reports without the ability to modify configurations or trigger actions. Admin (System) teams provide full administrative control over all functionality within the tenant organization, including access control management, resource creation and configuration, and user invitations.

System teams serve as the foundation for basic access control, handling the most common permission scenarios without requiring custom configuration. New users can be immediately assigned to the appropriate system team based on their intended role, providing instant access to necessary resources.

Custom teams become valuable when organizations need permission sets that don’t match the system team patterns. For example, a team might need the ability to modify specific pipelines but not create new ones, or access certain projects but not others. Custom teams allow administrators to define these specialized permission combinations and assign them to users with specific needs.

Team membership grants permissions within specific organizations, and these permissions are strictly scoped to the granting organization. A user might hold Admin (System) permissions in one organization while having only User (System) permissions in another, reflecting different roles across different organizational contexts.

This organization-scoped approach enables users to participate in multiple organizations with different permission levels appropriate to their role in each context. For example, a consultant might have administrative access in their client’s organization while maintaining read-only access in their own company’s organization for reference purposes.

Multiple team memberships within a single organization work together to provide the union of all granted permissions. If a user belongs to both a custom team with pipeline creation permissions and another team with deployment permissions, they can perform both functions. This additive approach allows for flexible permission combinations without requiring complex custom team definitions for every possible scenario.

Team ownership enables non-administrative users to manage team membership independently, reducing administrative burden while maintaining organizational control. Team owners can add or remove users from their teams, update team descriptions, and manage day-to-day membership changes without requiring intervention from tenant administrators.

This delegation model reduces administrative overhead by pushing routine team management tasks to the people closest to the work. Project leads or team managers can directly control access to their resources without creating bottlenecks through central IT administration.

Team ownership works alongside tenant administration rather than replacing it. Tenant administrators retain full control over all teams and can modify team ownership, permissions, and membership at any time. Team owners cannot modify the fundamental permissions granted by their teams or change team ownership. They can only manage membership within the existing team structure.

Now that you understand how users and teams work in CloudBees Unify, you can: