Access

Getting access to the application typically follows one of two flows:

1. Users request access to the application through the sign up link (/auth/signup)
2. Users are invited to the application by an admin

Given two possible flows, it's possible for a request to exists while an account already exists. This is harmless and can easily be decluttered through deleting extra requests.

Requesting Access

When a users visits your app they have the option to sign up through the login link. Sign up

Completing the short form will creates the request which can be acted upon by anyone with CreateUser or DeleteUser in the admin/access-requests. Admin Access Requests There are a few aspects worth noting here:

• Only requests from allowed domains are accepted (see Authentication, Allowed Domains). A visitor from a domain outside the list is rejected at submission with a clear "this email domain is not approved — contact your administrator" message; no request is created.
• The requester receives a confirmation email ("we received your request") immediately, and administrators who hold the CreateUser right are notified by email that a request is waiting (this is the New Access Request entry in each admin's profile communication preferences — on by default, opt-out per admin).
• Only one request can be made by each email address
• The requestor's message is replaced upon resubmission
• Declined requests are also deleted, and the requester is not notified — silence on decline is deliberate. The admin right to viewDeleted is needed to see deleted requests. Undeleting a request requires the admin right createAccessRequest
• Approving a request creates the account and sends the invitation email. The email contains a secure link where the user sets their own password; once set, their email address is validated and they can log in. If an account already existed for that address, approval flips it to approved and sends an "account approved" email instead. The result toast reports exactly what happened per request: created and invited, existing account approved, blocked (domain not allowed), or failed.
• To allow SSO, a user must exist. SSO details are attached to the user's profile but all details are hidden except for the validation that the user is able to use it. Once the user is logged in they should be able to trigger the SSO flow which associates to the account. Permissions are managed within the application rather than through third party OAuth providers.

Giving Access

Users with the CreateUser admin right can create accounts directly through the Admin → Users menu. For bulk operations, a .csv template is available in the upper right of the Add User panel.

A directly-created account starts with no usable password and an unvalidated email. To get the person in, use the Send invite action on their row in Admin → Users — it emails them a secure link where they set their own password and validate their address in one step. The action is only available while the account's email is unvalidated; if the invitation went to spam or was deleted, run Send invite again to issue a fresh link. Once an account is validated, Send invite is disabled — from that point the person uses the normal Forgot password flow.

While it is possible to create an account outside of the Allowed Domains, invitation and notification email to that address will be blocked by the domain allowlist — add the domain first.

SSO

Under the default settings, users will need to create an account. Upon navigating back to the login page, they'll see a message to Add SSO. (This option must be activated by the administrator first. See Authentication, Customizing Admin Settings.) Logging in a second time through SSO will automatically associate the SSO settings to the user's account.

Alternatively, if Allow Registration is active in the application settings, users can sign up with SSO directly. This creates the account and an access request in one step — the person then sees an "account awaiting administrator approval" notice on the login page until an admin approves the request (admins holding CreateUser are notified by email when it arrives). The account also carries a random secure password which can be reset and used provided the option to login through username/password is active.

SSO settings can be removed from a user's profile by any user with the UserUpdate admin right from the './admin/users' page.