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.

The list of outstanding invitations lives under Organization settings → Invitations.

Sending, revoking, and pre-configuring invites all require canInviteUsers (which also implies admin access).

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.

Pre-configuring an invite

Before the invitee signs in, you can wire up much of their account in advance from the Pre-configure button on the invite row. Anything you leave blank falls back to the invite default or the org default. The Pre-configure invitation modal exposes:

When the user signs in, the row is consumed and these values are applied before their first chat.

Note

Pre-granting Jira or Confluence only lifts the organization and role gate — 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 → Extensions; 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 settings → Branding & Policy → Invite domain restriction. Enter a comma-separated list of domains (with or without the leading @). When set, the server rejects any invite whose recipient domain is not in the list.

The input shows live chip previews — valid domains get a gold @ prefix, malformed entries turn red.

Revoking an invitation

In the Pending invites table, click Revoke on the row. 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.

The pending invites table

Found under Organization settings → Invitations. The table columns:

• Email — the invitee.
• Role — the role they will be assigned on first sign-in.
• Default DB permission — pulled from the role. This column appears only when your organization has SQL Server connections.
• Sent — relative time since the invite was created.
• Actions — Pre-configure and Revoke.

Once an invitee signs in successfully, their invite is consumed and the row disappears — they now appear in the Users table instead.

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 settings for the domain restriction and invite email defaults.

Related

• Users
• Roles and permissions
• Per-user governance — narrowing a single user's models, agents, and Analysis access
• SCIM provisioning