Strata PlatformDocs
↑↓ navigate ↵ open esc close

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 > Apps > 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, testing, disabling, and deleting org connections all require the canManageOrgConnections permission (Manage org DB connections). Granting per-user access to a specific connection (or revoking it) requires canManageUsers.

Where you manage them depends on what else your role holds. With Manage org settings too, they are one of the organization's settings sections: Organization > Database connections (/admin/database-connections; /admin/connections lands there as well), with your organization's private connectors underneath. Without it, the Admin sidebar shows a standalone Database connections page (/admin/connections) with the same list and actions, minus private connectors.

Create an org connection

  1. Open Database connections (see Required permission for where it is).
  2. Click Add connection in the header.
  3. Fill in the New connection form. It is laid out in three groups:
    • Connection details
      • Display name — shown to users in their connections list. Up to 100 characters (the field stops there), and unique within the org (case-insensitive). The name is checked as you type: the line under it reads Checking availability…, then Name is available, or An organization connection with that name already exists. A duplicate the server refuses on save lands on the same line.
      • Description — optional, up to 500 characters, e.g. "Read-only replica for analysts". Shown on the connection's detail page so users know what it's for.
    • Server
      • Reach the server through — shown only when your organization has a private connector and private connectors are enabled on your environment: leave it on A public hostname (direct), or choose a connector to reach a server inside your network. See Private connectors.
      • Hostname, Port (default 1433, any whole number from 1 to 65,535), Database name.
    • Credentials
      • 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, under Advanced — same semantics as a personal connection. Only for a server inside your own network that uses a certificate it made itself.
  4. Click Create connection. A field that is missing or out of range is marked in red with what to fix, and the line beside the buttons counts them (2 fields need fixing.); nothing is sent until they are fixed.

Cancel, Escape, a click outside the form, or Back in the browser while the form holds changes asks Discard your changes? first.

The connection is created enabled, with Health reading Not tested, and every member can use it right away at their effective database access — set per person under Users, or else what their roles give them (see Control who can use a connection) — unless that access is none, and provided SQL Server is available to them. The action is recorded in the audit log as org_db.created.

Test a connection

Nothing is tested automatically. To check a connection, open its row menu (⋯) and choose Test connection, or open Edit, whose Health group at the top shows the Last test with a Test connection button beside it. Either way the test checks the saved connection, so in the form the button waits while you have unsaved changes (Save your changes first. Test connection checks the saved connection.). Strata connects with the stored details — a test can take up to 60 seconds — and the row's Health shows the result: Reachable, or Failed with a sentence saying what to fix, such as Login failed for user "strata_readonly". Check the SQL login in Edit. or The server didn't answer within 60 seconds. Check the host, the port and the server's firewall. The result is kept, so after a reload the row still reads, for example, Reachable · tested 2h ago; a connection nobody has tested reads Not tested. A disabled connection can still be tested, so you can check it before enabling it again.

Tests count against the same per-person budget as personal connection tests: 10 a minute and 30 an hour. Past it, the row reads Test limit reached. Try again in 40 seconds. and counts down; the stored result is left as it was. Each test is recorded in the audit log as org_db.tested.

Control who can use a connection

By default, every member of the org can use an org connection at their role's database permission (viewer when the role sets no default), unless that permission is none — a member whose role's permission is none, with no setting of their own, doesn't see, activate or use the connection at all; an explicit per-user setting, below, replaces the role's for that connection. The Access column in the connections table counts the people who have viewer, editor or admin access to each connection — for example 14 people, with 9 viewer · 4 editor · 1 admin underneath when more than one level is present. A connection nobody can use reads No one yet, with a Who has access link to Users if you can open Users. To grant or restrict access for one specific user, open Organization > Users, click the user to open their management modal, and on the Access tab, under Database access, choose the Permission for that connection:

  • Role default (…) — stores no permission for this user, so they follow their roles; the brackets name the level their roles give them today, for example Role default (Editor), counting group roles where your organization counts them. A role default of none withholds the connection (Role default (None)).
  • None — blocked — explicitly denies access. The user does not see the connection in their Saved connections list.
  • Viewer — read only — read-only.
  • Editor — writes with 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.

In organizations created from late September 2026, a role bound to one of the member's groups counts toward the role default: the member gets the higher of their own role's permission and the highest among their groups' roles, and a group role set to none adds nothing. The Access column counts them at that level. In organizations that already existed then, group roles don't change database access yet, and the member's Data & sessions tab says so under Where their permissions come from: Group roles don't change database access in your organization yet.

