Table of contents
Security and Permissions in Project Web App
Permissions are what allow users to perform a specific function or action with Project Online. The security configuration uses Allow and Deny or no selection to configure each and every permission in Project Online. It is these security settings in the project management tool that ensures team members, project managers, and the entire project team are able to perform their requires tasks in the tool.
For example, the View Project Center permission may be allowed or denied for a given user or group in the system.
To provide more detail, there are two types of permissions in Project Online
- Global Permissions: These are permissions that are granted or denied that provide the ability to perform actions throughout the entire Project Online system, agnostic to a resource or project.
- Category Permissions: There are permission that are granted or denied that provide the ability to perform actions on specify resources and/or projects. Category permission are assigned at the category level. More in this later.
To make Project Online security more complex, permission may actually be set in a number of different places with the cloud based Project Web App system. Permissions are allowed or denied by selecting the checkbox in the Allow/Deny columns. There are MANY permissions to consider and set. If neither box is selected, the default state is Not Allow. The Not Allow selection does not prevent a user or users from accessing a specific feature of they are granted the permission in some other way.
For example, the user may belong to two security groups ( Project Managers and Resource Managers). Although the permissions in the Resource Managers group will have Not Selected for opening and editing projects, the Project Managers group will have it set to Allow. It is always best to leave a permission at No Allow (no checkbox selected) than to select Deny. In the scenario just noted, of the Resource Managers group had the Open and Edit project permission set to Deny, the user that was a member of both groups would ultimately not be able to manage projects as a Project Manage because the Resource Managers group specifically Denies that ability!
Remember, it's the proper selection of Allow and Deny to the various permissions that allow project managers to perform proper project planning, update tasks, see data in Power BI reports, and connect via the Project Online Desktop client.
Permissions are configured by choosing Project Web App Settings from the Project Web App Settings menu.
Again, It is important to consider when you are configuring a permission to Deny that the Deny setting supersedes any Allow settings that apply to the user for that permission by means of other group memberships. Limit your use of the Deny setting to simplify permissions management for large groups of users.
For organizations that have a large number of users, assigning and administering permissions on an individual basis can be an overwhelming task. In these cases. Well Actually, in most every case it is best to use and assign permission at the group level. And only at the group level. This will make assigning and troubleshooting permissions much more direct. Imagine trying to troubleshoot a permission for a specific user in a Project Online environment where permissions have been assigned at both the user and group level!
Groups in Project Web App
Groups contain sets of users who have the same functionality needs. For example, project managers within your organization may need the same set of Project Online permissions, while executives or resource managers might have different needs.
Note: Group membership consists of users only. Groups cannot contain other groups.
Users can belong to multiple groups. The following default groups are available in each instance of Project Web App that is in Project Server permission mode. Each is assigned a set of predefined categories and permissions.
Administrators usually assign permissions by adding a user account to one of the built-in groups or by creating a new group and assigning specific permissions to that group.
Categories
Categories are collections of projects, resources, and views. Categories define the scope of the information accessible to a given user or group. Again, it is highly recommended to only assign categories and apply permission at the group level. This provides an easily maintained system
Resource Breakdown Structure
The Resource Breakdown Structure (RBS) is a hierarchical security structure typically based on the management reporting structure of your organization. The RBS can be an important element in your Project Web App security model when it is used to define the reporting relationships among users and projects in your organization. When you specify an RBS value for each Project Web App user, you can take advantage of the dynamic security options that can be defined for each security category.
The RBS structure is defined by adding values to the RBS custom lookup table that is built in to Project Web App. Once you define the structure, you can assign RBS values to individual users by setting the RBS property in the user's account settings page. Once the RBS is configured, Categories can use RBS codes to dynamically determine which projects and resources particular users can view or access.
