> For the complete documentation index, see [llms.txt](https://docs.datalogz.io/guides/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.datalogz.io/guides/organizational-setup/user-onboarding-guide/available-roles.md). # Available Roles Datalogz uses two kinds of roles. * **Account roles** apply across your whole account. They control who can manage users, connectors, settings, and shared catalogs. * **Team roles** apply within a single team. They control who can see a team's data and who can configure the team. A user can hold several account roles at once, either assigned directly or through a group. Their permissions add up. Team roles work the same way: if a user belongs to a team directly and through a group, they get the higher of the two roles. ### Account roles #### Everyday roles **Datalogz User** The standard role for everyone in the account. A Datalogz User can sign in and access basic features. Everything else comes from the teams they're assigned to. **BI Viewer** Read-only access to every team's data, plus account-wide BI360 definitions and analytics. BI Viewers cannot change team configuration. This role suits analysts and leaders who need to see everything without administering anything. #### Administration roles **Connector Admin** Adds, configures, and removes the account's connectors and their credentials. **Account Settings Admin** Manages account settings, single sign-on (SSO), and OAuth clients. **BI Admin** Day-to-day administration of the account. A BI Admin manages users and groups, creates and deletes teams, manages team rosters and ownership, has admin access to every team and its configuration, and manages connectors, account settings, and the monitor catalog. BI Admins can view BI360 definitions and workflow templates but cannot edit them. **System Admin** Every account permission. This includes everything a BI Admin can do, plus editing BI360 definitions and workflow templates. The only actions out of reach are the few reserved for Application Admins. #### BI360 roles **BI360 Viewer** Views account-wide BI360 definitions and analytics. **BI360 Admin** Creates and edits account-wide BI360 definitions. Includes everything a BI360 Viewer can do. #### Workflow roles **Workflow Viewer** Views the account's workflow templates. **Workflow Editor** Creates and edits workflow templates. Includes everything a Workflow Viewer can do. ### Team roles Every user in a team holds one of three roles. **Member** Sees the team's data: assets, monitors, and analytics for the team's connectors. **Admin** Everything a Member can do, plus team configuration: connectors, monitors, and who belongs to the team. **Owner** Everything an Admin can do, plus deleting the team and transferring ownership. Each team has exactly one owner, and the owner is always a user. Transferring ownership makes the previous owner an Admin. Groups can be added to a team as Members or Admins. A group cannot own a team. Some account roles include a seat in every team without needing a membership. BI Viewer gives Member access to every team. BI Admin and System Admin give Admin access to every team, and can also delete any team or transfer its ownership. ### Application Admin Application Admin is a user type, not an assignable role. Application Admins bypass every permission check, and a few actions are reserved for them. Keep this to a small number of people and use System Admin for full day-to-day access. ### Assigning roles Managing users requires the BI Admin or System Admin role. When assigning roles, you can only grant what you already hold: a role cannot be given to a user or group if it includes permissions the person assigning it does not have. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.datalogz.io/guides/organizational-setup/user-onboarding-guide/available-roles.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.