Organisation policies

Every row on this page is visible only to an owner or an administrator of this organisation; a member reads none of it.

What this does for you

This page walks an administrator through Organisation → Policies, control by control, and names the audit row each one writes.

Before you start

• You are signed in as an owner or an administrator, on Organisation → Policies.
• To relax residency to Anywhere a route requires, you are the owner — an administrator sees the option but cannot use it — and you know the organisation's name exactly as it is spelled, because the confirmation compares it case-sensitively.
• A plugin's own Allowed, Blocked or Required state is set on the plugin's own detail page, not here; this page only reads it back.

Steps

1. Turn Botseon for this organisation off to stop every run start for every member at once — chats, routines and channels alike — with nothing deleted, or back on when the reason has passed. Turn Work with people outside this organisation on to let a bot hand a task to somebody who is not a member, by mail or a shared link; it is off by default. Both writes an audit row (org.product_toggled, org.delegation_toggled).

   <!-- shot: policies-01-phone.png | The product switch and delegation, on a phone --> <!-- shot: policies-01-desktop.png | The product switch and delegation, on a desktop -->

2. Choose where model calls may be processed: EU/EEA only (the default), EU/EEA first, or Anywhere a route requires. The first two commit at once; the third opens a panel that asks the owner to type the organisation's name before it takes effect. Every choice writes org.residency_changed to the audit log, and the confirmation panel's typed name is kept on the organisation's own settings row, never inside the audit body an export hands to a third party.

   <!-- shot: policies-02-phone.png | The residency control, on a phone --> <!-- shot: policies-02-desktop.png | The residency control, on a desktop -->

3. Read back each plugin's policy, and choose which models bots in this organisation may use. Ticking one or more boxes in the Model allowlist and saving writes model.allowlist_changed with the list before and after; leaving every box unticked allows every compliant model. A plugin's policy, set on the plugin's own page, writes no audit row at all — it is the one control on this page whose change the audit log does not carry.

   <!-- shot: policies-03-phone.png | The plugin policy list and the model allowlist, on a phone --> <!-- shot: policies-03-desktop.png | The plugin policy list and the model allowlist, on a desktop -->

4. On a team organisation, turn on Bring your own key to run calls on a provider you hold a key for, drawing nothing from the shared allowance; your residency policy still decides which of that provider's routes may be used. This writes org.byok_changed. Choose who members may publish templates to — Off, Team (the default) or Public — with the segmented control before the Network row; switching to Team moves every public template back to the team at once. This writes org.template_sharing_changed, and the saved notice names how many templates were moved.

   <!-- shot: policies-04-phone.png | Bring your own key and template sharing, on a phone --> <!-- shot: policies-04-desktop.png | Bring your own key and template sharing, on a desktop -->

5. Open Organisation → Packages to review a plugin package a member submitted: the manifest, its skill documents and its server configuration exactly as written, and the advisory findings beside them. Approving publishes it; rejecting needs a note the author reads. Either decision writes package.reviewed.

   <!-- shot: policies-05-phone.png | The package review queue, on a phone --> <!-- shot: policies-05-desktop.png | The package review queue, on a desktop -->

A worked example

An audit row for a residency change reads back roughly like this once decrypted and rendered for export:

{
  "action": "org.residency_changed",
  "actor_user_id": "1f2e-…-a9c4",
  "target": "1f2e-…-a9c4",
  "details": { "from": "eu_only", "to": "eu_first" }
}

What can go wrong

See also

• Members and access requests
• Data residency and rights