Skip to main content

Users

Administration → Users manages who can reach your organization and what they can do in it.

Inviting someone​

Invite by email address and assign a role at the same time. Roles are described in

Screenshot pending

SCREENSHOT: the Users list with the invite action.

Roles and permissions - the short version is that most people are engineer or developer, and auditor is genuinely read-only and almost always what a compliance or leadership reader actually needs.

If you use single sign-on, users authenticate through your identity provider instead of holding a separate password. See Identity providers.

Scoping to a business unit​

A role says what someone can do. A business unit says what they can do it to.

Scoping a user to a business unit means they see findings and assets for that unit rather than the whole estate. This is what makes a findings queue usable for a team - an organization-wide list gets filtered past by everyone. See Business units.

Keeping the list honest​

Review it on a schedule. A user list is the thing that silently drifts: people change teams, projects end, and nothing about the platform notices.

Keep org_admin small. It can do everything within the organization, including changing other people's roles.

Remove access at the point someone leaves, not at the next review. If you use single sign-on this largely takes care of itself - disabling the account at your identity provider is what actually ends access - which is one of the better reasons to use it.

Users and API keys​

A departing person's access is not only their account. If they created API keys, those keys belong to the organization and keep working.

Keys are deliberately not tied to a person - a key that dies when someone leaves takes a pipeline with it, usually at the worst moment - but it means offboarding has two steps, not one. Review keys when someone with access to them leaves.

API​

The endpoints behind this section are in the API reference.

Next​