Why Should I Use User, Role and Access Management (Permissions) in Project Management Software?

Why Should I Use User, Role and Access Management (Permissions) in Project Management Software?

User, role, and access management are three different types of permissions commonly found within project management software. Permissions determine what information users can view and edit within the software.

Flexible and customizable permissions allow you to maintain the appropriate balance of collaboration and control while giving you peace of mind that your company's data is secure and protected. For example, if you're working on a highly sensitive project, you need the project team to collaborate, but you want to keep the information on a need-to-know basis. User, role, and access permissions allow you to achieve this balance.

User management allows you to manage permissions at the level of an individual user. For example, user management enables you to select exactly what Bob Smith can see and edit.

Role management allows you to manage permissions at the role level. When you make changes to a role’s access, it automatically impacts every user with that role. For instance, if you have a “reviewer” role, you can set permissions so the role can see everything but edit nothing. This setting would then apply to each person within the software who has been assigned a reviewer role.

Access management allows you to manage permissions tied to a specific folder or project. This allows you to assign users with different permission levels for different projects or folders. For instance, let’s say you have a folder for your design team and another for your testing team. You can give the members of each team full access to their own folder and read-only access to the other folder.

Managing permissions

Permission management is restricted to a few select users. The software account owner and system admins can manage permissions within the project management software. This includes creating, customizing, and deleting roles.

Regular users can be granted the right to “Set folder permissions” on a folder or project. With this right, users can then manage other users’ folder and project access without relying on an admin.

If you have more than one system administrator, you can choose to use controlled admin permissions to control at an itemized level what functions each admin can perform. This approach results in a more fail-safe and secure software deployment. Teams see the most benefit from this approach when the project or business has a host of system admins, including several second-tier admins who only need to manage users and groups.

Whenever a permission change takes place, it will immediately impact every user or user group that is assigned the modified role or access. This ensures that permission levels can easily be updated and maintained as projects progress and employees change roles.

The user management chart allows you to view all users associated with your software account, including users with pending invitations. From this chart, admins can easily modify user roles and access and license type, as well as invite new users. 

By default, the user management chart should show all users within the system, including collaborators, regardless of their license type or role. Within the chart, there will be a user list that contains the following information about each user:

• Name
• Profile picture
• Primary email address
• Role (regular user, external user, etc.)
• Status (active, invited, or invitation declined)

You can filter the list by role or status in order to view and manage only a specific segment of users such as:

• Administrators
• Regular users
• External users
• Collaborators

Inherited permissions

Subfolders and subprojects can inherit permission levels from parent folders and projects. When permission levels are inherited, users receive the same level of access to both the parent folder/project and their subfolders/subprojects.

When reviewing users' access, you may discover that some users or user groups have multiple access roles within a folder or project. Multiple access roles indicate that the following has occurred:

• Users have inherited different access roles from multiple parent folders, projects, or user groups.
• The access roles are customized in such a way that different permissions are associated with each role that was inherited from parent folders, projects, and user groups.

You can change a user’s access role so that their permission level on a subfolder or subproject is higher than the granted permission level associated with the parent folder or project. However, you cannot change a user’s access role on a subfolder or subproject so that it’s lower than the granted permission level associated with the parent folder or project. The one exception to this rule is if you choose to turn off inherited sharing. 

If you choose to turn off inherited sharing, permissions will be affected in the following ways:

• Users who have access to any folder or project at the time inherited sharing is turned off will keep their current access role.
• Users who are granted access to a folder or project after inherited sharing is turned off will be granted the default access role for their user type. 

User groups

User groups are customizable groups of selected users. For instance, you may group all of your software coders into one user group. Instead of sharing data with each person individually, user groups enable you to quickly share information and permissions with groups of people all at the same time.

For example, you have the ability to set and modify access roles for an entire user group instead of changing them for each user. Even when you choose to assign an access role to a group, you can still grant individual members a permission level that is higher than that of the rest of the group.

However, you cannot grant a member of the user group a permission level that is lower than the level assigned to the group. For instance, if a user group has “full access” to a project, you can’t downgrade one member to “limited access.”

When you share a task, folder, or project with a user group, the following rules apply:

• The task, folder, or project in your project management software is also shared with any subgroups that are a part of that user group.
• You cannot unshare the task, folder, or project from a subgroup within the parent user group or from just one individual or individuals within the user group.
• The task, folder, or project is automatically shared with users as they are added to the group.

Once user groups are created, admins can add and remove users from groups as well as edit groups, create subgroups, and move users between groups.

Access roles

There are typically four standard access roles to choose from:

• Full
• Editor
• Limited
• Read-only

Each of these access options has its own set of permissions associated with it. For instance, “editor access” will generally provide full admin rights except for the ability to modify permissions, add or change tags, and delete projects, folders, and tasks. “Limited access” is much more restricted, and may only allow the changing of tasks statuses and entering of comments and attachments.

When setting access roles on folders, keep the following in mind:

• You can’t change your own access role, even if other users have “full access” to the same folder or project.
• There must always be at least one person with the right to share a folder or project.
• You can’t adjust permissions for the “read-only” role.
• Permissions granted by an access role can’t exceed the rights granted by a license type. For example, collaborators can’t create tasks even if they are granted “full access” to a folder or project.