Roles & Permissions
SecureCodingHub uses role-based access control inside each organization with two roles. Each role has a defined set of permissions across the admin surfaces and learner experience.
Role Overview
Every user in your organization is assigned one of two roles. The internal enum values are org_admin and learner; the admin UI shows them as the readable names below.
| Role | Description |
|---|---|
| Org Admin | Organization-level administrator. Manages users, teams, assignments, custom courses, SSO, SCIM, SCORM, API keys, webhooks, audit log, compliance reports, and organization settings. Has access to the admin dashboard. |
| Learner | Standard user role for all developers. Completes practice challenges and learn scenarios, tracks personal progress, earns XP, and manages their own stack preferences. |
Permissions Matrix
The following table shows which permissions are available to each role:
| Permission | Org Admin | Learner |
|---|---|---|
| View admin dashboard | ✓ | ✗ |
| Manage users (add, edit, remove) | ✓ | ✗ |
| Manage teams | ✓ | ✗ |
| Create and manage assignments | ✓ | ✗ |
| Build and manage custom courses | ✓ | ✗ |
| Configure SSO | ✓ | ✗ |
| Configure SCIM provisioning | ✓ | ✗ |
| Generate SCORM packages | ✓ | ✗ |
| Manage API keys | ✓ | ✗ |
| Manage webhook endpoints | ✓ | ✗ |
| View audit log | ✓ | ✗ |
| View compliance dashboards | ✓ | ✗ |
| Generate compliance / training reports | ✓ | ✗ |
| Edit organization settings (leaderboard, threshold) | ✓ | ✗ |
| Complete practice challenges | ✓ | ✓ |
| Complete learn scenarios | ✓ | ✓ |
| View own progress and assignments | ✓ | ✓ |
| View leaderboard (when org allows it) | ✓ | ✓ |
Changing Roles
Org Admins can promote a learner to Org Admin or demote an org admin back to Learner within their organization. Role changes take effect immediately on the user's next request. Every role change is written to the audit log with the actor, target, and timestamp.
Best Practices
Minimize Org Admins
Keep the Org Admin count to 2-3 per organization. This limits the surface area for accidental misconfiguration and keeps audit trails clean.
Learner for Developers
Use the Learner role for all developers. They get full access to training content, progress tracking, and stack preferences without any admin capabilities.
Choosing roles for your org
Role design inside a training platform feels lower-stakes than role design inside production systems, and that is exactly why it tends to be done carelessly. The training platform holds data about who knows what, which teams are weakest on which topics, and which engineers have completed mandatory compliance training. That data is sensitive in its own right — both as competitive information and as evidence in audit conversations — and the role model should reflect that.
Org Admin versus delegating to team leads
The temptation in growing organizations is to make every engineering manager an Org Admin so they can manage their own teams without filing tickets. The cost of that pattern shows up later. Org Admins can view every team's data, not just their own, which means a manager can see how a peer's team is performing without that peer's knowledge. They can also reassign users between teams, change deadlines on assignments they did not create, and modify SSO configuration. For most organizations, two or three Org Admins is the right ceiling — typically the head of engineering or AppSec plus one or two designated administrators.
For day-to-day team-level operations, the better pattern is to keep team leads as Learners and give them the dashboard filter for their team. They get the visibility they need without the configuration power they do not. If a team lead needs to create an assignment for their team, the Org Admin can do it in a couple of minutes — far cheaper than the long-term cost of granting standing administrative access to a wider group than necessary.
Least privilege and audit logging
The principle of least privilege applies inside the training platform just as it does anywhere else. Every additional Org Admin is one more credential whose compromise lets an attacker read your training data, modify your SCIM configuration, or quietly grant their own external account admin access. Practical least privilege here means defaulting new hires to Learner, promoting only when the operational need is clear, and demoting promptly when someone changes role.
Role changes and significant administrative actions are recorded with timestamps and actor identity for the same reason that production systems log privileged actions. When something goes wrong — a user is removed who should not have been, an assignment is changed days before an audit, a team is deleted by mistake — the audit log is the artifact that lets you reconstruct what happened. Keep that in mind when granting admin rights, since the audit trail will eventually be read by someone, and a small admin roster makes the log readable. For details on managing the people inside these roles, see Managing Users.