Organization settings

Org-wide defaults, locks, the AI Model Catalog, branding, deletion controls, agent governance, and AI engine routing — all live under /admin/org-settings. Which extensions your organization allows, and the Atlassian connection itself, are governed on each extension's own page under Settings → Extensions — see Extension availability and per-extension settings.

Both viewing and changing the page require canManageOrgSettings. The page (and the GET/PATCH /api/admin/org endpoints behind it) are gated on that single permission, so a member with canAccessAdmin but not canManageOrgSettings cannot reach Org Settings at all.

Page layout

Org Settings is a strip of sub-tabs. Several are permission-gated, so you may see fewer than the full set:

1. Defaults — applied to new accounts in your org.
2. Locks — prevent users from overriding specific defaults.
3. Models — the AI Model Catalog launcher.
4. Branding & Policy — org logo, invite domain restriction, suspension, data export, deletion request.
5. Database Connections — embedded view of /admin/connections for shared SQL Server connections. Shown only with canManageOrgConnections.
6. Agents — org-wide agent templates library.
7. AI Engine — the Azure AI Foundry your organization runs its AI on. Shown only with canManageFoundry.
8. Provisioning (SCIM) — SCIM tokens for directory-driven provisioning. See SCIM provisioning.
9. Support — your organization's support contact settings.
10. Audit log — your organization's security-event activity table. Shown only to admins with canViewAudit.

Most of the page has no Save button. The Defaults, Locks, and Branding controls auto-save — every change schedules a debounced PATCH /api/admin/org (~350 ms after you stop interacting), and a successful save is silent. The exceptions inside Branding & Policy are the AI data policy and Content detection panels, which each save themselves and are not carried by that debounced write. The Database Connections, Agents, AI Engine, Provisioning, Support, and Audit sub-tabs manage their own state. Model enable/disable is owned by the Model Catalog modal, which saves each change on its own — see Models sub-tab below.

Note

Three things used to live here as sub-tabs and have moved. Knowledge Base now has its own admin page at Knowledge base. Invitations is now the Add user flow on the Users page — /admin/invites redirects there. Atlassian — and the org-wide availability switch for every extension — moved onto each extension's own page: open Settings → Extensions, pick the extension, then Manage → Organization settings (for Atlassian that is /settings/extensions/jira/manage). See Extension availability and per-extension settings.

Reading a setting row

Every switch on the Defaults and Locks sub-tabs — and on the extension pages described below — shows the same four things:

• the setting name;
• a scope chip — NEW ACCOUNTS ONLY, EVERYONE, IMMEDIATELY, or ADMINS ONLY. This is the fastest way to answer the question admins ask most often about this screen: whether a change reaches people who already have accounts;
• a state line in plain words that rewrites itself as you flip the switch, so the row always describes what is true right now rather than what the setting is called;
• the explanation, and where it matters a short note about what does not happen — turning the Memory default off, for instance, changes new accounts but never erases memories members have already saved.

Defaults sub-tab

These settings are applied when a new account is created in your organization. Existing users keep their current preferences unless you lock the corresponding setting under Locks.

• Database permission — Viewer, Editor, or Admin. The default DB permission for org connections.
• Default rate limit (per hour) — number plus a chats/tokens unit toggle. See Rate limits and quotas.
• Audit log retention (days) — 30 to 3650. Default 365. Entries older than this are deleted nightly. This control — along with the Audit detail level picker (Standard / Compliance / Forensic) above it — is shown only to admins with the compliance permission (canManageCompliance).
• Auto-purge deleted chats after (days) — 1 to 3650, or blank to keep forever. When a user deletes a chat it disappears from their view but stays in the DB so admin exports include it. After this many days the row is hard-deleted.
• Required AI mode — No requirement (users pick freely), Auto, Technical, or Simple. When set, every conversation in your org is forced into this mode and users cannot pick another.
• Max agents per user — cap on how many scheduled agents one user can deploy. Blank = unlimited.
• Max agent runs per day (per user) — daily ceiling on aggregate scheduled agent runs across all of one user's agents. Blocks runs once hit; resets at UTC midnight. Blank = unlimited.
• Minimum interval between runs (seconds) — reject schedules more frequent than this. e.g. 300 = "no more than every 5 min". Blank = no floor.
• Max tokens per agent run — hard ceiling on total tokens a single agent run may consume; the run stops mid-execution once reached. Blank = no limit.
• Max spend per agent run — dollar ceiling for one run, in cents (100 = $1.00); the run aborts once its estimated spend crosses it. Blank = no cap.
• Monthly spend cap per agent — total each agent may spend per calendar month, in cents. Once reached, that agent is skipped until the month resets. Blank = no cap.

