Users and groups

ScaiDrive accounts represent people; groups are bundles of accounts you can grant access in bulk. Both live under People in the admin console.

How accounts get created#

Three paths:

1. Self-sign-up via SSO. A user authenticates against your IdP for the first time; ScaiDrive creates an account on the fly. Default — the most common case.
2. SCIM push. Your IdP (Okta, Entra ID, Google Workspace) pushes user create/update/delete events to ScaiDrive. See SCIM provisioning.
3. Manual. People → Users → New user. Useful for service accounts, contractors, or pre-provisioning before someone's first sign-in.

You can mix all three; ScaiDrive matches by SSO subject (sub) claim, so a user pre-created via SCIM gets linked automatically when they first sign in via SSO.

User states#

Move between states from the user's detail page. Suspending a user is the right answer when an account is compromised or someone is offboarding — it preserves their data while immediately denying access. Deleting is irreversible and removes the user from every share membership.

Per-user fields#

The fields you can edit on a user:

• Display name — what other users see in shares.
• Email — used for invitations and notifications. Doesn't have to match the SSO subject.
• Quota — hard cap on personal storage (GB). Defaults to the global per-user default from Settings.
• Role — user, admin, or superadmin. Default user. Admins can access the admin console for their tenant; superadmins can manage all tenants.
• Allowed devices — optional. Restrict which device kinds (desktop/mobile/web/api) the user can sign in from.
• MFA requirement — handled by your IdP, not ScaiDrive. You can flag a user as "must have MFA" and check the audit log for compliance.

Groups#

Groups exist to grant access in bulk. Common patterns:

• Org-chart groups — engineering, marketing. Sync these from your IdP via SCIM so they stay current.
• Project groups — Q2-launch, acme-customer. Hand-managed; delete when the project ends.
• Compliance groups — dlp-bypass, legal-hold-reviewers. Used by other ScaiDrive features to grant elevated capabilities.

Create at People → Groups → New group. Add members from the group detail page (search by name or paste a list of emails).

Once a group exists, you can add it as a member of any share with a role; everyone in the group inherits that access. Group membership changes propagate immediately — no re-share needed.

Bulk operations#

For larger orgs, the user list supports:

• CSV export — current users, status, last sign-in, quota usage. Useful for compliance reports.
• Bulk suspend — select multiple users, Suspend selected. Common for offboarding.
• Filter then act — filter by last-sign-in older than N days, then bulk-suspend or bulk-delete.

For automated provisioning at scale, use SCIM — bulk operations in the UI are for one-off cleanups.

Service accounts#

For automated pipelines that need to read or write ScaiDrive (a CI job, a backup script, an integration), create a service account:

1. People → Users → New user → tick Service account.
2. Skip email; service accounts don't sign in via SSO.
3. After creation, go to the user → API keys → Issue key. The key is shown once; copy it.
4. Use the key with the Authorization: Bearer <key> header in API calls.

Service accounts can be added to shares like regular users. Scope them to the minimum shares they need.

Quotas#

A user's quota caps personal-share usage. Shares have their own quotas (see Shares and quotas). When usage approaches the cap, the user gets a warning email; when usage hits the cap, new uploads are blocked.

Quota changes take effect immediately; the user's current usage isn't recomputed on the spot — it updates within an hour via the background quota job.

What's next#

• Shares and quotas.
• SCIM provisioning.
• Identity providers.