Configure roles and domains

Roles express what members may do; access domains identify where those permissions apply. Administrators and the Owner configure them when the plan includes fine-grained permissions. Check the access model before assigning a new configuration to members.

Create and configure a role

1. Open Organization settings > Rights > Configuration, then Roles > Manage. The Roles navigation entry also opens this list.
2. Click Create Role. Enter Name, check the generated Key, and add a description if useful.
3. Click Create, then open the role's row to edit its permissions.
4. Under Assets > Overview, locate the asset type and domain. Visible access domains only filters displayed columns.
5. Open a type/domain cell. Set General access, then inspect Properties, Relationships and Flow content for process types.
6. Use Type detail to compare one type across domains and adjust its detailed permissions.
7. Configure Folders and visualizations separately if needed.
8. Click Review and save, inspect before/after changes, then Save changes.
9. Assign the role in Users and check By user.

The row's editing menu changes the role's name, key and description; opening the role configures its permissions. Generated keys can be unlocked for editing in the form.

Review a new role before assigning it

A new role starts with maximum permissions on No access domain, including applicable properties, relationships, flow content and folders/visualizations, except calculated properties, which it does not see. It does not start empty everywhere and does not grant those permissions across every existing domain.

Set permission levels deliberately

General levels are None, View, Edit, Delete and Change access domain. Property, relationship and flow levels extend up to Edit. Calculated properties remain limited to View and start hidden from every role: open them only to roles that already see their sources (see calculated properties).

Lowering general access can also reduce property and flow permissions. Raising it again does not restore their previous settings. Review those details after changing the general level.

Relationship permissions are separate from asset editing, but remain unusable when the source asset is inaccessible. Configure incoming relationships from their source type using the provided link. A relationship property's permission cannot exceed its relationship's permission.

All properties and All outgoing relationships include entries outside the current search results. Metamodel-hidden properties are excluded from the bulk property command, but an automatic ceiling reduction can still affect them. Review the full change summary.

Clicking a level prepares a draft. It does not immediately save. Cmd/Ctrl + S opens the review, and from that review saves when possible. Cancel > Discard all abandons the draft; the review also supports discarding individual changes.

If another editor changed the same permissions, the conflict dialog reports that nothing was saved. Reload conflicting permissions discards your local changes only for conflicting cells. Recheck the draft before saving. Other save errors leave local changes available for retry.

Create and configure a domain

1. Open Access domains from Rights or organization navigation.
2. Click Create access domain and enter its name, key and optional description.
3. Click Create, then open its row.
4. Set the permissions for the relevant roles. Here, columns represent roles; Visible roles filters the display.
5. Use Review and save, then Save changes.
6. Check the result before assigning data or shared content to the domain.

A new domain starts without permissions. Assigning objects before configuring it can make them inaccessible to their intended users. This differs from a new role's permissions on No access domain.

Assign domains to an asset

1. Open the asset's editing form and find Access domains.
2. Select the intended domain list.
3. Review both added and removed domains, then validate.
4. Check the asset's visibility and the effective permissions of the intended users.

The interface requires Change access domain on at least one current domain before you can change the list. Adding a domain then requires at least Edit on every added domain. Removing one requires Change access domain on every removed domain. Removing the last domain also requires Edit on No access domain.

Being able to edit the asset does not automatically authorize every domain change. Since permissions combine, adding a domain can broaden the audience. Folder placement is not permanent inheritance of a visualization's domains; content access is configured separately.

Duplicate or remove configurations

Use the ordinary role or domain row menu to rename, duplicate or delete it. The system No role and No access domain entries cannot be deleted.

Deleting a role removes its permissions and assignments. Members without another explicit role then use No role; inspect that role before confirming removal.

Deleting a domain removes it from active and archived assets, visualizations and folders, including scenario copies, along with its associated permissions. The objects remain. Objects left without a domain now depend on No access domain, which may change their audience.

Read the confirmation, then recheck the affected users and objects. Removing a configuration is not equivalent to deleting the business data it governed.