Auto-approve writes, beside each permission, skips the in-chat confirmation before INSERT, UPDATE and DELETE statements run: Role default (On) or Role default (Off) follows the user's own role — a role bound to a group never turns it on — while On and Off set it for this connection. Each select saves on its own, so changing one never touches the other. A refused save puts the select back and says so under the table: Couldn't save <connection>. followed by the reason.

Before late September 2026, every save here stored both fields: choosing Use role default saved an explicit Viewer permission, and auto-approve was always saved as On or Off. Those rows were not rewritten, so they show as Viewer — read only and On or Off; choose Role default (…) to make either follow the role again.

Edit credentials or rotate the password

In Database connections, open an existing connection's row 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 — and, when your organization has private connectors, the connector it goes through. To see the port, SQL login, certificate setting, who created the connection and who changed it last without opening the form, click its name in the table.

A connection that goes through a private connector keeps it unless you choose otherwise. If its connector has been removed, Reach the server through asks for a choice and says so in amber: The private connector this connection used no longer exists. Choose another connector, or a public hostname. When there is nothing to choose from (private connectors are not enabled on this environment, the removed connector was the last one, or the list could not be loaded), the form names the connector as text, says why it cannot be changed there, and offers Use a public hostname instead, which brings back an empty Hostname and the Port to fill in. Saving without choosing keeps the connection as it is.

Changing the hostname, database, SQL login, password, port or certificate setting clears the connection's last test result, because that result was for a different target: Health reads Not tested until someone runs Test connection again.

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 fields the form sent — it sends every field on every save, so this is not a diff of what changed — and never the password value.

Disable a connection

To take a connection out of use without deleting it, choose Disable in its row menu. Members keep their access settings, but the connection leaves their Saved connections list and cannot be queried, and scheduled agents that use it stop too. Health reads Disabled, with the last test result underneath if there is one. Enable, in the same place, lets members query it again. Both are audited as org_db.updated.

Delete a connection

Open the connection's row 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.

Private connectors

A private connector reaches a SQL Server inside your network without opening an inbound firewall port. Private connectors are managed under the connections in Organization > Database connections (the standalone page does not show them), with the same canManageOrgConnections permission.

  1. Click New private connector, give it a name, and enter the SQL Server's host and port as reachable from inside your network — it never needs to be public. Click Create; provisioning the relay on Strata's side is automatic and can take a moment.
  2. Connector setup opens with a connection string. Your network team installs Microsoft's Hybrid Connection Manager on a machine inside your network that can reach the server, and adds that connection string. Only outbound HTTPS (443) is needed. Setup on the connector's row opens it again.
  3. Point a connection at it: in Add connection or Edit, choose the connector under Reach the server through.

Each connector's row shows its Target, its Agent — Connected, Waiting for agent, or Couldn't check — and what it is Used by: the organization's connections (click to find them in the table) and a count of members' personal ones. A connection that goes through one reads Via private connector · <name> under Server / database. A test through a connector succeeds only once its agent reads Connected. A test that cannot reach the connector itself says which of two things happened: The private connector could not start. An admin can check its status in Organization > Database connections. (the connection's Health reads connector could not start), or The private connector this connection uses no longer exists. Choose another in Edit. when the connector has been removed.

Remove deletes the connector's relay and cannot be undone. It is refused while any connection still points at the connector — one of the organization's, or a personal connection saved by an active member — with a notice such as Couldn't remove sql01-hcm: it is still used by 2 connections. and See which to find the organization's own. Members have to remove personal connections themselves; a deactivated member's personal connection does not block the removal. On an environment where private connectors are not enabled, existing connectors are listed read-only.

How org connections look on the user side

In the user's Settings > Apps > 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, or be reached through a private connector. Test connection reports the same thing as This host is a private or internal address. Reach it through a private connector instead.
  • A user reports they can't see an org connection — check (a) SQL Server is available to them: on under Organization > Extensions when that list is a ceiling, allowed by their role or by a role bound to one of their groups, and not denied on their own account; (b) their row in the Database access section of their user modal (Access tab) reads neither None — blocked nor Role default (None); and (c) the connection isn't Disabled.
  • 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 none since 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.
  • SQL Server is turned off for your organization. Turn it on under Extensions, then test again. — the Extensions list is a ceiling that leaves SQL Server out, so nobody can use the organization's connections; a notice above the table says so. Turn SQL Server on under Organization > Extensions.
  • SQL Server isn't part of your own access, so you can't test connections. — SQL Server is available to the organization but not to you, because your role or your own account excludes it. A test dials the database, so it needs the extension yourself.
  • Test limit reached. Try again in … . — you have used your 10 tests a minute or 30 an hour, counted across personal and organization connections. Wait for the countdown.
  • Couldn't remove …: it is still used by … connections. — a private connector cannot be removed while a connection points at it. See Private connectors.

Related