> For the complete documentation index, see [llms.txt](https://docs.revenium.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.revenium.io/account-and-resources/manage-users-and-teams.md).
# Manage Users & Teams
Behind every productive use of Revenium is a clean map of who's allowed to see what. Users are the individuals in your organization who log in and use the product - engineers instrumenting agents, finance teams auditing spend, product leaders tracking ROI. Teams are the internal structure those users belong to - business units, departments, product groups - that let you separate analytics and usage by group rather than flattening everything into one undifferentiated tenant view.
This is where you manage both. Access this area from the user avatar in the bottom-left corner of Revenium, then choose **Users & Teams** from the menu. Two tabs: **User** for individual accounts, **Teams** for the organizational structure they live within.
Worth a quick distinction before getting into detail: Teams here are your *internal* business units. They're different from Organizations, which represent your *customers* and live under [Manage Customers & Credentials](/monetize-your-ai/manage-customers-and-credentials.md). A Team is for your own team at Revenium; an Organization is for the company that pays you.
### :user: Users
The Users tab lists every person with access to your Revenium account. Each user has:
* **Email Address** - the login and unique identifier
* **First Name** and **Last Name** - for display in dashboards and audit trails
* **Teams** - one or more teams the user belongs to, displayed as badges. Users can belong to multiple teams, which is how you handle people who work across business units
* **Assigned Roles** - the permission scopes that govern what the user can do (see below)
* **Actions** - edit user details or delete the user
Adding a new user uses the **Add User** dialog. First Name, Last Name, Email, Teams, and Roles are all required. Once saved, the user receives a magic link invitation at the email address provided - no password is set on creation; the user claims their account by following the link.
#### Roles
Revenium uses a small set of named roles to control what users can do. These include **Tenant Administrator**, **Team Administrator**, and **Read Only**. A single user can hold more than one role; the Assigned Roles column in the Users list shows each applicable role, and role badges also appear against members in the Teams view.
The specific permission boundaries of each role are documented in Revenium's role reference. As a rough conceptual guide, tenant-scoped roles tend to grant cross-team access to settings and data, while team-scoped roles tend to be bounded to the team or teams the user belongs to. When configuring roles for a new user, choose the least privilege that covers their job.
**Understand workspace roles**
A user is treated as read-only only when the **Read Only** role is present without a write-capable role. If the same user also holds a write-capable role, that role supplies their write access.
**Read-only access**
The **Read Only** role grants view-only access: a user with this role can see the data and settings their scope allows but cannot create, modify, or delete resources. It is the right fit for stakeholders who need visibility—such as auditors, finance reviewers, or leadership tracking spend—without write capability.
For a user identified as read-only, write actions — create, edit, delete — appear disabled, with a note explaining the account is read-only.
In Guardrails, for example, a read-only user can view every rule and its history but can't create, toggle, or delete one.
Other product areas may expose different read and write actions. Use the disabled-action guidance shown in the product rather than assuming that the Guardrails boundary defines every page. User roles and API key permissions are separate access controls; see [API Key Permissions](/integrations/api-key-permissions.md) for the API key access model.
**Assign or change a role**
Choose **Read Only** when a user needs visibility without write access. Choose a write-capable administrator role when the user must manage resources within its scope. If you assign Read Only together with a write-capable role, the user is not treated as read-only.
#### The Can View Prompt Data Permission
One permission sits separately from the standard role model: **Can View Prompt Data**. This toggle, configurable per user, controls whether the user can see captured AI prompts, messages, and responses in the transaction log and trace views.
This is deliberately a standalone permission because prompt data is sensitive in a way that other AI cost data isn't. A user who can legitimately see cost and usage totals for a customer may not have any business seeing the actual text content of that customer's prompts. The default is off; Tenant Administrators have implicit access regardless of the setting, and only Tenant Administrators can modify it for other users.
Worth configuring thoughtfully from the start. Teams with compliance requirements around PII, confidential business data, or regulated industries generally want prompt access limited to a small set of named reviewers rather than everyone with a Revenium login.
### :users: Teams
The Teams tab lists your internal organizational structure. Each team has:
* **Name** - the display label
* **Parent** - optional, for building a hierarchy. Teams can be nested, so a parent team contains sub-teams. The Teams list renders the hierarchy as an expandable tree - click the chevron to expand a parent and see its children.
Teams are lightweight to create but carry a lot of optional configuration. Teams can be created without a tier upgrade or plan prerequisite, so you can structure your teams as soon as you need them. The **Add Team** dialog's header calls them "Team, Organization, or Business Unit" - reflecting that a Team can represent anything from a small engineering group to an entire business division.
#### Configuring a Team
The required fields are minimal - just **Name**. Everything else is optional and grouped into expandable sections:
* **Currency** - the default currency for this team's billing and analytics. USD is the default; pick a different currency if the team operates in a non-dollar market.
* **Advanced Settings** - team-level behaviors including auto-discovery settings for data sources and metering elements (Revenium recommends leaving these on in most cases).
* **Billing Address** - postal address and contact details used on invoices issued to or from this team, along with remittance instructions.
* **Metadata** - arbitrary key-value pairs for your own tagging or integration needs.
* **AI Settings** - team-level AI behaviors including whether prompt capture is enabled. Prompt capture is the feature that makes the Can View Prompt Data permission meaningful - without it on at the team level, there's no captured prompt data for users to see or not see.
You can also upload a team logo that appears in the Revenium interface when that team is active.
#### Why Teams Matter
Teams aren't just an org-chart convenience - they're the scope boundary for a lot of Revenium's behavior. API keys are scoped to a team. Analytics can be filtered and rolled up by team. Invoices and billing settings apply at the team level. When you pick a team from the selector in the top-left of the product, you're choosing which team's data you're currently looking at.
For most organizations, the right pattern is one top-level team representing the company, with sub-teams for departments or business units that need their own cost attribution. Users who work across sub-teams can belong to multiple teams simultaneously.
### Tenants
Tenants are the top-level object that contains your teams. The hierarchy is Tenants -> Teams -> Users.
### :code: Via API
The [Users endpoints](https://revenium.readme.io/reference/get_user) and [Teams endpoints](https://revenium.readme.io/reference/get_team) both have full CRUD - creating and listing users, updating their roles and team memberships, creating and configuring teams, nesting them into hierarchies via `parentId`. Useful when provisioning users programmatically (from an identity provider, for instance) or when setting up a multi-team structure as part of a deployment script rather than clicking through the UI. The [Tenants endpoint](https://revenium.readme.io/reference/get_tenant) returns information about your tenant.
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.revenium.io/account-and-resources/manage-users-and-teams.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.