--- description: Partition your Studio assets into write boundaries and scope which members can edit what --- # Data domains **The problem:** in larger organizations, many people work in Actian AI Analyst Studio at the same time — the finance team, the sales team, the marketing team. Without guardrails, anyone with Studio access can edit *anything*: a sales analyst could accidentally change a finance model, or overwrite a metric another team relies on. **The solution:** Data domains. An Admin groups the Studio assets into named domains — say *Sales* and *Finance* — and then decides per member which domains they can edit. Everyone still sees and uses everything; they just can't change what isn't theirs. Data domains partition an environment's authorable Studio assets — models, metrics, glossary terms, and AI analysts — into named write boundaries. A member restricted to the *Sales* domain can still see and use every asset in the environment, but can only create and edit assets that belong to *Sales*. Two principles to keep in mind: - **Domains gate writes, not reads.** Every Studio member can still browse, search, preview, and query every asset in the environment, regardless of their domain grants. Domains only control who can *create, edit, move, and delete* assets. - **Nothing changes until you restrict someone.** Creating domains on its own has no effect on your members — everyone keeps full write access until an Admin explicitly restricts them from the [Members](members.md) page. --- ## The default domain Every environment has exactly one **default domain**, named *General* out of the box (you can rename it). All existing assets belong to it, and new assets land there unless another domain is chosen at creation time. As long as your environment has only the default domain, no domain-related UI is shown anywhere in Studio — no domain columns, chips, or pickers. The feature stays out of the way until you create a second domain. The default domain cannot be deleted. --- ## Managing domains Only Admins can create, rename, and delete Data domains. Studio members can see the list of domains but cannot manage them. ### Creating a domain 1. Go to **Settings > Data domains** in Actian AI Analyst Studio. 2. Click **Create domain**. 3. Enter a name (unique within the environment) and click **Create**. When you create your second domain, a one-time note reminds you that existing assets stay in the default domain and that members keep full write access until you restrict them. ### Renaming a domain Click **Rename** next to a domain, enter the new name, and save. Renaming a domain never affects which assets belong to it or who can write in it. ### Deleting a domain Click **Delete** next to a domain. If the domain still holds assets, you must choose a destination domain for them — the assets are moved there as part of the deletion. !!! warning Deleting a domain never widens anyone's access. A restricted member whose only granted domain is deleted can no longer edit anything, and the Members page flags them with a **Needs re-grant** badge until an Admin grants them another domain or lifts the restriction. --- ## Restricting a member to domains Domain restrictions are managed per member from **Settings > Members**. Once your environment has more than one domain, each member row shows a **Data domains** column: 1. Go to **Settings > Members**. 2. Open the **Data domains** dropdown on the member's row. 3. Either select **All domains** (unrestricted — the default for every member), or tick the specific domains the member may write in. 4. Save your changes. A few things to know: - **Admins are never restricted.** A member with the Admin role can always write in every domain. - **Restrictions can be set before first sign-in.** You can restrict a member who has been invited or provisioned by your identity provider but has never logged in yet. - **Restrictions apply everywhere writes happen** — the Studio UI, edits made through the Steward AI agent, and writes made via the Public API on the member's behalf are all enforced the same way. --- ## What a restricted member experiences A restricted member keeps full visibility of the environment. The differences only appear when they try to write: - **Asset lists** show a domain chip on each asset and can be filtered by domain. - **Assets outside their granted domains** render in a view-only state with a lock chip naming the domain (e.g. *View only — Finance*). Disabled actions explain the reason: *"You don't have write access to the Finance data domain."* - **Creating an asset** offers a domain picker. If the member has exactly one granted domain, it is preselected; assets they create always land in a domain they can write in. - **Asking Steward** to edit an asset in a foreign domain gets a polite in-chat refusal naming the domain — the asset is left unchanged. - **Environment export** still works, but **environment import** requires write access to all domains (Admins and API keys always qualify). --- ## Moving assets between domains An asset's detail page shows the domain it belongs to and a **Move to…** action. Moving an asset requires write access to *both* the source and the target domain; Admins can always move assets. --- ## Auditing Domain management and scoping are fully audited. Creating, renaming, or deleting a domain, changing a member's domain scope, and changing roles all write entries to the [audit log](../governance/audit-logs.md).