Members and roles

Manage who can use Adverity Atlas, which workspaces they reach, and how automated systems authenticate. In the product these are three cards under Settings > People & Access: Members, Workspace Access, and Service Accounts.

Prerequisites

Admin role at the tenant level. Members can see their own access but cannot change anyone else’s.

Roles

Five workspace roles, on a single ladder. Each inherits everything the one before it can do:

1. Viewer: Read and browse

2. Analyst: Ask and propose

3. Editor: Create and configure

4. Knowledge Manager: Approve

5. Admin: Administer

What each rung adds:

Role	What it adds
Viewer	Read and browse. Sees conversations, artifacts, glossary terms, knowledge, data sources, and field profiles, and can file a support ticket. Changes nothing
Analyst	Use Adverity Atlas without authoring it: start conversations and run queries, upload files, propose glossary terms for approval, and raise or withdraw approval requests
Editor	Author: connect, edit and sync data sources, write glossary concepts and knowledge directly, create and run automations, create, share and delete artifacts, fit a marketing mix model, and configure workspace storage
Knowledge Manager	Approve: vote on approval requests, manage the organization-wide glossary and knowledge, approve classifications, and promote concepts to the organization tier
Admin	Administer: manage members and workspace access, bind and delete data sources, delete automations, files and concepts, change tenant settings, register MCP servers, set row-access rules, and see cost and audit views

Analyst is the role for people who use Adverity Atlas but do not build in it. It is the lowest role that can hold a conversation, so give it to anyone who should be able to ask questions without also being able to author artifacts and automations.

Knowledge Manager is the approver rung. When an Analyst proposes a glossary term, it waits in Approvals for a Knowledge Manager (or an Admin, who outranks one) to review.

Roles are assigned per workspace, not globally. Someone can be an Admin in one workspace and a Viewer in another. Because the ladder is strictly cumulative, a role that ranks above the one an action asks for can always perform it.

Members

Settings > Members opens Team Members, which lists everyone in the tenant plus any outstanding invitations. Columns are Member, Role, Status, and Joined. Search by name or email, and filter by status or Owners Only.

1. Invite a member, click Invite Member. Enter their email address, then either tick Organization Owner, or set the Role and the Default Workspace they should land in. Role offers all five roles and is described as the “Default workspace role for this member”. The workspace is optional, the panel offers None (assign later). Click Send Invite and they receive an email invitation.

2. Edit a member, open their row for Edit Team Member. Here you set Organization Owner and Status, either Active or Inactive, then Save Changes. An inactive member cannot access the organization. Per-workspace roles are changed under Workspace Access, below.

3. Remove a member, revokes access across every workspace. Their conversations and artifacts remain; authorship is preserved.

An invitation that has not been accepted shows as Pending with an Invited date. Use Resend if the email did not arrive, or Revoke before it is accepted.

Note

Organization Owner is separate from the workspace roles above. Owners have full administrative access to the organization, so the role and default-workspace fields do not apply to them.

Workspace access

Settings > Workspace Access is the same information from the other direction: rather than one member and their workspaces, it shows one workspace and everyone who can reach it. Use it when onboarding a team onto a new workspace, or when auditing who can see a particular set of data.

The table lists Member, Workspace, Role, Inherited Access, Granted By, and Granted At. Filter it by workspace or member.

1. Grant access, click Grant Access, then pick the Team Member, the Workspace, and the Role they get there. All five roles are selectable here. The Team Member picker lists active members and matches what you type against their name or email.

2. Change a role, use the Role select on the row. The change saves as soon as you pick a new value.

3. Check what someone really has, open the row actions and click Effective access. The panel shows both Direct grants and Inherited ones, so a role that comes down the workspace tree is visible next to one granted on the workspace itself.

4. Revoke, in the same row actions, removes that member’s access to that workspace after a confirmation.

Note

Workspace access controls which workspaces a person can open. It does not override the row-level security your warehouse already enforces. Adverity Atlas queries with the credentials configured on the data source and inherits whatever restrictions those carry.

Service accounts

Settings > Service Accounts manages API keys for programmatic access, scripts, CI jobs, and anything calling the API without a human signed in.

The table lists Name, Auth Method, which reads API Key, Status, Last Used, and Created.

1. Create one, click Create Service Account and fill in:

   Field	Description
   Name	Unique identifier for API access. Lowercase letters, digits, dots, dashes, and underscores, e.g. my-service-account	Required
   Display Name	How it reads in the list	Required
   Description	What this service account is used for	Optional
   Permissions	Tick the individual permissions it should have	Optional

2. Generate a key, use New Key in the panel, or Generate new key from the row actions. The key is shown once, under “Save this key, it will not be shown again”, so store it before closing.

3. Revoke a key, click Revoke next to it. Revoking cannot be undone, and anything still using that key stops authenticating immediately.

Activity is attributed per service account in the audit log, where Service Account is one of the actor types you can filter on, so automated activity stays traceable.

Note

A service account is scoped by the Permissions you tick, not by a workspace role. Grant only the permissions the integration actually needs.

Not every account in this list was created by hand. Publishing a data app to a public link provisions one automatically, named after the artifact and marked as managed by Adverity Atlas, to run that link’s queries as. It holds no permissions and has no API key. Deactivating it cuts the link off from data, and it cannot be deleted while a link is still bound to it. See Sharing.

Tip

Give each integration its own service account rather than sharing one key. Revoking a compromised key then affects only that integration.

Permissions

Roles are cumulative, so the role named is the lowest one that can take the action.

Action	Required role
See your own access	Viewer
Invite or remove members	Admin
Change roles	Admin
Manage service accounts	Admin

What’s next?

• Single sign-on, authenticate through your own identity provider instead of passwords

• Workspaces, create the workspaces you are granting access to

• Audit logs, see who changed access, and when

Was this page helpful? Yes No