The caps above are per-agent. The org-wide Monthly AI spend ceiling — a single dollar cap across all AI usage — is a separate billing control that lives under Billing, since it is gated on canManageBilling rather than canManageOrgSettings.

Six boolean defaults follow as toggle switches:

• Memory enabled — Strata remembers facts users share between conversations.
• Save AI conversations — persist chat history to each user's account.
• Save extension output — persist SQL results, file contents, and email bodies with each conversation.
• Feedback collection — show thumbs-up / thumbs-down on AI responses.
• Plan mode by default — Strata outlines a plan before executing complex tasks.
• Web search by default — allow the AI to search the web during responses.

A separate Capabilities group exposes the org-wide default for Analysis (whether the AI can run code in an isolated sandbox during chats; roles and individual users can override it), plus a Member chat oversight toggle that is shown only to admins with the oversight permission.

The same group carries Address lookup and maps — the org-wide ceiling on map and place data leaving your tenant. It powers generated maps and place results, and resolving an address requires sending that address to Mapbox. Unlike the web-search default above, this is not a per-member preference: it is an org-wide switch, and it is on unless an admin turns it off. Turn it off if your agreements bar sending customer or location data to a third party — maps already in past chats are unaffected. See the Sub-processors page for what Mapbox and the place-photo provider receive.

Locks sub-tab

A counter at the top of the tab reads N of M settings locked and updates as you change them, so you can see how tightly the org is configured without reading every row. Each lock's state line names the value everyone will be pinned to — the useful question is not "is this locked" but "what is everyone stuck on once I lock it".

When locked, the matching setting on a user's personal Settings page is read-only with a "Managed by your organization" badge. The lock toggles:

• Memory toggle — users cannot turn memory on or off.
• Save AI conversations — users cannot opt out of (or into) saving chat history.
• Save extension data — users cannot opt out of (or into) saving responses that contain SQL results, file contents, or email bodies.
• Rate limit — users cannot request a different chat rate limit.
• Database permission — users cannot request a higher DB permission than their role grants. Appears only when the SQL Server extension is enabled.
• Extensions — users cannot enable extensions outside their role's allowed list.
• Agents — org-wide kill-switch for scheduled agents. When ON, no one in the org can create or edit agents — already-deployed agents stay paused-but-visible. Per-role permission still applies on top.
• Feedback toggle — users cannot opt out of (or into) the thumbs-up/down feedback system.
• Timezone — users cannot pick a timezone; Strata uses the one detected from their browser.
• Display name — users cannot change their own display name.
• Profile picture — users cannot change their avatar.

Locks compose with role-level defaults. A user gets the lock's value (when locked), then the role's default (when allowed by the lock), then their own override.

The Jira writes lock — Apply to everyone, with no exceptions — is not on this sub-tab. It sits directly under the Jira writes toggle on the Atlassian page so it cannot be set without seeing what it governs.

There is no longer a separate "Allowed models" lock. The set of models your org has enabled in the Model Catalog is always authoritative — it is enforced everywhere a model can run (chat, agents, the Teams bot, voice, and the /v1 API) without a lock toggle. See Models below for how the catalog and per-user model access compose.

Models sub-tab

AI models

Strata is no longer limited to a fixed set of models. It runs a central Model Catalog that Kronisys Inc. curates. Your org chooses which catalog models your team can use and deploys them into your own Azure AI Foundry.

This sub-tab shows a Model Catalog launcher — overlapping provider logos and an Open the catalog button. Opening it shows every model with its capabilities, context window, pricing per 1M tokens (input/output), and benchmark results. Enable or disable a model with its toggle.

• Only enabled models appear in the model picker for chat and agents.
• Enabling fewer models is useful for cost control — e.g. restrict analysts to faster, cheaper models.
• The catalog spans seven providers — OpenAI, Anthropic, xAI, DeepSeek, Mistral AI, Cohere, Microsoft — all served through Microsoft Azure AI Foundry. The live catalog is the source of truth for what is available; see Choosing an AI model.

The catalog modal saves each toggle on its own, independent of the rest of the page's auto-save. Each toggle opens a confirmation first — enabling deploys the model to your whole organization; disabling removes it for everyone, and warns that conversations and agents pinned to it will fall back to another model. Your organization must always keep at least one chat model enabled, so the modal blocks disabling your last one.

