Organization settings

Org-wide member defaults, the Model Catalog and the default model for new members, which extensions your organization allows, your org profile and sign-in policy, data retention and egress, agent governance, MCP connectors, shared database connections, AI engine routing, SCIM provisioning, the audit log and your support tickets with Kronisys — all live under /admin/org-settings, which opens on Profile. Every setting sits with the thing it governs, and the padlock beside it pins that setting for everybody. The Atlassian connection itself — site URL, cloud id, write permissions — stays on the Jira page under Settings → Apps, see Per-extension configuration.

Opening the page takes canManageOrgSettings (Manage org settings), and so do the GET/PATCH /api/admin/org endpoints behind it. Without it the address of a settings section does not redirect; it says Admin access required. Two delegates are the exception: an admin who holds canViewAudit gets the Audit log as a page of its own, and one who holds canManageOrgConnections gets Database connections the same way, each listed in their sidebar's Admin group. Inside the page, some sections and rows need a further permission. A section you cannot open is left off your rail, and a link to it shows the section's heading over a card naming the permission. A row you cannot change usually stays visible, read-only, with a line saying who can — Needs the "Manage compliance" permission. Ask an owner. A few are left off instead: the audit-log retention and detail level without Manage compliance, and the Oversight group without Manage member-chat oversight switch.

Page layout

The settings are twelve sections of the Organization page (Organization in the sidebar), listed in its navigation down the left among the admin pages, in seven groups: Organization, People, Intelligence, Connections, Usage and billing, Data and oversight and Help. Several sections are permission-gated, so you may see fewer than the full set; a group appears only when you can open at least one place in it. Each section has its own URL — /admin/member-defaults is not one of them; the slug is what shipped, so the rail entry labelled Member defaults lives at /admin/defaults and Profile at /admin/branding. A slug never retires, even when the label above it changes.

The groups answer "what am I changing": who the organization is, who is in it, how clever it is allowed to be, what it is plugged into, what it costs, what it is held to later, and where to get help. The settings sections are listed below by group; the admin pages beside them (Announcements, Users, Groups, Roles, Active sessions, Knowledge base, API keys, Usage and Billing) have their own articles.

Organization — who you are and who may join. (Also: Announcements.)

1. Profile (/admin/branding) — how your organization appears in Strata, who may join, and what happens to its data: org name, industry, overview and logo; your logo and accent color on files Strata creates; invite domains, multi-factor sign-in and session timeout; what members may change about their own account; export, suspension and deletion. The bare /admin/org-settings opens here. (Labelled "Branding & Policy", then "Profile & access", in earlier releases; the data policy that once sat here is now under Data and privacy.)
2. Member defaults (/admin/defaults) — where new members start, and the rules that apply to everyone right away: Where new members start (the defaults a new account inherits), Rules for everyone, effective now (AI conversation mode, Extension output in history, the capability switches, sub-agent approvals, and an Advanced fold with approvals for scheduled agents and autonomy limits), and Rate limits.

People — who is in the organization. (Also: Users, Groups, Roles and Active sessions.)

3. Provisioning (/admin/provisioning) — connect your identity provider over SCIM so it creates and deactivates Strata accounts and keeps names and groups in sync with your directory: the tenant URL and the tokens your provider uses. See SCIM provisioning.

Intelligence — how clever the organization is allowed to be. (Also: Knowledge base.)

