Skip to main content

General workspace administration

As a workspace Admin you can add users, change user roles, allow other domains to have access to your projects, and create shared assets in your workspace settings.

Users & Groups

All roles (except Guests) can view their workspace's users and groups in their workspace settings panel. Only Admins can create and edit user roles.

Workspace Roles

A user can have one of several roles in a workspace. Workspace roles specify what a user can access and what project permissions they can be granted.

  • Admins - Admins can access all projects shared with the workspace, as well as create and duplicate projects. Admins also have access to workspace settings where they can manage users and assets, and view certain private project details, such as title and workspace assets utilization.

  • Editors - Editors can access all projects shared with the workspace, as well as create and duplicate projects.

  • Viewers - Viewers can access all projects shared with the workspace, but only with up to "Can View" permissions. Viewers cannot create or duplicate projects.

  • Guests - Guests are users who can only access content that has been explicitly shared with them. Guests can be granted up to "Full Access" project permissions.

    Guest users can do everything a regular workspace user can do, with a few notable exceptions:

    • Projects, components, and shared assets that are shared with the entire workspace will not be shared with Guests. If a Guest needs to have content or assets shared with them, they will need to be explicitly granted access.
    • Guests will not be able to view the Users or Groups pages found in Settings.

Deactivate users

Admins can deactivate users from the Settings Users tab, under the "Access & Security" header. Click the three-dot menu to the right of the user's name and select Deactivate. This will prompt you to transfer ownership of the deactivated user's projects.



User groups are only available for workspaces on Teams and Enterprise plans.

Admins can define subsets of users as a group in the Settings Groups tab, under the "Access & Security" header. Add a group by clicking the + Group button, naming the group, and selecting users from the search bar at the bottom of the dialog. Individual users can appear in as many groups as desired.

Allowed domains

Admins can allow anyone with an email address belonging to a certain domain (e.g. to log into your workspace with the default role. By default, any user with an allowed domain will be able to log in, so there's no need to manually create a user account for each person in your workspace.

In most cases, you will want to set up the default role as "Viewer". Any Users who should not have the default role (e.g., Admins) need their roles set explicitly in the Users field.

Project organization

Hex includes two types of tags that can be used to organize and manage projects: Status and Category. By default, Hex includes 3 Categories and 5 Statuses, but Admins are free to edit the defaults and add their own. Any edits to a category or status will automatically be reflected on all projects it is used on.

Once assigned to projects, categories and statuses can be used to filter the Projects page.


Deleting a status or category will remove it from all projects it is currently assigned to, and cannot be undone. You can re-create the category with the same name, but it will have to be manually re-assigned to projects.

Default categories: External, Internal, Template

Default statuses: Approved, Archive, Exploratory, In Progress, Production

Environment settings

Workspace timezone

Admins can set a workspace timezone in the Settings General tab, under the "Workspace" header.

This timezone is the default target timezone used by chart cells and pivot cells when displaying timestamp values.

By default, this is set to 'UTC'. Typically, the value of an organization's head office should be chosen as the workspace timezone.

The workspace timezone setting can be overridden at the project-level, or per app session for published apps.

In increasing precedence, the target timezone used will be set by:

  • Workspace timezone: This is the default target that all new projects will use.

  • Project timezone: The workspace timezone can be overridden by the project timezone, set in the Environment panel of the sidebar.

  • App session timezone: When viewing a published app, the project and workspace timezone can be overridden for a specific app session in the top right hand corner of the app. Note: this only persists for the current app session — if you revisit the app in the future, the app will revert to the project timezone.

The target timezone is also represented in the hex_timezone built-in variable, which can be used to execute timezone-aware logic in both code and SQL cells.

Workspace SQL caching

Admins can adjust the default SQL caching policies for their workspace, with separate timeouts for developing logic and published apps. The default values defined here can be overriden at the project level. See our docs on SQL caching for more information.

Admins can disable this setting in order to prevent any user from using SQL caching in any of their projects.