Managing users
Everything here is admin only, and every action writes an audit row naming who
did it.
Join requests
Section titled “Join requests”When someone signs up with your email domain and self-service signup is open, they land as a pending user and a join request appears for administrators.
Approving a request asks you which roles to grant. Grant the smallest set that
lets the person do their job — viewer is a perfectly good starting point, and
adding releaser later is one action.
An approval activates the account only if the person actually verified their email address. If they never clicked the link, approving records your decision but leaves the account inactive until they do.
Granting roles to a named person
Section titled “Granting roles to a named person”Three sources can give someone a role, and they are unioned:
| Source | Applies to | Use it when |
|---|---|---|
| Directory claim mapping | Anyone whose token carries a mapped group or app role | This is the default. Your directory stays the authority |
| Base roles | Every authenticated member of your organisation | You want a floor, typically viewer, for everyone who can sign in |
| Explicit user roles | One named subject or email address | Your directory cannot express the grant |
Explicit user roles are additive and cannot let anyone in. They are applied only after the token has been validated and your organisation resolved, so your directory remains the sole authority on who can sign in. They exist because some providers make claim-based granting impossible — most notably Google Workspace, whose ID tokens carry no group information at all.
Closing self-service signup
Section titled “Closing self-service signup”Under your organisation’s authentication policy you can turn public signup off. After that a colleague signing up with your domain is refused before any mail is sent — they are told to contact an administrator, and no pending account is created.
Most organisations close signup once single sign-on is configured, because from then on the directory is the way in.
Deactivating someone
Section titled “Deactivating someone”Deactivating a user ends their access immediately. Their audit history is kept — an audit trail that loses entries when someone leaves is not an audit trail.
If the person signs in through your identity provider, remove them there too. Removing the Seylo account without removing the directory grant means that under an open signup policy they can come back as a new join request.
Sessions and re-authentication
Section titled “Sessions and re-authentication”Sessions are cookie-based and expire. A password change invalidates existing sessions on their next refresh, so a compromised password does not leave a live session behind it.
- Roles and permissions
- Set up single sign-on
- Break-glass recovery — if nobody can sign in