# FAQ

Quick answers to common questions about managing users, teams, and organization settings in Valohai.

## Can we automatically map users to teams based on our SSO?

**Yes.** When configuring your Okta or Azure AD application, you can send additional user attributes — like team affiliation — to Valohai. Valohai then automatically assigns users to teams based on these attributes.

This eliminates manual team management for organizations with SSO. Users join the correct teams automatically when they log in.

**Setup:** Contact <support@valohai.com> for guidance on configuring automatic team mapping with your SSO provider.

See [Azure AD](/user-and-organization-management/single-sign-on/azure-ad.md) or [Okta SAML](/user-and-organization-management/single-sign-on/okta-saml.md) documentation for initial SSO setup.

## Can our organization require two-factor authentication (2FA)?

**Yes.** Organization administrators can mandate that all users enable two-factor authentication.

Before enforcing organization-wide 2FA, enable it for your own account:

1. Click **Hi, \<name>** → **Profile**
2. Go to <https://app.valohai.com/auth/>
3. Set up your 2FA method (authenticator app)
4. Save changes

Then enforce it organization-wide:

1. Click **Hi, \<name>** → **Manage \<organization>**
2. Go to **Settings**
3. Enable **Require Two-Factor Authentication**
4. Save changes

Users will be prompted to configure 2FA on their next login.

## Can I restrict user access to a project, machine type, or data store?

**Yes.** Valohai uses a three-tier access control model: Organizations, Teams, and Users.

### Projects

**Ownership:** Projects can be owned by a user, team, or organization.

**Collaborators:** Add individual users as collaborators in project settings, even if they're not part of your organization or team.

**Transfer ownership:** Move projects between teams or organizations in project settings.

**Example:** The "data-science" team owns the "customer-churn" project. Individual engineers can be added as collaborators for specific experiments.

See [Create Teams](/user-and-organization-management/getting-started/create-teams.md) for team setup.

### Environments (Machine Types)

**Ownership:** Environments are typically owned by organizations.

**Team quotas:** Control which teams can use specific environments and set maximum concurrent machines.

**Example:** The "staging" team can use up to 5 CPU machines and 2 GPU machines, while the "production" team has access to 10 machines of any type.

See [Team Quotas](/user-and-organization-management/environments-and-access-control/team-quotas.md) for configuration.

### Data Stores

**Scope:** Data stores can be defined at the project or organization level.

**Organization-level:** Share with everyone in the organization or restrict to specific teams.

**Project-level:** Limit access to a single project.

**Example:** The production S3 bucket is shared only with the "production" team, while the staging bucket is accessible to all teams.

See [Restrict Data Stores](/user-and-organization-management/environments-and-access-control/restrict-data-stores.md) for setup.

## How long is the API token valid for?

**Default:** API tokens generated by users do not expire by default.

**Organization policy:** Administrators can set a "Maximum API Token Lifetime" to enforce automatic expiration:

1. Click **Hi, \<name>** → **Manage \<organization>**
2. Go to **Settings**
3. Set **Maximum API Token Lifetime** (e.g., 90 days)
4. Save changes

Once set, all tokens expire after the specified duration. Users must generate new tokens periodically.

**Security recommendation:** Set token expiration for organizations handling sensitive data or subject to compliance requirements.

See [REST API Authentication](/automation-overview/rest-api.md) for token management details.

## How do I transfer a project to a different owner?

**Transfer between teams:**

1. Open the project
2. Go to **Settings** → **General**
3. Select the new owner (team or organization) from the dropdown
4. Click **Transfer ownership**
5. Confirm the transfer

The new owner immediately gains full control. The previous owner loses admin access unless they're part of the new owning team.

**Transfer to a user:**

Projects can be transferred to individual users the same way. Useful when someone leaves a team but should retain project access.

## Can users belong to multiple organizations?

**Yes.** Users can be members of multiple organizations simultaneously. This enables:

* Consulting workflows across multiple clients
* Separating personal and work projects
* Accessing shared resources from different companies

**Switch organizations:** Use the organization dropdown in the top-right corner to switch context.

Each organization has independent:

* Projects and executions
* Compute environments
* Data stores
* Billing

## What happens when I remove a user from the organization?

The removed user immediately loses access to:

* All organization-owned projects
* Team-owned projects
* Organization environments and data stores
* Shared credentials and environment variables

**Projects they own personally:** Remain accessible if your organization allows personal projects.

**Collaborator access:** Projects where they're an individual collaborator remain accessible until removed by the project owner.

**Data created by the user:** Remains in the organization (executions, models, datasets).

## Can I limit which projects can access an environment variable group?

**Yes.** When creating or editing an environment variable group:

1. Go to **Hi, \<name>** → **Manage \<organization>**
2. Open **Environment Variables** tab
3. Edit the variable group
4. Select specific projects in the **Projects** field
5. Save changes

Only selected projects can access the variables in this group.

**Use case:** Separate production credentials from staging credentials by granting access to different project sets.

See [Environment Variables & Secrets](/user-and-organization-management/getting-started/environment-variables.md) for detailed configuration.

## How do I disable an environment for everyone?

**Disable organization-wide:**

1. Go to **Hi, \<name>** → **Manage \<organization>**
2. Open **Environments** tab
3. Find the environment you want to disable
4. Uncheck **Enabled**
5. Save changes

Users can no longer select this environment when launching executions.

**Disable for specific teams:**

Set team quotas to zero:

1. Go to **Environments** tab
2. Click **Manage team quotas**
3. Set quota to 0 for the environment and team
4. Save changes

The team cannot use this environment, but other teams remain unaffected.

See [Configure Environments](/user-and-organization-management/environments-and-access-control/configure-environments.md) and [Team Quotas](/user-and-organization-management/environments-and-access-control/team-quotas.md).

## What's the difference between organization-level and project-level environment variables?

| Feature        | Organization-Level                        | Project-Level             |
| -------------- | ----------------------------------------- | ------------------------- |
| **Scope**      | Multiple projects                         | Single project            |
| **Management** | Admins only                               | Project owners            |
| **Use case**   | Shared credentials, infrastructure config | Project-specific settings |
| **Rotation**   | Update once for all projects              | Update per project        |

**Best practice:** Use organization-level variables for credentials shared across projects (database passwords, API keys). Use project-level variables for project-specific configuration (model hyperparameters, feature flags).

See [Environment Variables & Secrets](/user-and-organization-management/getting-started/environment-variables.md) for detailed comparison.

## Related Topics

* [User Management Overview](/user-and-organization-management.md) — Complete guide to organizations, teams, and users
* [Azure AD SSO](/user-and-organization-management/single-sign-on/azure-ad.md) — Set up single sign-on
* [Team Quotas](/user-and-organization-management/environments-and-access-control/team-quotas.md) — Control resource usage per team
* [Audit Log](/observability/audit-log.md) — Track organizational activity


---

# Agent Instructions: 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:

```
GET https://docs.valohai.com/user-and-organization-management/getting-started/faq.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.