When Strata advances its model lineup, older models stay available as legacy models for a transition period. Keep a legacy model enabled so members can maintain chats, agents, and saved workflows that still depend on it; disable it once your team has migrated. Legacy models are flagged in the picker and discouraged for new work.

Model access composes across three levels — org, role, and per-user. The models a member can actually use are the intersection of the org's enabled catalog models, their role's allowed list (set under Roles and permissions), and any per-user override. To narrow a single member below the org/role set, open Admin → Users → (manage user) → Extensions & Data → AI models and uncheck models there; leaving every box checked means the user inherits all org-allowed models.

Enabling a model that is not deployed in your Azure AI Foundry produces a sticky error toast: "<model> is not deployed in your Azure AI Foundry. Deploy it there before members rely on it — until then it will fail at runtime."

Extension availability and per-extension settings

The org-wide extension allow-list is not on this page. Each extension is governed on its own page, so an administrator configures a connector where the connector lives:

1. Open Settings → Extensions.
2. Click the extension.
3. Open the Manage menu and choose Organization settings.

The direct URL is /settings/extensions/<id>/manage. The page is visible only to administrators with canManageOrgSettings, and every change applies to all members immediately.

Each governed extension has one switch — "<Extension> is available to your organization" — and there are eight of them across the catalog: SQL Server, Outlook, OneDrive, SharePoint, Microsoft Teams, Web search, Jira, and Confluence. Turning one off hides its connect option in Settings and disables every related AI tool for all members.

What the switch actually means depends on the Extensions lock on the Locks sub-tab. With the lock on, org availability is a hard ceiling: turning an extension off takes it away from every role. With the lock off, it is an org-wide menu rather than a ceiling, and each role's own allow-list still decides what its members get. The page states which of the two applies, and shows how many roles currently list the extension.

Jira and Confluence are separate switches even though members connect Atlassian once — you can allow one and deny the other, and neither is granted automatically to an organization that already existed. Turning one off removes that product's tools from chat, agents, the Teams bot, and the public API; the member's stored Atlassian token is dropped only when neither product is allowed, so turning Confluence off alone leaves a working Jira connection in place.

SharePoint rides OneDrive's sign-in and cannot outlive it: turning OneDrive off also turns SharePoint off, with a SharePoint turned off too toast. Disabling SharePoint also turns off the Knowledge base, which runs its search over SharePoint content.

Atlassian is the one extension whose Manage page carries configuration of its own beyond the availability switch — see below.

Branding & Policy sub-tab

The tab is grouped into four zones: Identity (name, industry, overview, logo), Access (invite domain restriction, suspension), Security (multi-factor requirement, AI data policy, content detection), and Your data (export, deletion).

The Security zone is visible only to admins holding the compliance permission (canManageCompliance), so it is absent for other admins rather than shown disabled.

Organization name — shown in the sidebar header next to your logo, in member-facing emails, and in page titles. Defaults to your sign-in domain.

Industry and Organization overview — optional context fields. The industry and the one-or-two-sentence overview become part of the AI's context on every conversation, so it frames examples and terminology for your business.

Organization logo — PNG, JPEG, SVG, or WebP, max 5 MB before crop. Square works best; the file is cropped to a square before saving. Shown in the sidebar header for all members. Click the logo card to Change the image or Remove to revert to the default "Strata" wordmark.

Invite domain restriction — a comma-separated list of domains. When set, you can only invite emails whose domain appears here. Leave blank to allow any domain. The input shows live chip previews — valid domains get a gold @ prefix, malformed entries turn red.

Service suspension — temporarily pause all access for every member of your org. Admins can still reach the admin panel to lift the suspension. Useful for billing disputes, security incidents, or planned maintenance.

To suspend, type a reason (shown to members) and click Suspend organization. A step-up confirmation dialog appears — you must type the organization's name exactly before the action is applied. To lift, click Lift suspension (also requires typing the org name). Suspension flips members to a 403 "Organization suspended" response (carrying the reason you set) within about 30 seconds, as sessions re-hydrate org policy. Admins keep access. The audit log records org.suspended and org.unsuspended with the reason.

Require multi-factor authentication — when on, every member must sign in with an MFA-backed Microsoft account, and anyone who authenticates without MFA is denied at sign-in. It applies to administrators too, so verify your Microsoft Entra MFA policy works before enabling it — otherwise you can lock yourself out alongside everyone else.

AI data policy and Content detection — two separate panels in the Security zone, both concerned with inspecting content going to and coming from the model. They are siblings rather than one control: they write to different routes with different rules, and each carries its own Save button.

