> For the complete documentation index, see [llms.txt](https://docs.rootcause.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rootcause.ai/more-details/organisation-administration.md). # Organisation Administration The **Organisation settings** page manages everything about the organization itself: its identity, its roles and their permissions, its members, how new people join, and the OAuth apps its connections sign in through. Open it from the Organization home under Manage, or from the account menu in the top-right corner. For the container model (organizations and workspaces), see [Setup Org and Workspace](/start-here/navigation.md). *** ## OAuth apps The **OAuth apps** section holds the app registrations this organization's connections use to reach API providers: Google Drive, Google Analytics 4, HubSpot, Ramp, Salesforce, or any other OAuth 2.0 API. Register an app once and every connection in the organization can sign in through it. {% hint style="info" %} These are the registrations RootCause uses to reach *your* providers. Apps that authenticate users *against* RootCause are registered on the API page instead: see [OAuth Apps](/api-and-integrations/api-access/oauth-apps.md). {% endhint %} Each entry lists its app ID, its provider, whether it connects by **User consent** or **Machine access**, whether it is an **Organisation app** or a **Platform app**, and the API origins it may reach. Platform apps are registered by the deployment and cannot be edited here. Adding and editing an app needs write access to **Organisation Settings**. **Add app** opens the editor: * **API provider**: picking HubSpot, Google Drive, Google Analytics 4, Ramp, Ramp sandbox or Salesforce fills in that provider's endpoints, scopes, allowed origins and client authentication, and links its setup documentation. **Custom API** leaves them to you. The provider cannot be changed after the app is saved. Salesforce also asks for your **My Domain** HTTPS origin, and builds its endpoints and allowed origin from that. * **Connection method**: **User consent** for the authorization-code flow, or **Client credentials (machine access)** where the provider supports it. * **Register this redirect URI with the provider**: the callback to paste into the provider's own app settings. It is fixed per app and identical for every connection that uses it. * **Client ID**, **Token endpoint client authentication** (HTTP Basic, client secret in the request body, or a public client with no secret) and **Client secret**. The secret is stored encrypted and never shown again; editing an app keeps the stored secret unless you enter a replacement. * **Issuer URL**, **Authorization URL**, **Token URL** and **Allowed API origins**: free for a custom API, and fixed by the profile otherwise. The allowed origins bound which API hosts the app's access tokens are ever sent to. * **Scopes**: a profile starts from the scopes it needs and accepts only the ones that provider supports; a custom API takes whatever the provider documents. * **Advanced provider settings**: PKCE (S256), a revocation URL, the access token header and prefix, and extra authorization and token parameters. Those parameters are sent as given, so keep secrets out of them. A Google Drive app also takes a **Google Picker browser API key** and the **Google Cloud project number** of the same project as its OAuth client, which is what lets its connections open Google's file chooser. Restrict the key to the platform domain, `https://docs.google.com/*` and the Google Picker API. Left empty, a platform app falls back to the deployment's own picker settings. Connections pick an app in the OAuth panel on the connection itself: see [Google Drive](/data-sources-and-connectors/connectors/google-drive.md) and [REST API](/data-sources-and-connectors/connectors/rest-api.md). Changing an app's registration means reconnecting the connections that use it. *** ## Organisation Details The organization's basic identity. Click **Edit Details** to change the name. Two brand assets can be uploaded (SVG, PNG, JPEG, or WEBP): * **Logo** — the full wordmark, displayed in the header of public apps. Cropped to a wide 3:1 frame; SVGs are kept as-is. * **Icon** — a square mark used where a full logo doesn't fit. Cropped to a 1:1 frame. Use **Replace** or **Remove** on each, or drag and drop an image file.
The Organisation settings page with the Organisation Details section: the organisation name Acme Corp, the uploaded logo wordmark and square icon each with Replace and Remove buttons, and the Organisation Roles section starting below

Organisation Details: the name, the wide logo, and the square icon, each replaceable in place.

*** ## Organisation Roles The **Organisation Roles** section lists every role with the permissions it grants. Three default roles ship with the organization: | Role | Intent | | --------- | ----------------------------------------------------------------------------------------------------------------------------- | | **Owner** | Full control of everything, including invites, settings, and billing | | **Admin** | Full control of data, workspaces, connectors, applications, and reports; write-level access to invites, settings, and billing | | **User** | No standing permissions; grant access per workspace or with a custom role | Permissions are grouped by area: **Data**, **Workspaces**, **Connectors**, **Applications**, **Organisation Invites**, **Organisation Settings**, **Organisation Billing**, and **Reports**. Each area is granted at one of four levels: | Level | What it allows | | --------- | ----------------------------------------------------------------------- | | **none** | No access to the area | | **read** | View only: no modification and no executing things | | **write** | Create, view, and update: upload and build, but not delete others' work | | **full** | Everything, including deletion |
The Organisation Roles section listing the three default roles — Admin, Owner, and User — each with its per-area permission levels shown as coloured pills, and a Create Role button

The three default roles and their per-area levels. Create Role defines a custom one.

Click **Create Role** to define a custom role when the defaults don't fit, for example a role that can manage data and connectors but never touch workspaces or billing. *** ## Workspace access Organization roles set a member's baseline. Access to a specific workspace is granted on the workspace itself: * **Share a workspace** from the workspaces list (or the Organization home) via its **Share** action. Add individual users or whole roles at **read**, **write**, or **full** access, exactly like sharing a report. * Sharing with someone who is not yet in the organization sends them an **invite** as part of the share (this requires invite permission). * A member who opens a workspace they have no access to sees a **request access** screen; the workspace owner approves or rejects the request.
The Share Customer Analytics dialog: an Add people or roles section with User and Role tabs, a Choose user dropdown, Read, Write, and Full access pills, and a People with access list showing the workspace owner

Sharing a workspace: add users or whole roles at Read, Write, or Full access. The owner is always listed.

This is how a member with the default **User** role (no standing permissions) gets to work: share the workspaces they need with them, at the level they need. *** ## Team Members The **Team Members** section lists everyone in the organization with their role. Click **Invite User** to send an invitation and assign the new member's role. **Domain-based joining** lets users with matching email domains join your organization without an individual invite. It is disabled by default, and outside edit mode it shows only an Enabled or Disabled badge. To change it, click **Edit Details** in the Organisation Details section to put the page into edit mode (the action appears only for members with write access), scroll to **Domain-based joining** below the member list, switch **Enable Domain-based Joining** on, add the authorised domains and pick a **Default Role for Domain Joiners**, then save from the Organisation Details section.
The Team Members section listing one member with the Owner role and an Invite User button, above the Domain-based joining toggle (disabled) and the top of the Danger Zone

Team Members with the Invite User action, and Domain-based joining below it.

*** ## Danger Zone **Delete Organisation** permanently deletes the organization and everything in it: all workspaces, datasets, reports, roles, and invitations. This cannot be undone. The Danger Zone is visible only to members holding the **Owner** role in a multi-tenant deployment, and the default or system organisation cannot be deleted at all.