Managing Users
Add, edit, and remove users from your organization. Manage roles, team assignments, and monitor individual progress.
User List
The Users page shows all organization members in a sortable, searchable table. Each row displays the user's name, email, role, team, last login date, and current status.
| Column | Description |
|---|---|
| Name | User's first and last name |
| Login email address | |
| Role | Org Admin or Learner |
| Team | Team the user belongs to (if assigned) |
| Last Login | Date and time of the user's most recent login |
| Status | Active (has logged in) or Invited (pending first login) |
Adding Users
There are two ways to add users to your organization:
Manual
Click "Add User" and enter the user's email, first name, last name, and role (Learner or Org Admin). The user will receive an invitation email to join the platform.
SCIM Provisioning
Set up SCIM to automatically sync users from your identity provider (Okta, Azure AD). Users are created and deactivated automatically as your directory changes.
Seat Limits
Your organization has a maximum number of seats based on your plan. Adding users beyond your maxSeats limit will fail with an error. Check your current seat usage on the Users page header.
Editing Users
Organization admins can edit the following user properties:
| Field | Editable |
|---|---|
| First Name / Last Name | Yes |
| Yes | |
| Role | Yes |
| Team | Yes |
| Password | No — managed via magic code or SSO |
Removing Users
When you remove a user from your organization, the user is deactivated and can no longer log in. Their training progress data is retained for reporting purposes. Removing a user frees up a seat in your organization's plan.
Roles
SecureCodingHub supports two organization-level roles:
| Role | Can Do |
|---|---|
| Org Admin | Manage users, teams, assignments, view dashboard, configure SSO/SCIM/SCORM |
| Learner | Complete challenges, view own progress, manage preferences |
Seat Management
Your organization has a maxSeats limit determined by your subscription plan. The current usage is displayed at the top of the Users page (e.g., "124/150 seats"). When you approach your seat limit, a warning banner appears. Contact your account manager to upgrade your plan if you need additional seats.
User List Interface
Here is what the user management page looks like:
Add User Modal
Clicking "Add User" opens the following form:
Why thoughtful user management matters
Most organizations do not notice seat sprawl until it shows up on the renewal invoice. A handful of contractors finish a project and stay in the directory. A team reorganizes and the old team membership is never cleaned up. Two engineers leave the company but the offboarding ticket missed the training platform. Within a year, twenty percent of the seats your finance team is paying for belong to people who do not log in, and the accounts that remain do not reflect who is actually on the team today.
Seat sprawl is also a security problem. Every inactive account is a credential that an attacker can target through password reuse, phishing, or session hijacking. The same SSO that grants access to your code review platform may grant access here, and an account no one is watching is the easiest one to compromise quietly. Treating the user list as a living artifact, not a backlog, closes that gap before it becomes an incident.
Auditing user-team mapping quarterly
A simple quarterly review keeps the roster honest. Export the user list, filter on last login older than ninety days, and ask the line manager whether each person should remain. Cross-check the Team column against your HR system or org chart — anyone whose team membership no longer matches their actual role is a candidate for reassignment. Pay particular attention to users without a team set, since they typically slip through team-level assignments and skew completion rates downward without anyone noticing.
If you use SCIM provisioning, most of this work happens automatically. Group membership in Okta or Azure AD flows through to the team mapping, and deprovisioning a user in the identity provider deactivates them in SecureCodingHub on the next sync cycle. The audit then becomes a sanity check rather than a manual reconciliation.
Why deprovisioning matters for compliance evidence
PCI DSS 8.1.3 and ISO 27001 control A.9.2.6 both require that access for terminated users be revoked promptly. Auditors look for evidence — a timestamp showing when the account was deactivated, ideally tied to the offboarding date in HR. SecureCodingHub retains the deactivation date and the completed training history of removed users, which means the deprovisioning event itself is auditable and the training record survives for the retention window your policy requires.
For teams running secure coding training as part of their PCI DSS 6.2.2 evidence pack, the user list also doubles as proof of who was in scope during the audit period. Keeping it tidy makes the audit conversation shorter and the evidence cleaner.