Managing Users

User List

The Users page shows all organization members in a sortable, searchable table. Each row displays the user's name, email, team, role, and last login. Disabled users are flagged inline with a small DISABLED pill — there is no separate status column. An Export CSV button at the top of the page downloads the full user list with progress totals.

Adding Users

There are two ways to add users to your organization:

Seat Limits

Your organization has a maximum number of seats based on your plan. Adding a user beyond that cap fails with the error Seat limit reached (N). Contact support to increase. — the Users page itself does not surface a live seat counter today; use the Reports page or the public API GET /api/public/v1/org to read maxSeats against the current user count.

Editing Users

Click a user row to open the user detail page; the Edit button opens a modal that lets organization admins change the following four properties. Every field is required and the edit acts as a full replace — to keep a field unchanged, leave the current value in place.

Removing Users

The Remove action on the user detail page deletes the user record itself. Once removed, the person can no longer sign in. Removing a user frees up a seat against your maxSeats cap.

The user's historical data — practice challenge results, learn scenario progress, assignment completions, earned certificates — is not erased from the database, because those tables do not cascade-delete with the user record. In practice, though, that data stops being visible: every report, leaderboard, certificate verification, and user detail page joins through the user record to display it, so once the user row is gone the rows hang around as orphans that the UI does not surface.

Re-adding the same email after a removal creates a brand-new user with a new internal id. The old orphaned rows are not reattached — there is no "restore" path in the admin UI.

If you want to keep the user's training history visible for evidence retention, compliance audits, or rehire scenarios, do not use Remove. Either deprovision the user upstream through SCIM (which sets them inactive but keeps the user row in place) or just leave the account alone — they cannot sign in if their mailbox no longer receives the magic code.

Roles

SecureCodingHub supports two organization-level roles:

Seat Management

Your organization has a maxSeats limit determined by your subscription plan. There is no live seat counter on the Users page header today; if you need to monitor usage, read it from the public API (GET /api/public/v1/org returns maxSeats) and compare against the current user count. Contact your account manager to raise the cap 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. The role picker uses two side-by-side cards instead of a dropdown:

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 timestamped event showing when the account stopped being able to sign in, ideally tied to the offboarding date in HR. The Remove button satisfies access revocation, but it also deletes the user record, which means their completed training stops being visible in reports — the rows still exist as orphans but no UI surfaces them. If your audit needs that history to keep showing up as evidence, deprovision through SCIM (which sets the account inactive while keeping the user record in place) rather than using Remove. The audit log records either action.

For teams running secure coding training as part of their PCI DSS 6.2.2 evidence pack, the user list doubles as proof of who was in scope during the audit period. Pull a snapshot at audit time — either from the Export CSV button or via the public API — and keep it alongside the rest of your evidence pack.