Permissions Management in awork
Control who can view and edit what. Learn here how to manage permissions efficiently.
Key benefits and use cases
- Simple role management: Understand who has access to what.
- Clear structure: General and project roles define specific access rights.
- Flexibility: Customize permissions to fit your team's needs.
Permissions management in awork is based on two levels:
- General permission roles (workspace level): Applies to your entire awork workspace.
- Project roles (project level): Applies only to specific projects where a user is a member.
Accessing permissions management
- Navigate to Settings (gear icon in the bottom left of the main menu).
- Click on Permissions Management.
Only users with the Admin role can configure these settings.
General permission roles
- Each person in the workspace has a general permission role (e.g., Admin or User)
- Important: If a user is not a project member, only the rights of the general role apply.
Creating a general role
- In the General Permission Roles section, click on + Role.
- Give it a name and choose either a blank role or a template.
- Customize the individual permissions.
Pre-configured roles
- Admin: Full access and can manage workspace settings.
- User: Can work with projects but cannot change central settings.
Set menu visibility per role
In the details of a permission role, you'll find the Menu Visibility tab, where you can specify which areas of the menu are visible.
Important: If the eye icon is disabled, the role lacks the necessary permissions.
Assigning general roles
At the bottom of the Permissions Management page, you'll find a list of all users where you can assign a role to each person.
Note: You cannot remove yourself from the Admin role.
Managing project roles
Project roles define specific rights at the project level.
Important: Project roles can extend permissions, but cannot restrict them. Restrictions are always controlled through the general role.
Creating a project role
- In the Project-Specific Permission Roles section, click on + Role
- Give it a name and set the view and edit rights.
Optional: Mark the role as Default Role so it's pre-selected when adding members to projects.
Editing or deleting a role
In the role overview, you can edit or delete roles using the action button.
Important: System roles like Admin and Guest cannot be edited or deleted. When deleting a role that's already assigned to users, you must select a replacement role.
Permissions in detail
Create project | Active Users can create projects.
Users cannot create projects.
|
Project details | Manage
Read
None
|
Project tasks | Manage
Read
None
|
Project times | Manage
Read
None
|
Users
New users can only be created by Admins.
User details | Manage
Read
None
|
User times | Manage
Read
None
|
Customers
Customer details | Manage
Read
None
|
Settings
Project settings |
|
Task settings |
|
General settings |
Note: The workspace can only be deleted by Admins. |
Tips & hints
Please note:
-
Project roles only extend permissions, they cannot remove rights.
-
You cannot remove yourself from the Admin role.
-
Project creators always retain full rights on their projects.
Tip: Access to only specific projects
If users should have access to only selected projects, we recommend this approach:
-
In the general role, keep cross-project rights (e.g., view of all projects/project tasks/project times) restrictive.
-
Then specifically add the person as a project member and give them the needed rights in that specific project via the project role.
FAQ
Is it possible for users to only see their own projects and tasks?
Yes. You can configure a general role so that users only see projects they're a member of.
Is there a setting so users fundamentally cannot track time?
Yes. Admins can disable time tracking for the entire workspace under Settings > Workspace. This is available starting with the Professional Plan.
Who can delete projects?
Users who are allowed to manage project details (in the general role and/or via project role) can delete projects. Additionally, each user can delete projects they created themselves at any time.
Do the permissions also apply in the API?
Yes, the permissions configured in permissions management also apply to access via the awork API.
