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 [email protected] for guidance on configuring automatic team mapping with your SSO provider.
See Azure AD or Okta SAML 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:
Click Hi, <name> → Profile
Set up your 2FA method (authenticator app)
Save changes
Then enforce it organization-wide:
Click Hi, <name> → Manage <organization>
Go to Settings
Enable Require Two-Factor Authentication
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 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 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 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:
Click Hi, <name> → Manage <organization>
Go to Settings
Set Maximum API Token Lifetime (e.g., 90 days)
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 for token management details.
How do I transfer a project to a different owner?
Transfer between teams:
Open the project
Go to Settings → General
Select the new owner (team or organization) from the dropdown
Click Transfer ownership
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:
Go to Hi, <name> → Manage <organization>
Open Environment Variables tab
Edit the variable group
Select specific projects in the Projects field
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 for detailed configuration.
How do I disable an environment for everyone?
Disable organization-wide:
Go to Hi, <name> → Manage <organization>
Open Environments tab
Find the environment you want to disable
Uncheck Enabled
Save changes
Users can no longer select this environment when launching executions.
Disable for specific teams:
Set team quotas to zero:
Go to Environments tab
Click Manage team quotas
Set quota to 0 for the environment and team
Save changes
The team cannot use this environment, but other teams remain unaffected.
See Configure Environments and Team Quotas.
What's the difference between organization-level and project-level environment variables?
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 for detailed comparison.
Related Topics
User Management Overview — Complete guide to organizations, teams, and users
Azure AD SSO — Set up single sign-on
Team Quotas — Control resource usage per team
Audit Log — Track organizational activity
Last updated
Was this helpful?