Skip to main content
Organisation Settings is where Admins control how the workspace operates: the organisation name, how email notifications for finding discussions behave, the prefix used in finding identifiers, the domains you have proved you own, and single sign-on. Open it from the user menu in the top-right corner.
Only Admin and Owner roles can edit organisation settings. Other members see a read-only view of the same information.

​
General information

The general section shows your organisation’s name and discussion notification defaults.

​
Organisation name

The display name for your organisation, visible to all members throughout the platform. Admins can change it at any time. Saving requires step-up verification.

​
Discussion reply emails

When someone (Borg or a teammate) replies in a finding’s discussion thread, Odin can send an email so you don’t miss it.
  • Discussion reply emails (toggle): when on, all members receive emails for new discussion replies on findings, unless overridden by each user in their profile. When off, no emails are sent by default — only users who opt in via their profile receive them.
  • Minimum severity for reply emails: only findings at or above this severity trigger reply emails. Defaults to all severities.
Mentions (e.g. @alice) always send an email, regardless of severity threshold or the organisation default.

​
Finding identifiers

Every finding in your organisation gets a unique identifier like ACME-42. The prefix (ACME) is your finding prefix — choose something short and memorable, typically your organisation’s abbreviation. The prefix can be set once during onboarding and changed afterwards. Changing it renumbers nothing — existing findings keep their identifiers, new findings use the new prefix going forward. Saving a new prefix requires step-up verification.

​
Default finding subscribers

Owners and Admins choose who is subscribed automatically when a new finding is reported, from the Default finding subscribers setting:
  • All members — every member is subscribed automatically, except Read only users. This includes people who join the organisation later.
  • Custom — only a selected list of members is subscribed automatically.
This only sets the starting subscriber list for new findings. Individuals can still follow or unfollow specific findings themselves, regardless of the default.

​
Verified domains

The Verified Domains card is where you prove you own an email domain with a DNS TXT record. Verifying one unlocks single sign-on and automatic team joining for the people who use that domain. Mjolnir pentest setup can also prove a scan target with a file or CNAME. That is only authorisation to test the domain — it does not enrol it for single sign-on. Those rows stay on this list as Verified with a Pentest only badge. Publish the TXT record shown on the row and select Re-check. Odin keeps the pentest proof if the TXT record is not there yet. Only Owners and Admins can see and manage this card.
1

Add the domain

Type the domain (for example example.com) and select Add domain. It appears in the list marked Pending, with the DNS record you need to publish.
2

Publish the DNS record

Copy the Type, Name and Value fields onto your DNS provider as a TXT record. Each field has its own copy button.
3

Re-check

Select Re-check on the row. Odin looks up the record and flips the badge to Verified. On a Pentest only row it looks for the TXT record and, if it is there, drops that badge so the domain can be used for single sign-on. DNS changes usually appear within a few minutes, so if the badge still reads Not found, wait a moment and check again.
If your DNS provider supports Domain Connect, Odin offers to publish the record for you instead. A panel appears above the manual instructions reading Add the record with Cloudflare (or Add the record automatically for other providers). Select it, approve the request at your provider, and Odin re-checks the domain when you come back. Each row carries a status badge: Verified (DNS TXT, ready for single sign-on), Verified plus Pentest only (Mjolnir file or CNAME), Pending while the record is not visible yet, or Not found when the last lookup failed.
Removing a verified domain disables the features that depend on it, including single sign-on and automatic team joining. Odin asks you to confirm first.

​
Single sign-on

The Single Sign-On card lets your team sign in through your own identity provider over SAML or OIDC. It needs a verified domain and a Business or Enterprise plan. On other plans the card lists what single sign-on unlocks and links to the upgrade page. Only Owners and Admins can configure it. Other members see the connection’s status, or a note saying an administrator can set it up.

​
Connecting an identity provider

The card shows the values to enter on your side first: the ACS (Single Sign-On) URL and SP Entity ID / Audience for SAML, or the Redirect URL for OIDC. Copy those into the application you create in your identity provider, then fill in the Odin form:
  • SAML: give Odin either an IdP metadata URL or the metadata XML pasted in full
  • OIDC: give Odin the discovery URL, client ID and client secret
  • Display name (optional): a label such as Okta, shown wherever the connection appears
  • Verified domains: tick every domain whose users should sign in through this connection. At least one is required. Only domains verified with a DNS TXT record are listed — a Mjolnir file or CNAME check is not enough.
Select Connect identity provider to save. The card then shows the connection with its type, status and sign-in domains.

​
Managing a connection

Once a connection exists, Admins can:
  • Disable it temporarily, and Enable it again later. A disabled connection stops routing sign-ins without losing the configuration.
  • Reconfigure it to change the metadata, credentials or domains.
  • Remove it entirely. Members who signed in through it fall back to a one-time code.
Single sign-on relies on a service Borg runs for your environment. Until it is provisioned the card explains this and the form stays read-only.

​
Organisation overview

A summary card shows key details about your organisation:
  • Members: the current member count, with a link to Team Management for admins
  • Status: your organisation’s current status
  • Products: which products are active on your subscription
  • Created: when the organisation was created

​
Domain join

If your organisation has domain join enabled, anyone with an email address matching your allowed domain(s) can join automatically without an invitation. Domain join is configured by Borg as part of onboarding. It appears as a read-only field on the General Information card. Contact [email protected] if you need it enabled or changed. Domain join is separate from the verified domains list: verified domains are the ones you have proved you own, and they are what single sign-on is bound to.
Domain join is powerful — anyone with a matching email can join. We only enable it for verified company domains, never for shared providers like gmail.com.
The Legal & Agreements card links the documents that govern your use of the platform:
  • Master Services Agreement, Data Processing Agreement, and AI Services Addendum — the agreements an Owner accepted during onboarding, opening as PDFs
  • Privacy Policy and Subprocessors — the in-app policy pages
Every member can open these links, regardless of role. The same documents are also collected on the /legal page.