Access Control in Y42

Y42 enables detailed control over data assets and operations using a hierarchical role-based access control system that is integrated throughout the platform.


To understand access control in Y42, this general summary of relevant concepts may be helpful:

  • Subject: typically a user, sometimes also an API token that is used to access Y42 programmatically. Users can be grouped into teams as well, and a team can be managed like a single subject.
  • Resource: can be any object inside Y42, like an integration, a table, a job, but also containers like the whole of the integrations module or even a space or an organization.
  • Resource Hierarchy: Resources can be "parents" of other resources.
    • An organization is the parent of all spaces inside that organization
    • The integrations module is the parent of each specific integration, etc.
    • An integration or model is the parent of each table and job connected to it
  • Role: roles are held by subjects, relative to resources. For example, the user "John Doe" can hold the "owner" role relative to the "ACME" organization.

A user/subject will have different permissions on a resource depending on their assigned (or inherited) role.

Roles in detail

The following provides a simplified overview of the different roles that exist on each resource type inside Y42, and which permissions are effectively entailed by that role.

RoleApplicable toPermissionsInheritance
AdministratorOrganizationAll permissionsAlways
Billing AdministratorOrganizationRead/change organization billing info onlyNever (N/A)
OwnerNearly all resourcesread, edit, delete*, create child resources, read subjects**Always
ManagerTeam, API KeySame as ownerNever (N/A)
EditorNearly all resourcesread, edit, create child resources, read subjectsAlways
ViewerNearly all resourcesread, read subjectsAlways
MemberOrganization, Space, Team, all modulesdiscover the resource (without reading data), read subjectsPartial - Organization members are not automatically space members - explicit grant required. Inherits down from space to all modules
GuestOrganization, Spacediscover the resource (without reading data)Partial - Organization guests are not automatically space guests - explicit grant required. Space guests are implicitly members of all modules in the space

*only administrators can delete an organization - for other resource types, owners can delete as well.

**reading subjects is only possible at two levels: organization and space. In practice, every subject can discover other subjects, except when the subject is a guest in the organization and also a guest in the space.

Discovering resources vs. reading data

The difference between "read" and "discover resource" stems from the way Y42 runs git under the hood. For technical reasons, as soon as a subject is able to access a space in any way (i.e. guest role or higher), they need to be able to do a git checkout of that space. This will let them discover all models, integrations, dashboards and other resources in the space, but, importantly, it does not necessarily let them read the underlying data from tables in the data warehouse. Nevertheless, this may have important governance, security and privacy implications that are important for an organization to be aware of.

To let downstream users and tools consume data managed by Y42 without exposing read access to the information managed in git, Y42 provides 2 main mechanisms: data exports, and the publish layer.

Granting roles

A subject can generally grant other users equivalent access to their own role, but not higher. For example, only administrators can grant or revoke the administrator role to others, an editor can only grant or revoke the editor role to others.

Viewers, members and guests cannot make grants.

Role inheritance and resource hierarchy

When a resource is the parent of another resource, the role on the parent resource will generally be inherited down to the children, as outlined in the table above.

The diagram below visualizes the structure of the resource hierarchy in Y42.

Resource hierarchy. 

Legend: Green → subjects, blue → organization & space, purple → modules, yellow → data assets, grey → jobs & runsResource hierarchy. 

Legend: Green → subjects, blue → organization & space, purple → modules, yellow → data assets, grey → jobs & runs

Resource hierarchy.

Legend: Green → subjects, blue → organization & space, purple → modules, yellow → data assets, grey → jobs & runs

A role with elevated permissions at a higher level in this hierarchy will always override a role with fewer permissions lower in the hierarchy. So if, for example, a user is a an owner at the organization level, that user can read, edit and delete all resources in all spaces of that organization, even if they are manually assigned the viewer role in some space (the organization-level role will override the space-level role).

Recommended approach to role management

In practice, if you wish to grant access on an as-needed basis, we believe the following is a sensible approach in most cases:

  • Grant all internal users of the organization the "member" role on the organization by default
  • Grant specific users a higher level of access either at the space-level or module-level according to the access they require, within only the spaces they require access to
  • To simplify the above, you may want to group users into functional teams (e,g. "data engineers", "data analysts") and make appropriate grants to those teams - onboarding a new user is then simply a matter of adding them to the right team

Inviting external guests

If you want to invite external read-only guests to view e.g. one or more specific tables or dashboards, you should make them a guest at the space and/or module level and assign them the viewer role specifically on the resources you wish for them to see.

Note that they will still be able to check out the git repository of the space and see all configuration therein! If you need to avoid this, consider using an export and grant them access to the data they need at the level of Y42's Publish layer via an API key, or at the data warehouse level.