Neither is carried by the tab's shared save bar, and saving one does not save the other. Save each panel before you move on — if you try to leave Branding & Policy with an unsaved change in either, Strata asks "Discard unsaved changes?" and names the panel.

Export organization data — opens a modal to build a single ZIP of every user's conversations, messages, settings, and analytics. A signed download link is emailed to you and expires in 24 hours. See Admin data export.

Delete organization — requests permanent deletion of your organization. Requires Kronisys Inc. approval and a 30-day grace window. See Organization deletion.

Database Connections sub-tab

A nested mount of the Database Connections page so you can manage org-wide SQL Server connections without leaving the settings page. Shares the same canManageOrgConnections permission.

Agents sub-tab

The org-wide agent templates library. Admins publish reusable agent shells here that every member can deploy with one click.

AI Engine sub-tab

Where your organization's AI runs. Your organization runs on its own Azure AI Foundry — connecting it is a required, one-time setup, and every chat and scheduled agent is orchestrated against the Foundry deployment in your own Azure tenant. Inference stays inside your Foundry: no prompt or data is ever sent to a Kronisys-controlled model. See Bring your own Azure AI Foundry for the full setup and the irreversibility warning.

Atlassian: Jira and Confluence

Not a sub-tab of this page. Atlassian is configured on its own extension page — Settings → Extensions → Atlassian → Manage → Organization settings (/settings/extensions/jira/manage), which also carries the two availability switches for Jira and Confluence.

How your organization reaches Atlassian — Jira (Software and Service Management) and Confluence both. One site, one connection, and one consent screen serve both products; turning Jira or Confluence on turns each product's tools on, and the settings below decide what they can reach. Everything here auto-saves, the same posture as the rest of Org Settings: switches and the connection-mode radio commit the moment you click them, text and number fields commit on a short debounce (the site URL is resolved to a cloud ID server-side, so a half-typed one would be a real failed request). A status line beside the settings reads Saving… then Saved, and a toast confirms Atlassian settings saved · Applied to every member immediately. Jira and Confluence are sent as two independent requests, so a Confluence failure is reported as its own failure and tells you the Jira half did persist.

Note

Jira and Confluence are the Strata extensions that are not Microsoft services. What Strata reads here comes from Atlassian Cloud, not from your Microsoft 365 tenant. Atlassian pins your data to the region you chose when the site was created; Strata's platform database and your Azure AI Foundry are separate infrastructure in their own regions. An organization that needs every connector to stay inside the Microsoft boundary should leave both Jira and Confluence unchecked. See Atlassian extensions for the member-facing view.

Site

One Atlassian site URL — for example https://your-company.atlassian.net. Strata resolves it to an Atlassian cloud ID and pins your organization to it; that one site serves Jira and Confluence alike. The pin is re-checked on every request, so another site the member has consented to inside their own Atlassian account is never reachable through Strata. Only an admin with canManageOrgSettings can set or change it — the same permission the rest of this page requires — and doing so writes an org.jira_site_pinned row to the audit log. Until a site is pinned, members are told an admin has to choose it first; an admin's own first connect can bootstrap the pin instead, and that is audited the same way.

Connection mode

Two choices, set once for the whole Atlassian connection, and they decide whose Atlassian permissions bound every result:

• Each person signs in — each member connects their own Atlassian account under Settings → Extensions (one Atlassian row, not one per product). Strata acts as that person, so a project or space they cannot open in Atlassian is one Strata cannot read for them. An agent a member deploys runs on that member's connection.
• One organization account — you configure an Atlassian service account (client ID and client secret from admin.atlassian.com) and everyone works through it, so what Strata can reach stops depending on who is asking. Strata verifies the credential against your site before saving. The secret is stored encrypted and never displayed again, so changing it means entering it again. Restrict that account inside Atlassian to the projects and spaces Strata should see — Atlassian's own permission engine is a stronger boundary than any filter Strata applies on top.

Jira: project allow-list

Optional, comma-separated project keys — for example ENG, SUP, OPS. It bounds issue search, issue counts, single-issue reads, and Jira Service Management queues: a query naming a project outside the list returns nothing. Leaving it empty does not widen anything beyond what the connected account can already see.

Jira: writes

Let Strata create issues and comment is off by default. With it off, the create and comment tools are never handed to the AI at all, and members connecting are asked for read-only Atlassian scopes. With it on:

• in chat, the member approves each write before it happens;
• a scheduled agent or an API key has nobody to ask, so its writes proceed — an agent's write permission is resolved for its owner, so denying that person Jira writes also stops their agents;
• everything Strata writes carries a trailing line naming Strata, and for an agent, which agent and on whose behalf.