4. Models (/admin/models) — which AI models your members can use, how much of each they may use, and where new members start: the Model Catalog launcher, Models your members can use (the chat models that are on, with each one's allowance and how many roles reach it where your permissions show them; allowances are changed here), Allowance defaults, Default model for new members, and Model retirements.
5. AI engine (/admin/ai-engine) — where your organization's AI runs: your own Azure AI Foundry, its endpoint and key (changed through Verify & save), and its deployment names. Shown only with canManageFoundry.
6. Agents (/admin/agents) — Freeze agent changes (which stops creating and editing agents, not their runs), the six agent limits, and the organization agent templates library.

Connections — what the organization is plugged into. (Also: API keys.)

7. Extensions (/admin/extensions) — which extensions your organization may reach for at all, and whether that list is a menu or a ceiling. See Extensions.
8. Connectors (/admin/connectors) — the MCP connector catalog and the connectors your org has added. See Connectors.
9. Database connections (/admin/database-connections; /admin/connections opens it too) — shared SQL Server connections and Private connectors. Shown only with canManageOrgConnections; an admin who holds that without canManageOrgSettings gets the shared connections as a page of its own, without the Private connectors group.

Data and oversight — what the organization is held to.

10. Data and privacy (/admin/data-privacy) — Retention; the Audit log group (audit retention, detail level and the tamper-evident log); Oversight; What can leave your organization (the egress rules); and Advanced data protection, which holds the AI data policy and content detection.
11. Audit log (/admin/audit) — your organization's security-event activity table. Shown only with canViewAudit; an admin who holds that without canManageOrgSettings gets the same table as a page of its own at /admin/audit.

Help

12. Support (/admin/support) — your organization's tickets with Kronisys, shared across the organization. It opens on Waiting on you when Kronisys has replied and is waiting for you (otherwise on Open), shows a count on those two filters, marks urgent tickets, and says who wrote last. A reply that arrives while the page is open is announced with a Refresh rather than moving the list under you. The support address (support@kronisys.com) is on the page too, and where Billing's note on an agreement points to Support, a billing manager who cannot open the organization's settings is given that address instead.

There is no thirteenth section listing what you have pinned. A padlock is read on the row of the setting it pins, and a second place to read the same state is a second thing to keep in step with it. To answer "what has my organization pinned?" across the whole org at once, open the audit log and filter it to the Organization category: every save is recorded as org.updated with a per-column diff, so each padlock carries its old value, its new value, who closed it and when.

Finding a setting

To find a setting without knowing which section holds it, type in Search settings at the top of the navigation (typed on one of the other admin pages, the words are carried to the settings and searched there) — the same search as in personal Settings. Results name each matching setting with the section it is in (in Data and privacy, for example), or offer Go to this page for a whole section. A setting that is changed on another page says where it goes — Monthly spend ceiling is marked Opens Billing — and choosing it takes you there. Common words work: "Okta" finds Provisioning, "egress" and "partner domains" find Data and privacy, "sub-agents" and "token pool" find Member defaults. Move through the results with the Up and Down arrow keys and press Enter, or click one: Strata opens that section, scrolls to the setting and briefly highlights it. Esc clears the search. Only settings you can open are found; sections your role doesn't show are left out. If nothing matches, the list says No organization setting matches that.

Linking to a setting

A section address is a fine bookmark, but it names a page rather than a control, and controls move between sections. For a link that survives the move, address the setting by its storage key: /admin/setting/<column> opens whichever screen owns that setting today, and flashes the control itself. /admin/setting/web_fetch_policy lands on Data and privacy with the web rung highlighted; /admin/setting/monthly_spend_cap_cents leaves the settings sections altogether and opens Billing, because that is where the ceiling is now set. This is the form to put in a runbook or a support answer. Column names appear in the audit log diff for every save, so you can copy one straight out of the entry you are reading. When the link has no control to light up for you, a line at the top of its section says why instead: the permission it needs (Session timeout needs the "Manage compliance" permission. Ask an owner to grant it.), or the other setting that hides its row. A key with no control opens Profile and says only the Strata API can change it, and a key Strata does not recognize opens Profile rather than a 404.

Older addresses keep working rather than 404ing. /admin/locks opens Member defaults, which is where most of the padlocks ended up. /admin/access, /admin/autonomy and /admin/limits — three sections an earlier plan drew — resolve to the pages that actually hold their controls. And where a link carried an anchor for a group that has since moved, the anchor wins over the slug: /admin/defaults#egress opens Data and privacy, /admin/defaults#agents opens Agents, /admin/defaults#session opens Profile.

Most settings save as you change them; see Saving changes for how, and for what a row says when a save does not land.

Note

Four 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's own configuration moved onto its extension page: open Settings → Apps, pick Jira, then Manage → Organization settings (/settings/extensions/jira/manage); the org-wide availability switch for every extension is here in the Extensions section. And Locks is gone — see Padlocks.

Reading a setting row

Every one of the organization's settings is built from the same row. Left to right, it carries:

• the setting name, with (optional) or a count such as 14 domains beside it where one applies;
• help under the name: what the setting does, and where it matters what it does not do — turning the Memory default off, for instance, changes new accounts but never erases memories members have already saved. A few rows rewrite their help to say what is true now: while Freeze agent changes or Require multi-factor authentication is on, the row says what On is doing; Help that runs past three lines shows its first two, fading out, with Show more under it to read the rest and Show less to fold it again; searching for a setting opens the help of the row it lands on.
• the control on the right — a switch, a segmented choice, a dropdown, or a number or text field with its unit inside the box. In a narrow window the control moves under the text;
• where the setting can be pinned, a padlock to the right of the control.

A line under the row carries anything else the row has to tell you: why a value was refused or has not saved yet (see Saving changes), who can change a row you can only read (Needs the "Manage compliance" permission. Ask an owner.), that it depends on another row (Applies when Sub-agents is on.), or that your deployment overrides it (Turned off for this deployment, so no one can search the web, whatever this is set to.).

Whether a change reaches people who already have accounts, the question admins ask most often about this screen, is answered by the group heading rather than by each row. On Member defaults, Where new members start reads Applied when an account is created. Existing members keep their own preferences unless you pin a setting for everyone with the padlock beside it., while Rules for everyone, effective now and Rate limits apply to everyone the moment you save. Agents keeps its freeze under Rules for everyone, effective now too, and Extensions says Everything on this page applies to every member the moment you save. The scope chips and state lines these rows used to carry are gone from the organization's settings; the extension pages under Settings → Apps still use them — a title, an Everyone chip, a state line such as On — Strata can write to Jira, and a description.

A padlock is outlined and muted while members may change the setting, and filled once it is pinned; its words — Members may change or Pinned for everyone, or a sentence written for that row — are its tooltip, not text on the row. Closed, the value on that row is what everyone gets; open, it is a starting position members may change. You never have to leave the row to answer "what is everyone stuck on once I close this" — see Padlocks.

The cascade line on a capability

The four capabilities that roles and individual members can narrow — Analysis and Sub-agents under Member defaults → Rules for everyone, effective now, Jira writes and Confluence writes on the Atlassian page — carry one more line, under the help text, reading the whole chain rather than just this switch: Organization: On · 2 of 5 roles turn it off · 3 members have an exception. Where a segment counts something, it is a link — to Roles or to Members — so you can go and look at what it counted. The line rewrites itself the moment you flip the switch, before the save has even fired, so it never describes a configuration that has just changed.

It also answers the question this page used to leave hanging — the switch above says On, so why can this person not use it? Turn the organization off and the line stops counting and says Nothing below can lift it, naming instead how many roles and members are being overruled. On a write capability the wording differs because the rule differs: a member set to Allowed never grants anything on its own, so it is not reported as an exception, and while a writes lock (Apply to everyone, with no exceptions) is closed the line reads Locked — roles and member exceptions do not apply rather than counting layers that are not consulted.

Member defaults

Where new members start, and the rules that apply to everyone right away. The section has three groups. Where new members start is applied when an account is created; existing members keep their own preferences unless you close the padlock on that setting's row. Rules for everyone, effective now and Rate limits take effect for everyone the moment they save.

Where new members start

The starting position for each new account. Members can change these for themselves unless you close the padlock beside the row, which pins it for everyone (see Padlocks); Plan before acting has no padlock. A custom role can start its own new members differently on Memory and Conversation history, with its Memory at start and Chat history at start starting values; a closed padlock here still wins. See Roles and permissions.

• Default database access — Read-only, Approve edits (asks before each change), or Full control (can also delete and change stored procedures): the permission a new member starts with on connected databases. Roles can set their own. The row appears once the SQL Server extension is allowed in Extensions. Closing its padlock is refused while members already hold more than their role grants: the row names them (three at most, then and N more) and offers Review in Users or Pin anyway. Pinning keeps their access as it is; it does not lower it.
• Memory — Strata carries facts a member shares from one conversation into the next. Turning it off does not erase memories already saved.
• Conversation history — keep each member's chats on their account so they can reopen, search, and export past work. How long deleted chats are held is set in Data and privacy.
• Response feedback — show thumbs-up / thumbs-down under answers. A rating stays in your organization; after rating, a member can choose to send Kronisys a note with diagnostics of that answer (see Conversations in feedback to Kronisys under What can leave your organization). Turning this off for everyone turns that off too.
• Plan before acting — on a multi-step request, Strata lays out what it intends to do before it runs anything.
• Web search — allow the AI to search the public web when your data does not cover the question. Search queries leave your tenant; your documents, database rows, and email contents never do. If your deployment has web search turned off, or has no search provider, the row says so under the switch.
• Default model for new members — read-only here. The row names the model new members start on, with Set it in Models (or See it in Models, without Manage AI models); the choice itself is made in Models.

Rules for everyone, effective now

These change every member's experience the moment they save. Analysis and Sub-agents each carry a cascade line.

• AI conversation mode — Let members choose (the default), Auto, Technical, or Simple. Choosing a tone forces every conversation in your org into it, so Strata asks first (Use the Technical tone for everyone?): it overwrites every member's own choice of tone, and switching back to Let members choose later does not restore their choices.
• Extension output in history — whether a turn that used an extension (databases, files, email, knowledge base) is written to chat history at all. This is an org-wide ceiling: turning it off immediately stops persisting extension turns for everyone (the member's message and the reply are both stored blank), and a member may narrow it further but never widen past it. Its padlock stops members narrowing it.
• Analysis — whether the AI can write and run code in an isolated sandbox with no network access, destroyed after each run. Roles and individual users can be granted or denied this separately. On by default.
• Sub-agents — whether the AI can split a complex request into independent subtasks and run them in parallel. Roles and individual users can be granted or denied this separately. On by default. Turning it off falls back to Strata handling multi-part requests one step at a time. A sub-agent always runs under the same permissions, model governance, and spend limits as the chat that spawned it, so this setting only decides whether the tool exists, never how far it can reach. See Sub-agents.
• Most freedom a member may choose — under Sub-agents, the ceiling on the approval mode a member picks beside the model: Members can choose any mode (the default), Up to Do not ask, refuse instead, Up to Ask before anything leaves, Up to Ask only when risky, or Always ask. Roles and individual members can be limited further, and the most restrictive of organization, role and member applies.
• Where a new chat starts — the mode a fresh conversation opens on: Ask every time (the default), Ask only when risky, Ask before anything leaves, Do not ask, refuse instead, or Skip approvals. A start looser than the ceiling above is held to it, and the row says where new chats will start. A member can still move it in the chat, up to the ceiling. This row and the one above apply only while Sub-agents is on; with it off they are dimmed and read Applies when Sub-agents is on.
• Re-check corrected files — when a review finds a problem in a generated PDF, Word, or Excel file and Strata corrects it, this looks at the corrected file again to confirm the fix landed. One extra pass, only on files that were flagged. It runs on your own Azure AI Foundry and shows up on your Usage page. Turning it off keeps the first review and the structural file check, which cost nothing. On by default.
• 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 it to Mapbox. On by default; 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.

Advanced: approvals for scheduled agents, autonomy limits folds away the rest of the group:

• Approvals for scheduled agents — what a run does when there is nobody to ask. Run without asking keeps the behavior scheduled runs have always had; Check every action runs the same classifier a chat uses and refuses what it cannot approve, so the run ends with a reason instead of waiting for an answer that will never come.
• Autonomy limits — how far Strata may go on a member's behalf inside one request: Tool rounds per turn, Sub-agents per turn, Sub-agents per batch, Approval wait, and the two Automatic approvals allowances (for members on Ask only when risky and on Skip approvals). You can make a limit stricter than your deployment allows, never looser; leave one blank to stay on the deployment's maximum. Limits in force lists the values that apply, with your deployment's own switches and provider keys — a switch that is off there overrides the matching organization setting.

Whatever any of these is set to, Strata always asks before a sub-agent emails someone outside your organization, creates a link anyone can open, or deletes data, and your data-egress rules still apply. Changes take effect at a sub-agent's next action. Members set their own mode on the Sub-agents card in the workspace panel — see The Approvals setting.

Rate limits

How much of your token allowance each member may use, and how it is shared. Applies to everyone now. See Rate limits and quotas.

• Plan — Per member (a rolling one-hour ceiling for each person) or Shared pool (one monthly token bucket the whole organization draws from). The rows for the plan not in use are dimmed but stay editable.
• Limit per member, per hour — a number from 1 to 10,000,000 and a chats/tokens unit; 1 chat counts as 5,000 tokens, and switching the unit converts the number. Blank uses your deployment's default, which the row states (60 chats an hour unless your deployment changes it). Roles and individual members can be given their own limit; closing the padlock on this row ignores individual members' limits, while role limits still apply. Under Shared pool with no pool set, this limit is the one in force.
• Monthly token pool, Per-member share of the pool (1 to 100%; blank means no cap), and Pool reset day (1 to 28, so it works in every month) — the shared-pool controls. A blank pool falls back to the limit per member.
• Monthly spend ceiling — read-only here. A rate limit is half the answer to "why did this person stop?", so the group states the ceiling's current value — $4,000.00 per month, or No ceiling set — with a button reading Set it in Billing (or See it in Billing, if your role can only view it). The control itself is on Billing: one setting, one place it can be changed. Without either billing permission, the row names the permissions it needs instead.
• Monthly limit per member — read-only here too: the Default limit per person and the Weekly pace, both set in Billing beside the ceiling ($50.00 per month · at most 40% in a week, $0, which stops members, or No default limit), with the same Set it in Billing button.

Note

Five groups of controls left this section in the reorganization and are named here so you do not go looking. The agent quotas and the org-wide agent stop moved to Agents. The data-egress rungs, audit detail level and the tamper-evident log moved to Data and privacy. The session timeout moved to Profile, beside the multi-factor requirement. Private connectors moved to Database connections. Every link that named the old home still resolves — see Linking to a setting.

Announcements

How long announcements stay in inboxes and whether members can dismiss them. Applies to announcements sent after you change it; announcements already sent keep what they were sent with.

• Remove announcements after — a number of days from 1 to 3,650, or blank to keep announcements until they are recalled. Where every new announcement's Auto-expire starts.
• Members may dismiss announcements — on by default. When off, new announcements start as mandatory notices that stay until they expire or are recalled.

Each row has a padlock. Open (Each announcement may differ), the value is where the publish flow starts and the author can change it. Closed (Same for every announcement), every announcement gets the organization's value and the control in the publish flow is disabled with a line saying where it is set. See Announcements.

Padlocks

A padlock is not a place. It is a control on the row of the setting it pins, so the value and the decision to freeze it are read together — you never have to change screens to answer "what is everyone stuck on once I close this".

When a setting is pinned, the matching control on a member's personal Settings page stops responding and carries a padlock badge reading Managed by your organization's name. These rows carry a padlock:

The remaining locks are written as the control itself rather than as a padlock:

• Freeze agent changes — a switch under Agents → Rules for everyone, effective now. While it is on, nobody, admins included, can create or edit an agent; existing agents keep running on their schedules. Per-role permission still applies on top.
• How members get an extension — Ceiling or Menu, under Extensions → How this list is applied. Ceiling makes the org list a hard ceiling; Menu lets each role's own list decide.
• Let members change their display name, Let members change their profile picture and Let members set their own timezone — switches under Profile → Member profiles, where on means members may. The pinned value is the member's own, so there is no org-side value to freeze, and the lock is written as the thing it does.

A closed padlock makes your value win over the member's own. Two padlocks work with roles rather than past them: pinned database access gives each member what their role grants, and a pinned limit per member ignores individual members' limits while role limits still apply.

Web search is the one whose member switch is not in personal Settings: it is the Web search row in the chat composer's + menu. While the padlock is closed, that row shows your default with a padlock and Set by your organization, and it can't be changed, so your default decides every answer. In personal Settings, Search the web under Capabilities carries the Managed by badge and reads Your organization has turned this on for everyone. (or off). In the Outlook add-in, Search the web under Settings › General shows your default, can't be moved, and reads Set by your organization: on for everyone. (or off), and every turn in the pane uses your default. Voice mode follows your default too, and checks it again each time it searches, so closing the padlock with the default off during a call applies from that call's next search. Closing the padlock does not overwrite anyone's own choice, and no member's change is saved while it is closed: open it again and each member's switch is back where they last left it. Close it with the default off when no part of a question may leave your tenant.

The Jira and Confluence write locks — each labelled Apply to everyone, with no exceptions — sit directly under their writes toggles on the Atlassian page, by exactly the same rule, and appear once that product's writes are on.

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

Which AI models your members can use, how much of each they may use, and where new members start. From the top, the section holds a summary of the Model Catalog, Models your members can use, Allowance defaults, New members and Model retirements. Anyone who can open the organization's settings sees it; changing which models are on, the default for new members or the retirement switch requires Manage AI models. The section is in the language you chose in Settings, with token amounts, retirement dates and counts written your language's way; model and provider names stay as the catalog writes them. The Model Catalog it opens is in your language too (what stays as written).

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.

The section opens on a summary card for the catalog: the logos of the providers whose models your organization has turned on, a line counting how many catalog models are on and from how many providers, and the button that opens the catalog — Manage models, or View models for an admin without Manage AI models. If the catalog can't be read, the card says Couldn't load the catalog summary. with Try again; the retirement switch still works, and the default-model row waits for the catalog (Choices load with the catalog.). The catalog shows every model with its capabilities, context window, pricing per 1M tokens (input/output), benchmark results, and retirement date when one is scheduled. Enable or disable a model with its toggle. A model that isn't deployed in your Azure AI Foundry yet shows Not deployed in place of its Enable button — or, for a model sold through Azure Marketplace such as Anthropic's Claude models, Needs Marketplace agreement until the offer is accepted in Azure AI Foundry. With autonomous deployment on, an admin who holds Manage AI provider key as well as Manage AI models gets the Enable button instead, for every model except the Marketplace ones: enabling deploys the model to your Foundry first, then turns it on. A Preview tag marks a model Microsoft offers in preview on Foundry, with no availability SLA.

• 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 (Disable model) removes it for everyone, and says Conversations using it will switch to another model. If agents run on it, Strata names them and asks before they pause. While an agent that can still run is set to the model (one that isn't paused, owned by a member whose account isn't disabled) the model stays on until you answer a second dialog, Turn off <model>?. It counts the agents and their owners, says they pause on their next run until moved to another model and that each owner is told, and lists them by owner, the people with the most agents first, in a list that scrolls, with a Filter by person or agent field once there are more than six owners; in a large organization it holds the first 200 agents and counts the rest. Turn off <model> anyway turns it off; Cancel keeps it on. Only an agent's owner can change its model; an admin with Manage users can delete a member's agent from that member's Agents tab. Paused agents, and agents owned by disabled members, aren't counted, and none of them can run on the model while it is off: Resume is normally refused, and any run started on it is refused. Removing the model's deployment asks the same way. A role, group or per-user model list can leave out a model agents use: the save goes through, the page warns which agents will pause, and each pauses the next time it is started unattended (see Model governance). 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, discouraged for new work, and not offered when the AI assigns models to sub-agents.

Models your members can use lists the chat models that are on: the first eight, with Show all for the rest; a longer list also gets a Find a model field that matches a model's name or provider. Each row names the model and its provider, and a Legacy model reads · Legacy after its name. Two more columns appear only for an admin who can read them: Allowance, with View usage & billing — the model's allowance in tokens per month (or per trial period), No cap, or Blocked (an older setting) — and Roles, with Manage roles — All roles, No roles, or how many of your roles allow it (3 of 7 roles). While your deployment isn't enforcing model allowances, one Not enforced. notice sits over the list and the values stay as they were set. Voice, transcription and embedding models are counted in a line under the table rather than listed. With no chat model on, the group reads No chat models are on, because members can't chat until one is. Until your AI engine is connected the group is titled Models turned on, since nobody can use them yet.

Allowances

Allowances are changed here, not in the Model Catalog: the catalog shows them, with a link back to this section. An admin with View usage & billing and Manage billing gets a box and a Change button on each row. Change opens the allowance dialog for that model. Ticking boxes, or Select all (which takes every model the filter matches, the ones folded under Show all too), brings up a bar at the foot of the list with Set allowance…, for up to 200 models at a time, and Clear selection.

The dialog offers Metered (a number of tokens per month, written like 20M, 500k or 2,000,000, or the way your language writes a number, such as 2.000.000 in German), No cap, or Follow the default; for a selection whose models differ it opens on Keep current. A metered allowance also sets what happens At the ceiling: Block the turn, or Fall back to another model that you choose; if that model is used up too, or isn't one the member may use, the turn moves to the nearest cheaper model they may use. A model that still carries the older Blocked setting opens with nothing chosen, and you choose what applies from now on. Closing the dialog with a change you haven't saved, or following its Open Groups link, asks Discard your changes? first.

Allowance defaults holds the levels above a model: Every model (the organization's default) and one row per provider that has a default of its own (Anthropic models), each with Change, and Add a provider default. A model with no allowance of its own follows its provider's default, then the default for every model. Voice mode can't have an allowance of its own: it follows the default of the voice model's provider when that default states one, otherwise the default for every model, and only the row that applies says so. Without Manage billing the values are read-only (Only admins with "Manage billing" can change this.); without View usage & billing the Allowance column isn't shown and the defaults read Needs the "View usage & billing" permission to read. Ask an owner.

Default model for new members

Default model for new members, under New members, is the model a new account starts on; existing members keep their current choice. The choices are the chat models your organization has on that are current — a Legacy model can't be the default. Until you choose one, the row shows the model new members start on today (Claude Sonnet 4.6), with its mark; when that model retires, they start on its replacement. Choosing that model's own row keeps it that way. It saves as you choose, like the rest of the page, and Member defaults shows which model new members start on, with a link here. Changing it requires Manage AI models; without it the row reads Only admins with "Manage AI models" can change this. Link to it with /admin/setting/default_model_id.

A new member starts on the default only if they may use it: members in a role that doesn't allow the model start on the model new members get when no default is chosen (or, if their role blocks that too, on a model their role allows), and an admin who can manage roles sees how many roles block it under the row. When the stored default has since been turned off, marked Legacy or retired, an amber notice under the row says new members start on that model until you choose another. If no default is chosen and that model isn't on for your organization, or has gone Legacy, the row shows it as unavailable and asks you to choose one. The server refuses a default that isn't a current chat model turned on for your organization; the choice goes back to the saved value and the row says why.

Model retirement

When Microsoft retires a model on Foundry, the catalog records the date and, where Kronisys has chosen one, a replacement of the same kind: a chat model for a chat model, a transcription model for a transcription model. Kronisys reads Microsoft Foundry's and Anthropic's published retirement schedules every day and is alerted the same day a date is announced or moved, so a vendor's change does not go unnoticed. In the Model Catalog, the model's row and its detail page read Retires October 19, 2026 · Moves to Claude Sonnet 5; the second half is left off when no replacement is named. 90 days before the date the model becomes Legacy, and members see Retires Oct 19 under it in the chat picker's Legacy models list.

Notices. Every active member whose permissions include both Access admin panel and Manage AI models, through their own role or a role bound to one of their groups, gets an inbox notice and an email 60, 30 and 14 days before the date, and on the day. Only organizations the retirement touches are notified: your enabled-model list names the model; or a default, role, member setting, scheduled agent, agent template, API key, usage allowance or the voice mode deployment names it; or your organization allows every model and the model was used in the last 90 days. A model scheduled late gets only the most urgent notice already due, never the earlier ones. The notice names the replacement, lists what Strata will switch (as counts), says whether Strata found the replacement deployed in your own Foundry, and links here with Review models. The 14-day and day-of notices can't be dismissed, and every notice leaves the inbox 30 days after the date.

On the date. In the first hourly pass on the date (UTC), Strata moves everything in your organization that names the model to its replacement: the enabled-model list, the default model for new members, each member's chosen model, roles and member model settings that allow it, scheduled agents, agent templates, the model lists on API keys that aren't revoked, usage allowances (including fallbacks and group caps; a block on the old model is not carried over), and the voice mode deployment setting. When anything changes, the audit log records model.retirement_migrated. The model then leaves every picker, and a chat, Teams or API request that still names it runs on the replacement. Strata can't change your own code that calls the API with the old model id.

Nothing is moved when no replacement is named, when your organization's model policy refuses the change, or when the switch below is off. The day-of notice then lists what still names the retired model, so you can change it yourself.

• Move to the replacement when a model retires — When Microsoft retires a model, Strata moves your organization's defaults, scheduled agents, roles and allowances to its replacement on the retirement date. Turn this off to choose replacements yourself. On by default.

The switch is the first row of the Model retirements group at the foot of the section, under the line Microsoft retires models on fixed dates. Strata marks a model Legacy 90 days before, and emails admins with "Manage AI models" 60, 30 and 14 days before and on the day. It saves when you flip it, like the rest of the page. Changing it requires Manage AI models; without that permission the switch is read-only and the row reads Only admins with "Manage AI models" can change this. While the switch is on and a model in the list below has no replacement named, the switch's help adds Models with no replacement are never moved automatically. Turning it off doesn't keep a model available past its date — it retires for every organization — it only stops Strata changing your settings. Link to it with /admin/setting/auto_migrate_retired_models.

Under the switch, Upcoming retirements lists the models your organization has on that have a retirement date, soonest first: the Retires date with the days left (amber from 14 days out), and the Replacement — its name, No replacement named yet, or You choose the replacement while the switch is off. Click a row to open that model in the Model Catalog. The first five are shown, with Show all for the rest; with no dated model, the table is not shown.

Note

If Kronisys has to retire a model immediately rather than on a scheduled date, every organization is moved to the replacement whatever this switch says, and no notices are sent.

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 together with those of any roles bound to their groups (set under Roles and permissions; a built-in role does not narrow it), and any per-user override. To narrow a single member below the org/role set, open Organization → Users → (manage user) → Access → AI models and uncheck models there; a model their roles don't allow is listed as Not allowed by their role and can't be ticked. Leaving every box checked, or clearing them all, means the user inherits every model their role allows.

Before a model is switched on, Strata checks, fresh, that your Azure AI Foundry has it, so it never reaches the picker only to fail at runtime. If your Foundry doesn't have it, what happens depends on autonomous deployment: with it on, an admin with Manage AI provider key who enables any model except a Marketplace one gets it deployed first and then enabled — a model already deployed is enabled directly. If that deployment fails (for example, no quota in your subscription) or is still running after about two minutes, the model stays off and the catalog says why; if your Foundry still isn't answering for the new deployment about two minutes after it lands, the model stays off and the catalog says to enable it again in a few minutes. Otherwise — autonomous deployment off, an admin without Manage AI provider key, or a Marketplace model such as Anthropic's Claude — the enable is refused, the model stays off and the catalog says why.

Extensions

Which of Strata's built-in extensions your organization may use, and whether that list is a ceiling or a menu. The list is edited only here, at /admin/extensions; each extension's own page under Settings → Apps states the decision read-only and names this section. Everything in this section applies to every member the moment it saves.

How members get an extension comes first, under How this list is applied, because it changes what every switch below it means rather than what it is set to:

• Ceiling — an extension that is off here is unavailable to every member, whatever their role allows, and leaves their Apps page and every AI tool that depends on it.
• Menu — each role's own list decides. An extension that is off here can still reach members whose role lists it.

Switching from Menu to Ceiling can take extensions away from people, so Strata first counts who would lose one and, unless nobody would, asks on the row — for example 12 members will lose at least one of Outlook and Jira. — with Switch to Ceiling and Keep Menu, and says how many would be disconnected, if any. Switching back to Menu only widens access and saves at once. While every extension is off, the ceiling is not applied: a notice reads Every extension is off, so the ceiling is not applied. and each role's own list decides until you turn one back on. Turning that first one on applies the ceiling, so it is counted the same way and, unless nobody would lose an extension, asks first (Turn … on or Keep off).

Below it is one switch per built-in extension, in three groups:

• Microsoft 365 — Outlook, OneDrive, SharePoint, Microsoft Teams and Teams chats, which use the member's Microsoft sign-in. Teams and Teams chats stay opt-in: the built-in admin and user roles leave them out and can't be edited, so each reaches only members whose custom role, or a role bound to one of their groups, lists it.
• Atlassian — Jira and Confluence, which share one Atlassian connection; each switch governs only its own tools. See Atlassian: Jira and Confluence.
• Data and the web — SQL Server and Web search.

Each row counts the roles that list the extension (3 of 7 roles list this), and its help says when that count decides the outcome: in Menu mode, Off here, but members of the 2 roles that list it still get it.; in Ceiling mode, No role lists it yet, so it reaches nobody. Configure beside a switch opens that extension's settings in a panel over this section — for Jira and Confluence, the Atlassian organization settings — and closing it (×, Esc or Back) returns you to Extensions. A modified click, or opening the link in a new tab, goes to the extension's own page instead. Web search has nothing to configure. An extension switched off for the whole Strata deployment shows Unavailable on this deployment in place of its switch, with a link to Kronisys support.

In Ceiling mode, turning an extension off first checks who uses it; unless nobody would lose it, the row asks — 4 members will lose SQL Server. — with Turn SQL Server off and Keep on. Outlook, OneDrive, Teams chats, Jira and Confluence hold a stored sign-in, so for those the question also says when members will be disconnected, which turning the extension back on later does not undo; a member's Atlassian connection is removed only once neither Jira nor Confluence is left for them. In Menu mode the organization list reaches nobody on its own, so a switch turns off without asking. Each switch saves on its own, one at a time; a refused save puts the switch back, and its row reads Couldn't save. Your organization settings were not changed. followed by the server's reason when it gives one.

SharePoint rides OneDrive's sign-in: turning OneDrive off turns SharePoint off too, with a SharePoint turned off too toast, and SharePoint's switch stays disabled (Needs OneDrive) until OneDrive is back on.

Connectors your organization added are governed under Connectors, not here — each is a synthetic extension id mcp:<slug>, and Ceiling mode, role allow-lists, and per-user overlays apply to it exactly as they do to a built-in extension. In Ceiling mode, roles narrow this list further under Roles and permissions; in Menu mode, each role's own list there decides. Either way, a single member can be denied one under Members.

Per-extension configuration

Anything an extension needs beyond "may we use it" lives on the extension's own page. Configure beside an extension in Extensions opens that page in a panel over the section (for Jira and Confluence, straight to the Atlassian settings); or:

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

The direct URL is /settings/extensions/<id>/manage, visible only to administrators with canManageOrgSettings. For seven of the eight extensions this page only states what your organization decided — what is on, whether the list is a ceiling or a menu, and how many roles currently list it — and names Organization › Extensions as the place to change it; it has no availability switch of its own. Atlassian is the exception: its site URL, cloud id and write permissions are set here, and those changes apply to every member immediately.

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. With the list in Ceiling mode, 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 left for them, 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 in Extensions 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 that read-only statement — see below.

Profile

How your organization appears in Strata, who may join, and what happens to its data. Five groups: Identity (name, industry, overview, logo), Documents Strata creates (your logo and accent color on generated files), Access (invite domains, multi-factor sign-in, session timeout), Member profiles (display name, profile picture, timezone), and Account (export, suspension, deletion). The data policy and content-detection controls that used to sit here moved to Data and privacy.

Every row saves as you change it. A value the server refuses shows a red line on its own row and is not sent again until you change it — a typed value stays in the field for you to fix, a switch or a choice goes back to its saved value — and every other row keeps saving. If a save never reached the server (a server error or a dropped connection), the row reads Couldn't save yet. with Retry, keeps your value, and sends it again with your next edit or when the connection returns. Successful saves are confirmed by the one Organization settings updated toast.

Organization name — shown in the sidebar next to your logo and in member emails. Leave it blank to use your sign-in domain. Up to 120 characters; a name made only of spaces is refused. A rename reaches the sidebar as soon as it saves, and the typed confirmations for suspension and deletion ask for the new name.

Industry and Organization overview — optional context. The industry and the one-or-two-sentence overview (up to 600 characters) become part of the AI's context in every conversation, so it frames examples and terminology for your business. Choose No industry to clear it.

Organization logo — PNG, JPEG or WebP, up to 5 MB before the crop; the image is cropped to a square before it is saved, and a very detailed image is compressed to fit (a photo may be stored as a JPEG, a logo with a transparent background as a smaller PNG), so any file the row accepts uploads. Shown in the sidebar for every member, and on the files Strata creates once Put our logo on files Strata creates is on. Upload logo (Change, once a logo is set) picks a file, Remove (after a confirmation) goes back to the name alone. SVG files are not accepted. A file that is too large, empty or unreadable, or an upload the server refuses, is explained on the logo row itself.

Put our logo on files Strata creates and Accent color — branding on the PDFs, Word documents, presentations and spreadsheets the AI generates, on dashboards in the web chat and their downloads, and on downloaded chart images; off by default because these files often leave your company. When the logo would be hard to see on the color it is drawn on, Strata sets it on a small white or dark plate automatically. Files a member creates in Analysis are written by the analysis code and are not branded. The accent color is a six-digit hex such as #1b3a5c, used for rules, banners and highlights, never body text; leave it blank to keep each document's own color. A half-typed value is shown as an error on its row and is not saved.

Invite domains — only emails from these domains can be invited; leave the list empty to allow any domain. Type a domain and press Enter, or paste a list separated by commas, semicolons, spaces or new lines. The list is sorted and duplicates are merged; an internationalized domain is stored in its punycode form and shown as typed. Up to 2,000 domains. An entry that is not a domain turns red and nothing saves until every entry is valid — the server refuses the list rather than dropping the bad entry, so a restriction can never quietly turn into "anyone may be invited". Long lists fold after two rows behind Show all.

Require multi-factor authentication — every member must sign in with an MFA-backed Microsoft account, administrators included. It takes effect immediately: turning it on signs out every session that did not sign in with MFA, and anyone signing in without MFA is refused, so Strata asks you to confirm and you should check your Microsoft Entra MFA policy first. You can turn it on only from a sign-in that itself used MFA, so the person who turns it on can always sign back in to undo it. From any other sign-in there is no confirmation: the switch stays off and the row explains: Sign in again with multi-factor authentication before you require it. This sign-in didn't use MFA, so turning it on now would sign you out, and you couldn't sign back in without MFA. Sign out, sign in again with MFA, and turn it on then. From an MFA sign-in, the confirmation adds Your own sign-in used MFA, so you stay signed in. While it is on, the row reads On. Members without MFA are denied at sign-in, admins included. Turning it off is never refused. Admins without the "Manage compliance" permission see the setting but cannot change it.

Session timeout — sign members out after this long without activity; any request extends it. Choose Platform default (the menu shows what that means on your deployment — 12 hours on a standard one), a preset (15 minutes, 1 hour, 8 hours, 12 hours) or Custom in whole minutes, from 5 minutes up to your deployment's own idle window (5 to 720 minutes on a standard deployment). Only presets within that window are offered, because a longer timeout would have no effect, and no session lasts more than 7 days from sign-in whatever this is set to. A custom value outside the range is shown as an error on the row (Enter 5 to 720 minutes.) and not saved. A change reaches members who are already signed in, not only new sign-ins, and the Outlook add-in follows it too, inside the add-in's own limit of 12 hours from sign-in. Admins without "Manage compliance" see it read-only. It was on the Defaults tab before the reorganization; /admin/defaults#session still opens it.

Member profiles

What members may change about their own account. The three switches are permissions: on means members may. Turn one off and Strata uses what your directory reports, and timezone follows the member's browser. The member's matching control stops responding and shows the same Managed by badge.

Let members change their display name — off keeps the directory name authoritative in audit entries, announcements and shared work; names members already changed revert.

Let members change their profile picture — off shows every member as their initials, the same everywhere in Strata, and the picture button in their settings stops opening the picker. The picture each member picked is kept, and comes back when the switch is on again.

Let members set their own timezone — off uses the timezone the member's browser reports. This moves every timestamp they see and the clock their scheduled agents run on, so a traveling member's reports shift with them.

Account

Export organization data — opens a modal to build a single ZIP with one folder per member: conversations, messages, settings, analytics and an organization-level manifest. A signed link is emailed to you and expires in 24 hours. Needs the "Manage compliance" permission. Picking members one by one also needs "Manage users"; without it the export covers everyone. See Admin data export.

Suspend organization — pauses access for every member. Admins can still open the organization's settings to lift it. Useful for billing disputes, security incidents or planned maintenance. Type a reason (shown to members, up to 500 characters) and click Suspend organization…; you then type the organization's name to confirm. While suspended, the row says since when, shows the reason, and offers Lift suspension (which asks for the name too). Suspension flips members to a 403 "Organization suspended" response (carrying the reason you set) within about 30 seconds, as sessions re-hydrate org policy. The audit log records org.suspended and org.unsuspended with the reason. Needs the "Suspend organization" permission; everyone else sees the row, and the banner, with a sentence naming who can lift it.

Delete organization — requests permanent deletion of your organization and every member's data. Kronisys Inc. support must approve before the 30-day window starts, and you can cancel any time until the deletion date — on the day itself, until the deletion runs. Requesting needs the "Suspend organization" permission; cancelling needs only access to the organization's settings. A deletion that started automatically because the subscription ended cannot be canceled here — reactivating the subscription stops it. See Organization deletion.

Data and privacy

What Strata keeps, what it records, who may read conversations, and what may leave your organization (/admin/data-privacy). The section has five groups, in this order: Retention, Audit log, Oversight, What can leave your organization, and a collapsed Advanced data protection card. The data-egress rules, the audit detail level and the tamper-evident log all live here. The section is in the language you chose in Settings, with counts, dates and numbers of days written your language's way; inside Advanced data protection, each detector's own description and its Will get wrong note are in your language too, keeping the cue words, code and sample values they quote as the detector reads them, and the code samples under For your developers stay exactly as your endpoint receives them.

The section opens for anyone who can open the organization's settings, and the groups inside it carry their own guards. Retention and What can leave your organization need nothing more. In Audit log, the retention and detail rows need canManageCompliance, and the tamper-evident log and the Open the audit log link need canViewAudit; with neither, the group is left out. Oversight needs canManageOversight and is left out without it. Advanced data protection needs canManageCompliance; without it the card is replaced by Advanced data protection needs the "Manage compliance" permission. Ask an owner to grant it.

Everything except Advanced data protection saves as you change it. Shortening a deletion window (Purge deleted chats after, Delete generated files after, or Keep audit entries for) asks first: a notice on the row reads This shortens the window from … to …., counts what would go (for example 1,204 deleted chats older than 30 days will be purged within the hour and cannot be exported afterwards.), and offers Purge after 30 days (Delete after … for files and audit entries) or Keep with the old value (Keep forever when there was no limit). Nothing is saved until you answer, and Keep puts the old value back.

Retention

How long Strata keeps each kind of data. Blank keeps it indefinitely, except on the two archive controls, where blank restores their default.

• Purge deleted chats after — 1 to 3650 days. When a member deletes a chat it disappears from their view but is kept for admin export until it is purged; after this many days the row is hard-deleted (the purge runs hourly). Saves when you leave the field.
• Delete generated files after — 1 to 3650 days. Generated PDF, Word, Excel and PowerPoint files are deleted once they reach this age, counted from when each file was made. It applies to active chats too, not only deleted ones.
• Archive messages after — 7 to 3650 days; blank restores the default of 90. Older messages move out of the live table. Nothing is deleted and members still see their chats; older ones just take a moment longer to open.
• Move archived messages to cold storage after — 30 to 3650 days; blank restores the default of 730. Archived messages older than this move again, to low-cost blob storage. Still nothing is deleted, and an admin export still finds them.

Audit log settings

What the audit log records and how long it is kept, with an Open the audit log link for admins who can read it. The log itself is its own section: see Audit log.

• Keep audit entries for — 90 days, 1 year (the default), 3 years, 7 years, or Custom, which shows a days field (30 to 3650). Older entries are deleted once a day. Needs canManageCompliance.
• Detail level — Standard, Compliance, or Forensic. Applies to new events only. Needs canManageCompliance. See Audit detail level for what each tier records.
• Alerts for blocked requests — off by default. Needs canManageCompliance. While it is on, Strata records each request the AI provider's content filter blocks, and each one that matches one of your custom data rules, in the audit log under Content safety: who, on which surface, with which model and why, never what was written. Admins who hold both Access admin panel and Manage compliance, through their own role or a group's, also get an Inbox alert naming the member when the request was typed in the web app, the iOS app or Teams: at most one a day for each member and ten a day for the organization. The member who was blocked is never alerted about themselves. Requests from the Outlook add-in, scheduled agents, the API, sub-agents and voice are recorded and counted, never named in an alert. A block whose only category is self-harm never names the member, and the audit row records it as sensitive. Members are told in their privacy settings and on the blocked request. The provider's filter covers GPT and Grok models. On Claude, a request Claude itself declines (its safety checks stopped it) is recorded too, never in an alert naming the member, because those checks also stop some legitimate requests; your own data rules can flag a request on any model. While the switch is off nothing is recorded at all. A line under the row counts what was recorded in the last 7 days, with a link to those entries in the audit log for admins who can read it.
• Tamper-evident log — a reading, not a setting. Needs canViewAudit. Every entry is hash-chained to the one before it, so a record altered or removed outside Strata is detectable. The chain is checked when this page opens, and again when you come back to it once the last answer is more than a minute old. The row reports:
  • Intact (green), with how many events were verified. Events outside the chain are normal and named in one line under the row: the oldest ones, from before the chain started, and the newest ones, which the chain picks up within the hour.
  • Not started yet or No events yet, when nothing is chained yet.
  • Integrity check failed (red), with the time of the event where the chain broke, as the audit log lists it, and what to do first.
  • Couldn't check right now, with a Retry link, when the check could not run. It runs at most 10 times a minute per organization; past that, the row counts down the seconds until you can retry.

Oversight

Member chat oversight opens members' conversations to administrators who also hold the "View member chats" permission, granted under Roles — the switch alone grants nothing. It is off unless you turn it on, and never silent: every access is written to the audit log with the admin's name and the conversation opened. While it is on, the row reads On. Admins with "View member chats" can read member conversations. Each access is logged with their name. Shown only with canManageOversight. Admin data exports need this switch on too.

What can leave your organization

Rules for what Strata may send out through your connected extensions, and what it may take in from the open web. Every rule is off by default, and every change is written to your audit log. Under each rule, a line says what the current choice does.

• Email to external recipients — No restriction, Warn before sending, or Block external sending. Applies to every send Strata makes on a member's behalf, by a person or a scheduled agent; a recipient is internal when their domain matches the sender's or is on Partner domains. With no restriction a person still confirms every send, and a scheduled agent still cannot send outside your domain and your partner domains. Warn before sending names the external recipients and their domains in the confirmation; Block external sending refuses the send and saves the message to Outlook Drafts, so a person can review it and send it by hand.
• Partner domains — domains that count as internal, for the rule above and for scheduled agents, which are otherwise limited to the sender's own domain. This list always applies, whatever the email rule says.
• Files into and out of OneDrive — No restriction, A person must approve, or Block saving and sharing. Covers saving a generated file or an attachment into OneDrive, and creating a sharing link or invite; moving and renaming inside the drive is not affected. Under A person must approve every save and share needs an explicit confirmation, and a scheduled agent, which has nobody to ask, is refused. Under Block saving and sharing members can still download the file from the chat.
• Web pages and search results — Any public site, Only approved domains, or No web pages or search. One rule governs both ways the open web reaches Strata: a page a member asks it to read, and the results of a web search. Private and internal addresses are always refused. Under Only approved domains a link outside the list is refused and search results outside it are removed before the model sees them — which is the half that matters most, because the AI usually answers from a search snippet without ever opening the page — and Strata tells the member their organization sets the list rather than reporting that it found nothing. No web pages or search withholds both capabilities from the model entirely; members can still paste a page's text into the conversation themselves.
• Approved domains — used only under Only approved domains, and inactive otherwise. A domain covers its subdomains, so python.org allows docs.python.org and does not allow evil-python.org; the row shows an example from your own list. Choosing Only approved domains while the list is empty is not saved: the rule's row reads Not saved yet: waiting for an approved domain below. until you add one, and removing the last domain under that choice is held the same way. If the list is ever empty under that choice, nothing is allowed and the row says so.
• Conversations in feedback to Kronisys — off by default. When a member rates an answer they can send Kronisys, the makers of Strata, a note about it, with an issue type and diagnostics of that answer: the model, how long it took, the token counts, and the tools it used with whether each failed. Without this switch that is all that goes — never the chat. With it on, the feedback form also offers Include this conversation, unticked; ticked, the member’s chat up to that answer goes with it (its last 60 messages at most), except any turn your retention rules or a data policy kept out of history. Deleting the chat removes that copy. Kronisys keeps feedback 90 days, with the note and the chat encrypted, and removes it with a member’s or the organization’s erasure. Each one sent is written to your audit log under Feedback (feedback.sent_to_kronisys, with whether the chat went), never with the note or the chat. Shown only with canManageCompliance.

Document previews never leave Strata: Word and PowerPoint files are converted on Strata's own servers, and spreadsheets and PDFs are drawn in the browser, so there is no outside viewer to allow or block.

Advanced data protection

A collapsed card at the bottom of the section for checking messages and answers for sensitive data before and after the model sees them — with an HTTPS endpoint you run, a data-security vendor, or Strata's own detectors. Its header shows one status for both sources, such as Not configured, Switched off, Shadow mode, Recording only, Enforcing, or Circuit breaker tripped, with the rollout share and which sources are on. Click Open to expand it. Needs canManageCompliance; see Data-loss-prevention policy hook for how the checks behave. Under the status, short lines say what the checks did in the last 7 days (with a link to those rows under the audit log's Data policy filter, for admins who can read the log) and when the setup last changed, with a link to that reference.

Inside, Content detection, What to look for, Your own rules and Try it on some text come first and configure Strata's own detectors. Who answers (your own endpoint or a data-security vendor) and Response inspection (what happens to a matched answer: Off, Retract, Hold or Mask) configure the policy hook. Pilot and rollout (shadow mode, the rollout percentage, and what happens when a check cannot run) comes last and governs both, for every organization, with or without an endpoint.

Unlike the rest of the section, the card does not save as you go: one Save data protection button saves both halves, and while a change is unsaved it stays at the bottom of the window. The detectors are written first. If one of your rules is refused, nothing is saved and the rule is marked on its card; if the rest is refused after that, the card says Content detection saved. Endpoint, answer and pilot settings couldn't save: … and marks the field. A successful save reads Saved · reaches every server within 30 seconds (the interval your deployment uses). If you try to leave with an unsaved change, Strata asks Discard unsaved changes? and names Advanced data protection. Once an endpoint or vendor is set up, Remove configuration… forgets it and destroys its stored secret or API key; Strata's own detectors and the pilot settings (shadow mode, the rollout, the answer posture and the failure setting) stay as they are, and the confirmation says so. To pause without losing your setup, turn endpoint or vendor enforcement off instead.

Database connections

SQL Server databases set up once for the organization. Members use them at the access level you grant, and never see the password. Among the settings, the section also needs canManageOrgConnections (Manage org DB connections); it lives at /admin/database-connections, and /admin/connections opens it too. An admin who holds that permission without canManageOrgSettings cannot open the organization's settings, so the Organization navigation gives them a standalone Database connections page at /admin/connections with the same connections list and no private connectors. See Org-managed database connections for the full reference.

Add connection sits in the section header. The table shows each connection's Name (click it for the port, SQL login, certificate setting, who created it and who changed it last), Server / database, Health, Access — how many people have viewer, editor or admin access to it — and Created. Health is the result of the last Test connection an admin ran: Reachable, Failed with the reason, or Not tested; a switched-off connection reads Disabled. Nothing is tested on load. The row's ⋯ menu holds Test connection, Edit, Disable (or Enable) and Delete…. Editing the host, database, SQL login, password, port or certificate setting clears the last test result, so the row reads Not tested again.

While SQL Server is off for the whole organization — the Extensions list is a Ceiling that leaves it out — a notice says SQL Server is turned off for your organization. The connections cannot be used, and Test connection is refused, until it is turned on under Extensions.

Private connectors, below the connections, reach a SQL Server inside your network without opening a firewall port. Provisioning on Strata's side is automatic; your network team installs Microsoft's Hybrid Connection Manager inside your network — outbound HTTPS only — using the connection string from Setup, which opens by itself after New private connector creates one. Then point a connection at it: in Add connection or Edit, choose the connector under Reach the server through. Each connector shows its Target, whether its Agent is Connected or Waiting for agent, and what it is Used by. Remove 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 giving the count (Couldn't remove sql01-hcm: it is still used by 2 connections.) and See which for the organization's own; members have to remove their personal connections themselves. A deactivated member's personal connection does not block it.

Agents

Limits for scheduled agents across your organization, and the templates your team can deploy in one click.

Rules for everyone, effective now holds Freeze agent changes. While it is on, nobody, admins included, can create or edit an agent. It does not pause anything: existing agents keep running on their schedules, and scheduled, manual and webhook runs continue. To stop one agent that is misbehaving, pause it on its own page. While your organization is suspended, a red notice at the top of the section says No agent runs while your organization is suspended. — scheduled, manual and webhook runs resume when the suspension is lifted — and the limits and templates can still be changed.

Count and frequency holds agents per member, runs per member per day and the minimum time between runs (in minutes); Cost holds spend per run and monthly spend per agent (in dollars), with tokens per run under Advanced: tokens per run. Each has a No limit or Limit choice. A limit of 0 agents per member blocks new agents; every other limit must be above 0. Agents per member is checked when an agent is created and the minimum time between runs when one is created or edited, so agents that already exist are not affected. Runs per member count every run — scheduled, webhook, manual, test and agent-invoked — and further runs are blocked until midnight UTC. Monthly spend per agent applies to each agent separately, not to a person or the organization. The 5-minute platform floor and any plan limit (a self-serve trial allows 2 agents per member and one run an hour) are shown under the field. A value that cannot be saved is refused on its own row and put back when you leave the field, with the reason: Couldn't save: enter 5 minutes or more. Reverted to 15. See Rate limits and quotas for the full reference.

Organization agent templates is the org-wide agent templates library: reusable agent shells you publish once and every member can deploy in one click, from Create from a template in their agents page. A template on a model your organization has turned off is tagged Not allowed, and one on a retired model Retired. Click a template (or press Enter on it) to see who is using it: each deployed agent's owner, its last run, its run count, and an honest status — Active, Paused, Blocked by monthly cap, Frozen, Expired or Failing. Blocked by monthly cap comes from the scheduler itself: it shows only when that agent's latest run this month (UTC) was refused at the monthly spend limit, so an agent close to the limit still reads Active, and raising the limit clears it. Frozen means creating and editing are blocked for that agent — by Freeze agent changes or its owner's per-member lock — while it keeps running. Edit template opens the template form from there. Deleting a member's agent from that page needs the Manage users permission.

A line at the bottom links the agent controls that live elsewhere: approvals for scheduled agents in Member defaults, who can create agents in Roles, and per-member agent locks in Members.

AI engine

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 for chat, agents, documents, voice and the API stays inside your Foundry: no prompt or data from those features is sent to a Kronisys-controlled model. The in-product help assistant is the sole exception: Kronisys hosts it.

The section is shown only to admins with Manage AI provider key. An admin without it who follows a link to /admin/ai-engine sees Only owners can manage the AI engine, whether your organization's AI is connected, and which permission to ask an owner for. Nothing in the section auto-saves; it has three parts:

• The status card says what is true now: Connected to your Azure AI Foundry, with the endpoint, the stored key as dots, the date it was configured and a line saying how many of your enabled models are deployed there, with a See in Models link (checked when you open the section); No Azure AI Foundry connected; or, when the stored connection stops working, Strata can't use your Azure AI Foundry or Strata can't reach your Azure AI Foundry, with the reason in red.
• Change AI engine… — Connect your own Foundry… before one is connected, Reconnect your Foundry… when it has stopped working — opens the Foundry endpoint and API key form. Verify & save asks you to type your organization's name, then checks both before anything is saved; a failed check is never applied.
• Deployment names — the voice, transcription and embedding deployment names, if your Foundry uses different ones — save on their own with Save deployment names, with no key and no typed confirmation. The group appears once your own Foundry is connected.

The section is in the language you chose in Settings, with each count said your language's way; the endpoint, your deployment names and the names of models stay as written.

See Bring your own Azure AI Foundry for the full setup.

Connectors

Outside tool servers your AI can use, added by your organization. The first-party extensions (SQL Server, Outlook, OneDrive, SharePoint, Teams, Jira, Confluence, web search) cover Strata's deep integrations and live under Extensions. Connectors is where you add the long tail beside them: additional tools that speak the Model Context Protocol (MCP) — an internal server your team stood up, a vendor's read-only catalog, a niche public tool. Requires canManageOrgSettings.

Add connector and Check all sit in the section header. The table lists each connector — its name, its address, and, where it applies, Authenticated or Each member signs in — with Who can use it (All roles, 3 of 7 roles with the first few named, or Nobody yet), Tools (how many of the server's tools the AI is actually offered, and whether read-only), Status (On, Off, Error, Needs a key or Needs sign-in) and an On switch that pauses or resumes the connector without opening it. Click a row to edit it; its ⋯ menu holds Edit, Check now and Delete…, and Delete says what else goes with it, such as every member's sign-in. With more than 25 connectors, a Filter connectors field appears above the table. See Connectors for what each column means.

• Add from the catalog. Strata ships a tested catalog of remote MCP servers (for example Dropbox, Cloudflare, and PayPal). Pick a server, supply its credential if it takes one — a key or a sign-in — and test it; its tools then become available to members who turn the connector on, and the AI shows each connector's own logo in the action-step trail.
• Read-only by default. A connector's tools are read-only until you say otherwise. Every request goes through Strata's outbound network rules, and whatever a connector returns is treated as untrusted text.
• Governed like any extension. Each connector is governed as a synthetic extension id mcp:<slug> — for a catalog connector, the summary line in its form shows it as the permission id — so the organization's extension list in Ceiling mode, each role's allowed list, and each member's per-user overrides all apply to it — see Extensions and the Extensions list on a member's Access tab in Users. A role saved with no extensions ticked reaches no connector. Unchecking a connector for a member withholds its tools from that person on every surface while the connector itself stays configured here.
• Deployment kill switch. Kronisys can turn connectors off for the whole deployment. The section then says Connectors are turned off for this deployment.; existing connector rows are still shown and their switches still save, but nothing is offered to the AI, and nothing can be added or checked.

Note

Only remote MCP servers are supported — Strata never spawns a local process. Once a connector is added and on, each member turns it on for themselves from the Connectors tab of the Directory; its tools then appear in their chats like any other extension's, tagged with the connector's own logo in the action-step trail. See Integrations overview.

Atlassian: Jira and Confluence

Not a section of this page. The two availability switches, Jira and Confluence, are in the Atlassian group of Extensions. Everything below is set on the Atlassian extension page: click Configure beside either switch, or open Settings → Apps → Atlassian → Manage → Organization settings (/settings/extensions/jira/manage). The old /admin/atlassian and /admin/jira links still work and open the Atlassian extension page (/settings/extensions/jira). The Atlassian page states the availability decision read-only.

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 the organization's 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 turn both Jira and Confluence off in Extensions, with the list set to Ceiling — in Menu mode, a role that lists them still gets them. 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 every save writes an org.jira_config_updated 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, which is audited as org.jira_site_pinned.

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 → Apps (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. Atlassian never widens a connection afterwards, so turning writes on does not change connections members already made: each of them has to reconnect before Strata can write to Jira for them. Once the switch is on (in Each person signs in mode), a note under it says so, with how many members who may write still have a read-only connection and how many older connections will be checked the first time they write. Those members see a Reconnect notice on their Atlassian extension page. See Connections made while writing was off. 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 (Organization → Users → (manage user) → Access). 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, under the toggle it governs, by the same rule every other lock follows: a padlock belongs on the row of the thing it pins.

Allow comments on service requests appears only once writes are on, is off by default as well, and turns off again whenever writes are turned off. 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 uses your deployment's default — 2,000 requests per hour on a standard deployment — and the field's help says what that default is. It does not remove the limit unless your deployment sets no default, in which case the field says so. A platform-wide ceiling of 10,000 per hour applies across all organizations and is consumed first.

Confluence group

The Confluence scope group on the same page, saved by its own request, below the Jira settings. 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 pages and comment 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. Its write access at connect time follows this switch, not Jira's, so members who connected while Confluence writing was off have to reconnect before Strata can write to Confluence for them, even if Jira writing was on; the same note appears under this switch. Strata creates pages and adds page comments; there is no tool that edits an existing page.

Apply to everyone, with no exceptions appears under the Confluence writes toggle once writes are on, and works like Jira's: with it on, the role and member Confluence writes settings stop applying and this toggle alone decides; turning Confluence writes off clears it. It is a separate lock from Jira's, so an organization can pin one product and leave the other per-person.

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 log

The organization's audit log (/admin/audit), in the rail's Data and oversight group: 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 paging. The section appears only for admins whose role grants canViewAudit; exporting additionally requires canExportAudit. An admin with canViewAudit but not canManageOrgSettings can't open the organization's settings, so for them /admin/audit opens the Audit log as a page of its own, with no rail, and the admin sidebar lists it as Audit log. The log's retention and detail level are set, and its tamper check runs, on Data and privacy, under Audit log settings. See Audit log for the full reference, including the action vocabulary, detail tiers, and retention.

Provisioning

Connect your identity provider so it creates and deactivates Strata accounts and keeps names and groups in sync with your directory (/admin/provisioning, needs canManageOrgSettings). The section has three parts: Provider status, which says whether your provider is connecting and what it manages (reading it needs canManageUsers); Connect your provider, with 1 · Tenant URL and 2 · Create a token (creating a token needs canManageApiKeys); and Tokens, every token that hasn't been revoked, newest first, each with one status and a Revoke button, with revoked tokens behind Show N revoked tokens. A token that stopped working more than 30 days ago is no longer listed, only counted in a line under the list, which points to the Audit log while the log still holds that token's record. The section is in the language you chose in Settings, with dates, times and counts written your language's way; a token's name, the people named in its activity, SCIM 2.0, Microsoft Entra and Okta stay as written. See SCIM provisioning for setup, token lifetimes and provider configuration.

Support

Your organization's tickets with Kronisys (/admin/support). Before you write points to the in-app assistant first (Ask the assistant), which searches the Strata documentation; open a ticket for what only Kronisys can do — billing, account changes, or a bug Kronisys has to look at.

Your tickets are shared with your organization, so a colleague can pick one up. The filter reads Waiting on you, Open, Closed and All; the first two show a count, and tickets waiting on you sort to the top of Open and All. Each row shows the subject, an Urgent tag where set, and a line with the reference (such as STR-7K4MQ2), category, message count, who wrote last and when. New ticket asks for a Subject, a Category (General question, Something is broken, Billing or plan, Access or permissions, Feature request, or Other), a Priority (Low, Normal, High, or Urgent — production is down) and What is happening?, and sends it with Send to Kronisys. Kronisys replies by email and the thread stays here; open a ticket to Send reply or Close ticket. Below the list, the support address is given for anyone who prefers email; an email conversation stays in your inbox rather than on a ticket.

Tickets can be read and filed by anyone who can open the organization's settings (the built-in admin role or canManageOrgSettings).

Saving changes

Most of the page has no Save button. Member defaults, Profile, Agents, Data and privacy (apart from Advanced data protection), the two rows on Models (Default model for new members and Move to the replacement when a model retires) and the Extensions mode — padlocks included — save as you change them, sending only the settings you changed to PATCH /api/admin/org: a switch, choice or padlock about 350 ms after you change it, a typed value about 350 ms after you stop typing. A few fields save when you leave them instead, because a half-typed value would do harm: the three retention windows (deleted chats, generated files, the audit log), the two archive tiers, the preview link lifetime and the accent color. A custom session timeout saves when you leave the field or press Enter. A few changes ask first and send nothing until you confirm: shortening a retention window asks in the row, and choosing one conversation tone for everyone or turning on Require multi-factor authentication opens a confirmation. Each save that lands shows an Organization settings updated toast, refreshed rather than stacked while you keep editing. The logo, export, suspension and deletion on Profile are actions of their own.

A save that does not land is reported on that setting's row, and every other row keeps saving:

• A value that cannot be sent — a half-typed or out-of-range number, an entry that is not a domain, a color missing a digit — is held back. The row says why (Enter a number., for instance), the field keeps what you typed, and nothing is sent until you fix it.
• A value the server refuses shows the server's reason on its row. A typed value stays in the field for you to correct; a switch, padlock or choice goes back to its saved value, and the row reads Couldn't save. Your organization settings were not changed. followed by the reason. A refused value is not sent again until you change it.
• A server error or a dropped connection shows one Couldn't save toast (Strata couldn't be reached. or Strata ran into a problem saving., then Your change isn't saved yet., or Your changes aren't saved yet. for several), and each unsaved row keeps its new value with the line Couldn't save yet. and a Retry button. Those values are sent again with your next change, when your browser is back online, or when you press Retry; the line clears once the value saves.

The six agent limits are the exception to keeping what you typed: on Agents, a limit that is held back or refused is put back to its saved value when you leave the field, and the row says so (Couldn't save: … Reverted to 15.).

Leaving the page with a change that is unsaved or held asks Discard unsaved changes? (Your changes to Organization will be lost if you leave this page.), with Stay on page and Discard changes.

The other sections save their own way. Each Extensions switch sends its own PATCH on click, because the switches all write one shared list; in Ceiling mode, turning one off first checks who uses it and, if anyone would lose it, asks in the row. A switch that saves is silent, and one that fails goes back with the same Couldn't save line. Model enable/disable is owned by the Model Catalog, which saves each toggle on its own after a confirmation — see Models. Advanced data protection on Data and privacy has one Save data protection button for both the AI data policy and content detection. AI engine saves the endpoint and key through Verify & save and the deployment names through Save deployment names. Database connections, Connectors, Provisioning, Support and the Audit log manage their own state.

The Atlassian configuration lives on the Jira extension page and auto-saves 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.

Padlock, model, and extension changes take effect on the next member request: active sessions re-hydrate org policy at most once every 30 seconds, so changes propagate within about half a minute. A member's sidebar and Directory show an extension change without a reload, the next time their Strata tab comes back into view or focus (at most once 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