Org-managed database connections
Admins can provision SQL Server connections once and share them with everyone in the organization, so users don't have to enter credentials themselves and rotations happen in one place.
Why use org connections
A personal connection lives in one user's account; only they can activate it. An org connection lives in the organization and shows up in every authorized member's Settings > Extensions > Microsoft SQL Server > Saved connections list, tagged Added by your org. Members can activate, view, and query it — but they can't rename, edit credentials for, or delete it. All four of those stay with admins.
Typical uses:
- A read-only analytics replica every employee should be able to query.
- A handful of department-specific databases where the credentials are a managed-identity secret you don't want to share by hand.
- Compliance scenarios where you need a single audit trail for who can reach which database.
Required permission
Listing, creating, editing, and deleting org connections all require the canManageOrgConnections permission. Granting per-user access to a specific connection (or revoking it) requires canManageUsers.
Create an org connection
- Open Admin > Database Connections.
- Click Add connection.
- Fill in the form:
- Display name — shown to users in their connections list. Must be unique within the org (case-insensitive). The inline pill shows Name is available or flags a duplicate as you type.
- Description — optional, e.g. "Read-only replica for analysts". Shown on the connection's detail page so users know what it's for.
- Hostname, Port (default
1433), Database name. - SQL login and password — the credentials Strata will use when any authorized member activates this connection. Use a least-privilege account; for analytics shares, a
db_datareader-only login is the recommended baseline. - Trust server certificate — same semantics as a personal connection.
- Click Create connection.
The connection is created with is_active = 1 and immediately becomes visible to every member of the org, unless they have an explicit per-user none override for it. The action is recorded in the audit log as org_db.created.
Control who can use a connection
By default, every member of the org can see and activate an org connection unless they have an explicit per-user none override for it. To grant or restrict access for one specific user, open Admin > Users, click the user to open their management modal, and under the Database access section (in the Extensions & Data tab) adjust the permission for that connection:
- Use role default — leaves the permission unset, so the user inherits their role's
default_db_permissionlevel. The user can still see and activate the connection. - None — blocked — explicitly denies access. The user does not see the connection in their Saved connections list.
- Viewer — read-only — read-only.
- Editor — writes w/ approval — read + write with per-query confirmation.
- Admin — full control — full access including DDL.
Per-user grants override the role default. The change takes effect immediately — no session refresh required.
Edit credentials or rotate the password
On the Admin > Database Connections page, open an existing connection's row menu (the three-dot menu) and choose Edit to open its edit modal. You can update any field: name, description, hostname, port, database, SQL login, password, and trust-cert flag.
Leaving the password field blank leaves the stored password unchanged. Type a new password to rotate it; the new value is encrypted with AES-256-GCM and replaces the old one on save. There is no rollback once you click Save changes — the previous password is overwritten — so verify the new login works against your server before saving.
Edits are audited as org_db.updated with the list of fields changed (excluding the password value itself).
Delete a connection
Open the connection's row menu (the three-dot menu) and choose Delete, then confirm by typing the connection name in the dialog and clicking Delete connection. Deleting removes the Strata-side credentials only; the underlying SQL Server database is untouched. The action is audited as org_db.deleted.
Authorized users who had the connection activated lose live access immediately. Past chats that referenced the connection keep their saved history but cannot run new queries against it.
How org connections look on the user side
In the user's Settings > Extensions > Microsoft SQL Server page, the saved-connections list mixes personal and org connections in one block. Each org connection is decorated with an Added by your org pill. Click a row to open its detail page:
- The activate flow is identical to a personal connection.
- The description field is read-only.
- A note at the bottom reads "This connection was provisioned by your organization. Contact an admin to change credentials or delete it." — instead of the Delete connection danger block that personal connections show.
What can go wrong
An organization connection with that name already exists.— names are unique per org. Pick a different display name or edit the existing connection instead.Connections to private/internal addresses are not allowed.— same SSRF guard as personal connections. The server hostname must resolve to a public address.- A user reports they can't see an org connection — check (a) the org's allowed extensions include
sql_server, and (b) no explicit None — blocked override is set for them in the Database access section of their user modal. The connection'sis_activeflag must also be1. - A user reports "Connection not found" when activating — most commonly the connection was deleted between page load and activate, or the per-user access was set to
nonesince they loaded the page. Have them refresh. - Forgot to update the SQL password before rotating in Strata — verify the credentials work via an external client first. There's no automatic rollback once a Strata password is saved, but you can re-enter the previous password and save again to restore it.
Related
- /docs/integrations/sql-server — connecting a personal database.
- /docs/admin/roles — role defaults, including
default_db_permission. - /docs/admin/users — per-user database access overrides.
- /docs/admin/audit — reviewing
org_db.created/updated/deletedevents.