Roles and Permissions
User permissions in Space fall into the following categories:
Users cannot be issued individual permissions — instead a user can be assigned a Role which has a pre-defined set of permissions.
Space comes with a number of Default Roles (described in the table below). The System Admin role includes global (organization-wide) permissions and cannot be modified — i.e. you can't add or remove permissions from it. However, if you need a custom set of permissions, you can create an additional Role.
(Valid throughout the entire organization)
Granted to the users in charge of administering the Space installation and/or organization and personnel management (e.g HR). Includes all available rights in all areas except for Projects.
This default global Role cannot be edited. Instead, the system administrator can create a new Role with a custom set of permissions.
(Valid within a particular team)
Team Admin and Team Lead roles are granted on a per-team basis, hence the permissions they contain are only valid within a particular team.
Similarly, the Manager role only gives authority over the subordinate members.
System Admin can modify these Roles by adding or removing permissions.
Intended for the team lead authorized to approve absences of the team members. Includes the right to see the team members' reasons for absence (hidden to others). The Team Lead and Team Admin Roles are typically assigned to the same person.
Intended for a person who is explicitly assigned to another person as their supervisor. Includes the rights to view and approve absences of subordinates and to see their reasons for absence (hidden to others).
(Valid within a particular project)
Initially granted to the user that creates the project.
Intended for project participants that should be allowed to manage access and configure project modules as well as contribute to the project.
System Admin has no specific rights over projects created by other users.
System Admin can modify the default templates for these Roles or create a new template with a different variety of project access permissions. The role templates can be then used by Project Admins to create Roles for their projects and assign those Roles to their project participants.
Granted by the Project Admin to project participants that are expected to contribute to the project on regular basis. Project members form the Project Team and have access to internal project tools and resources.
Intended for project participants that occasionally contribute to the project but are not considered part of the team. Collaborators have the same default permissions as project members but are not included in the Project Team.
Granted by default to all organization users. Includes viewing rights for some project resources.
Granted to Automation scripts. Includes the rights to:
Issued by default to all users except guests.
This role defines the base level of permissions that are available to every member of the organization (except guests). Specific permissions that are not enabled for this role can be granted separately at the team or project level.
These Roles are permanently assigned to all users (except guests) - they cannot be revoked.
System Admin can modify the Member role by adding or removing some of the permissions.
The Self role cannot be modified.
This role defines which permissions are available to members for the purpose of editing their own records.
Issued by default to all users registered as Guests.
This role defines the lowest possible level of permissions.
Guests have limited visibility.
These Roles are permanently assigned to all users registered as Guests - they cannot be revoked or modified.
This role defines which permissions are available to guests for the purpose of editing their own records.