Settings and administration

Your organisation is made of members, each with one organisation role, and domains — the parts of the organisation that a team owns. Most of what you can do follows from those two.

• Organisation roles
• Members
• Domains
• Policy
• Environments
• Billing and budgets
• Notifications

Organisation roles

Role	In short
Viewer	Reads: notebooks, the catalog, dashboards, governance results. Runs nothing.
Member	Does the work: starts kernels and warehouses, runs notebooks and pipelines, profiles tables, creates database schemas.
Admin	Changes what other people can do or what the organisation spends: members' roles, domains, access, settings, classification decisions, maintenance that deletes data.
Owner	Everything an admin can, plus billing and the AI plan.

A domain role adds to an organisation role for that domain only; it never takes anything away.

Members

Members & Domains lists every member with their organisation role and the domains they belong to, and every domain with its owners. Admins change a member's role there.

Domains

A domain is a part of the organisation that a team owns: its own people, its own limits, its own catalogs — one per environment — and who may approve a deployment to production. Owning a domain does not require being an administrator of the organisation. Admins create domains.

Domain role	Can
Owner	Add and remove people, set the domain's policy, approve other domains' requests for its data products.
Editor	Work with the domain's data and publish its products. Owners and editors get the same access to the tables.
Viewer	Read the domain's tables, everywhere.

In a production catalog, owners and editors can read tables and change their structure, but not write rows — production data changes through pipelines.

A domain's page shows its people, its policy, and Data access: what each role can do in each of the domain's catalogs. Access follows the people on the page — adding someone, removing them or changing their role rewrites it straight away. A badge says whether what is enforced matches the page; if it is out of step, Resync access rewrites it from the people listed.

A domain can be deactivated: everything it owns still exists and can still be read, but it accepts no new work. It can be reactivated.

Policy

The organisation policy is a floor every domain sits on. A domain can tighten any part of it for itself and cannot loosen one. Where the two disagree, the stricter applies. A policy can set:

• the shortest interval a pipeline's schedule may ask for;
• which runtime versions pipelines may name;
• how many other pipelines one pipeline may trigger;
• the most CPU, memory and running time a pipeline run may use;
• whether deploying to a production environment needs a second person.

Admins set the organisation policy; a domain's owners set the domain's.

Environments

Environments are the stages work moves through, such as dev and prod. A domain and an environment together name a catalog: sales in dev is sales_dev. Admins manage them under Settings → Environments:

• a short identifier (lowercase letters and digits) and a display name;
• whether it is production;
• whether it is where promotion starts (initial, like dev) or ends (terminal, like prod);
• Sandbox required: every pipeline promoted into it must pass a sandbox run first, on every path. It cannot be switched on while a promotion into the environment is waiting without one.

Deactivating an environment stops its catalogs being granted to anyone. The paths pipelines are promoted along are set on the Promotion paths page — see Promoting between environments.

Billing and budgets

Billing, for owners, shows the plan, its status and renewal date, and invoices once a billing period closes.

A monthly spend budget covers kernels, compute jobs, SQL warehouses, the AI assistant and the organisation's own database clusters; shared database clusters are not charged to anyone. The billing page lists this month's spend by each of those. As the total crosses each alert threshold, owners, admins and the groups that follow budget warnings are notified. A budget warns; it never stops anything — nothing running is stopped or throttled. Hard limits are set elsewhere: on each warehouse's maximum workers, and on the AI plan's spend cap.

Usage, linked from the billing page, breaks any of the last twelve months down by domain and by person or service identity. A kernel's cost goes to its owner, a compute job's to the identity it ran as, and a SQL warehouse's is split between the queries that ran on it in proportion to the processor time each used. Warehouse time no query used is shown as idle warehouse capacity, on its own line rather than spread over the people who did run queries; the most recent hour or two is shown as not yet split until every query in it has reported.

Notifications

The bell opens your inbox: pipeline runs, policy events, promotion requests, budget warnings and more, filterable by category, each linking to what it is about.

Under Settings → Notifications you choose how they reach you: in the app, by email, or muted altogether, and which events you want, one by one.

Notification groups, which admins manage, send events to a set of people together — for example, everyone who should hear when a quality rule fails or a budget threshold is crossed. Each group lists its members and the events assigned to it.