Invitations

Pre-authorize email addresses to sign in to your organization, optionally with a branded email link.

Invitations are sent from the Users page: go to /admin/users and click Add user. The older /admin/invites bookmark still works — it redirects to Users and opens the same dialog.

Outstanding invitations are listed in the Users table itself, after the members — see Pending invites in the Users table.

Sending, revoking, and pre-configuring invites all require canInviteUsers (which also implies admin access). Pre-setting anything other than the role also needs canManageUsers — see Pre-configuring an invite.

How invitations work

Strata signs users in with Microsoft SSO. The invitation step pre-authorizes a specific work email — when that email signs in with their Microsoft account, the pending invite is consumed and their users row is linked to your organization with the role and database permission you specified.

You do not need to send an email. Two paths are supported:

• Send invitation — Strata sends a branded email from mail.kronisys.com with a sign-in link. Use this when you want the user to know they have been invited.
• Pre-authorize — Strata records the invite but sends no email. Use this when you have already told the user through another channel; their next SSO sign-in still picks up the pre-authorization.

The button label switches between Send invitation and Pre-authorize based on whether the Send email invitation checkbox is on.

Sending one invitation

1. Open /admin/users and click Add user.
2. Leave the selector on One person.
3. Enter the work email in the Work email field.
4. Pick a role from Assigned role. Roles appear as <name> · built-in or <name> · custom. The user role is pre-selected.
5. Decide whether to leave Send email invitation checked.
6. Click Send invitation (or Pre-authorize).

The invitee's default database permission is taken from the role's default_db_permission. To override individual settings before they first sign in, see "Pre-configuring an invite" below.

Note

The line "Database access for this role: …" under the role picker only appears when your organization has a SQL Server connection. Without one there is no database access to describe.

Inviting several people at once

Switch the selector at the top of the dialog to Several at once. You get a table of rows rather than a single free-text box, so each person is a real record instead of something you have to format correctly:

Five empty rows are there when you switch. Add another person appends more.

Validation runs across the whole set before anything is sent, so you see every problem at once rather than one per attempt. Rows are flagged when the address is malformed, duplicated within the batch, already a member of your organization, or already has a pending invite.

Invitations are then sent one at a time, and the toast reports how many went out. A row that fails does not stop the rest of the batch.

Assigning groups at invite time

Below the role picker, the Add user dialog shows a chip for each group in your organization. Selecting groups applies them to every address in the invite — the same shape as the role control above it — so you can land a whole new team in the right groups in one send. When each invitee first signs in, they are added to the selected groups automatically.

Note

A group that grants elevated permissions (one with an admin-granting role bound to it) is not auto-applied on invite sign-in — the invitee arrives with no verified granting authority, so Strata skips the privileged group fail-closed. Add such a group to the person by hand afterward, from Organization → Groups or their user row. See Binding roles to a group.

Pre-configuring an invite

Before the invitee signs in, you can wire up much of their account in advance from Configure before they join in the invite row's ⋯ menu. Anything you leave blank falls back to the invite default or the org default. The Pre-configure invitation modal exposes:

Everything except Role also needs the Manage users permission (canManageUsers), the same permission those controls need on a member's own page. A field left at its default needs nothing, so an admin with only canInviteUsers can still pin a role. Save preconfig checks every field; a refused save keeps the dialog open and says why in a red line under Identity — for example Setting database access on an invitation needs the Manage users permission. — or Could not check. Try again. when Strata could not check.

When the user signs in, the row is consumed and these values are applied before their first chat. Each one is checked again against the permissions of the admin who sent the invitation, as they stand at that moment — not those of whoever saved the pre-configuration. If that admin does not hold Manage users by then, every field except Role is skipped; anything that could not be applied is recorded in the audit log as user.preconfig_apply_failed, naming the fields.

Before late September 2026, a level set here also saved Auto-approve writes as Off on that connection when the invitee signed in. Someone who joined that way shows Off under Auto-approve writes on their Access tab; choose Role default (…) there to make it follow their role again. Invitations saved then that nobody has used yet no longer do this.

Note

The two switches under Identity here pin one invitee, not the organization. The org-wide versions of the same two decisions — plus timezone — are on Organization settings → Profile → Member profiles, and they apply to everybody. Set them there if the answer is the same for every member; use these only when one arriving person needs a different answer from the rest.

Note

Leaving Jira or Confluence ticked grants neither beyond what the organization and the invitee's role allow, and it does not connect anything. If your organization is in the "each person signs in" mode, the invitee still has to connect their own Atlassian account once from Settings → Apps; that single connection covers both products. In the "one organization account" mode there is nothing for them to connect. See Atlassian extensions.

Pre-config is most useful when you need a new hire to land in Strata already set up — for example a portfolio manager who should arrive with the right database connection attached at Viewer permission and a locked display name.

Note

The pre-config modal does not set the user's default AI model. Models are governed centrally: a user's available models are the intersection of what the organization, their role, and any per-user override allow. To narrow a single user's models, see Per-user governance.

Domain restriction

If you do not want invitations going to addresses outside your company, go to Organization → Profile → Invite domains. Type a domain and press Enter, or paste a list (commas, semicolons, spaces and new lines all separate entries; a leading @ is fine). When the list is not empty, the server rejects any invite whose recipient domain is not in it.

Each domain becomes a chip. An entry that is not a domain turns red, and nothing saves until you fix or remove it, so a restriction can never quietly turn into "anyone may be invited".

Revoking an invitation

In the Users table, open the invite row's ⋯ menu and choose Revoke invitation. The confirmation reads:

Revoke this invitation? <email> won't be able to sign in until you send a new invitation.

Revoking an unconsumed invite does not affect anyone who has already signed in — only the pre-authorization is removed. To deny access to an already-signed-in user, disable or delete them from Users.

Pending invites in the Users table

Pending invitations are rows in the Users table, listed after the members, for admins with canInviteUsers. Each shows the email with Hasn't signed in yet under it, and:

• Role — the role they will be assigned on first sign-in.
• DB Permission — the database permission they will start with. This column appears only when the SQL Server extension is allowed for your organization.
• Status — Invited, or Expired once the invitation has lapsed.
• Last active — Invited and the time since it was sent, or Invitation expired.
• The ⋯ menu — Resend invitation, Configure before they join, Copy email address, and Revoke invitation.

The search box filters invite rows by email; filtering the table by group hides them, because an invitee is in no group yet. Once an invitee signs in successfully, their invite is consumed and the row becomes an ordinary member row.

What can go wrong

Invalid addresses, blocked domains, and duplicate pending invites all report the specific reason. If you see a generic "Something went wrong. Please try again." instead, the failure was unexpected rather than a validation problem — check the audit log or contact support.

See Users for what happens after an invitee signs in, and Organization for the invite domain list.

Related

• Users
• Roles and permissions
• Groups — assigning groups at invite time
• Per-user governance — narrowing a single user's models, agents, and Analysis access
• SCIM provisioning