Docs/Admin Guide/Teams

Teams

Organize your users into teams by department, project, or role. Teams make it easy to assign training to groups and track progress by team.

Creating a Team

Navigate to the Teams page from the admin sidebar, then click the "Create Team" button. Enter a team name and click save. Teams are flat — there is no hierarchy or nesting. Each team is a simple group of users.

Managing Members

Add members to a team from the Users list. Each user can belong to one team at a time — assigning a user to a new team automatically removes them from their previous team. To remove a member, click the × button next to their name in the team detail view.

SCIM Group Sync

If you use SCIM provisioning, groups from your identity provider (Okta, Azure AD, etc.) automatically sync as teams in SecureCodingHub. The ExternalGroupId field maps to the group identifier in your IdP, ensuring teams stay in sync when groups change in your directory.

Note: When SCIM is enabled, teams synced from your IdP are managed externally. Manual edits to SCIM-synced teams will be overwritten on the next sync cycle.

Assigning Training to Teams

When creating an assignment, select "Team" as the assignee type and choose the target team. All current members of the team will receive the assignment. Users who join the team later will also automatically receive the assignment — no need to re-assign.

Teams Overview

Here's what the Teams page looks like in the admin panel:

app.securecodinghub.com/admin/teams
Teams (4)+ Create Team
Backend Team
12 members
Frontend Team
8 members
Mobile Team
5 members
DevOps
6 members

Team Detail

Click on a team to see its members and manage the roster:

app.securecodinghub.com/admin/teams/backend-team
Backend Team12 members
Members
Sarah Chensarah.chen@company.comOrg Admin×
James Parkjames.park@company.comLearner×
Emma Wilsonemma.wilson@company.comLearner×
Alex Kumaralex.kumar@company.comLearner×

Deleting a Team

Deleting a team removes the team entity but does not delete the users within it. All members become unassigned and can be added to a different team. Any active assignments targeting the deleted team will remain but will no longer apply to new users.

Designing your team structure

There is no single correct way to model teams. The structure that works for a fifty-engineer company will not scale to five hundred, and the structure that works for a product-led organization will not match a services consultancy. Before you create your first team, decide which signal you most want to surface at the team level — language proficiency, product ownership, or seniority — because that decision determines which taxonomy to follow.

Three common taxonomies

By language or stack. Teams like Backend Java, Frontend TypeScript, and Mobile Swift work well when training content is language-specific and when you want to compare two backend groups against each other. The downside is that engineers who work across stacks (a common pattern in smaller orgs) have to be placed in their primary stack and the secondary skill is invisible.

By product line. Teams like Payments, Identity, and Checkout match how engineering work is actually organized in most product companies. This taxonomy makes it easy for a product manager or security lead to look at the dashboard and answer the question "how is the Payments team progressing on PCI-relevant training" without filtering. The trade-off is that comparing language proficiency across products requires cross-cutting reports.

By seniority or role. Teams like Senior Engineers, Engineers, and Junior Engineers help when training paths differ by experience level. This works well alongside one of the two taxonomies above as a secondary grouping, less well as the only one.

Multi-squad developers and team-level metrics

Each user belongs to exactly one team at a time, so engineers who genuinely split their time between two squads need a judgment call. The simplest rule is to assign them to the team that owns the majority of their work this quarter and revisit the mapping during your quarterly user-list review. If a developer rotates often, place them on their home team and rely on individual assignments for the rotation work rather than juggling team membership every few weeks.

At the team level, the metrics that matter most are completion rate against assigned training, average score per topic, and the count of active users in the last thirty days. The first tells you whether the team is doing the work, the second tells you whether they are learning from it, and the third tells you whether the team is engaged at all. A team with a high completion rate but low active-user count usually has one or two people carrying the whole roster — worth investigating in your next one-on-one with the team lead.

Next steps: Learn how to assign training to your teams in the Assignments guide.