Every Jira write also produces an audit row — jira.issue_created or jira.comment_added.

This toggle is the ceiling, not the whole answer. Once it is on, two narrowing layers apply: the Jira writes capability on each role (Roles and permissions) and the Jira writes override on each member (Admin → Users → (manage user) → Extensions & Data). Both are tri-states whose Allowed (if the org allows) value grants nothing — it only means "this layer does not narrow" — so Denied at either layer is the only thing that takes writes away from someone the org has allowed. See Who may write for the full resolution.

Apply to everyone, with no exceptions appears under the Jira writes toggle, only once writes are on. With it on, the role and member layers stop applying and this switch alone decides for every member and every agent — the state line reads On — roles and members cannot narrow this. Turning it back off restores whatever role and member settings were already saved; turning writes off clears it. It lives here rather than on the Locks sub-tab so an admin cannot set it without seeing the toggle it governs.

Allow comments on service requests appears only once writes are on, and is off by default as well. Strata posts comments on Jira Service Management requests as internal notes only — visible to your agents, never to the customer who raised the request. There is no setting that makes a Strata comment customer-visible. Leave this off if you would rather no automated text touched a customer-facing ticket at all.

Hourly request cap

The number of Atlassian requests your organization may make per hour, counted across chat, agents, Teams, and the API. Jira and Confluence share this one budget — Atlassian meters its quota per app rather than per customer, so a cap keeps one busy organization from crowding out the rest. Leaving it blank does not mean unlimited: it uses the default of 2,000 requests per hour. A platform-wide ceiling of 10,000 per hour applies across all organizations and is consumed first.

Confluence group

A group on the same page, saved by its own request, that appears below the Jira section. It governs Confluence only — nothing here changes what Jira may do, and denying Confluence writes leaves Jira writes untouched.

Space allow-list — optional, comma-separated space keys. It bounds Confluence search, page reads, and the space listing the same way the Jira project list bounds issues, and it fails closed: if Strata cannot determine which space a page belongs to, it does not return the page. Two differences from the Jira list are worth knowing — the keys are case-sensitive, and the list is capped at 500. Leaving it empty means every space the connected account can already see.

Let Strata create and edit pages is off by default and works exactly like the Jira writes toggle: with it off the write tools are never handed to the AI, and with it on the same three layers apply — this org toggle, the Confluence writes capability on each role, and the Confluence writes override on each member, resolved independently from Jira's. Despite the control's label, Strata creates pages and adds page comments; there is no tool that edits an existing page.

Note

Confluence's equivalent of Jira's Apply to everyone, with no exceptions lock is enforced by the server (PUT /api/confluence/org/config accepts lockWrites), but the Confluence group does not currently render a switch for it. Jira's lock is the only one of the two you can set from the UI today.

Every Confluence write produces an audit row — confluence.page_created or confluence.comment_added — and saving this group writes org.confluence_config_updated. Reads are not audited.

Strata never indexes Jira or Confluence into the Knowledge base. Issues, comments, service requests, and wiki pages are read live at question time and are never embedded or cached as KB content.

Audit sub-tab

The organization's audit log — a filterable activity table of every recorded security event, with per-row detail (including an approximate map of the actor's IP location), CSV export, and pagination. The tab appears only for admins whose role grants canViewAudit; exporting additionally requires canExportAudit. The direct URL /admin/audit opens Org Settings with this tab active. See Audit log for the full reference, including the action vocabulary, detail tiers, and retention.

Saving changes

The Defaults, Locks, and Branding controls auto-save: each change schedules a debounced PATCH /api/admin/org about 350 ms after you stop interacting, and rapid toggles are coalesced into one write, so none of them carry a Save button. The Database Connections, Agents, AI Engine, Provisioning, Support, and Audit sub-tabs manage their own state independently.

Model enable/disable also saves on its own: the Model Catalog modal commits each toggle as you flip it.

Extension availability and the Atlassian configuration live on the extension pages and auto-save there too — a switch commits on click, a text or number field on a short debounce. There is no Save button anywhere in this flow.

A successful auto-save is silent — only failures surface a toast. Locks, model, and extension changes take effect on the next user request: active sessions re-hydrate org policy at most once every 30 seconds, so changes propagate within about half a minute.

What can go wrong

See Roles and permissions for how role defaults compose with these org defaults, and Audit log for the audited org changes.

Related

• Roles and permissions
• Knowledge base
• Bring your own Azure AI Foundry
• Atlassian extensions
• Audit log