Project Management Context
Organizations are not always able to have entirely open access to their portfolio of projects, but rather need to take a more granular approach to security and access, while others are fine with users having access to the entire portfolio of projects. BrightWork 365 provides options to accommodate both of these approaches through a flexible security and access model.
One of the available BrightWork 365 security models is the Portfolio Security (Top-Down) Model, which limits access to only those users given a BrightWork security role in a Portfolio's associated Owning Business Unit. This access (or lack thereof) propagates down through the Portfolio's hierarchy to the Project level. However, invariably user access exceptions will need to be made, for example to allow team members access to a child project even though they are not given any security role at the parent Portfolio level. In these instances, after you implement the Portfolio Security (Top-Down) Model, you can then proceed to use the Project Security Model detailed in this article to allow users access to individual projects to which they would otherwise not have access.
Project Security Steps - In a Nutshell
- Set Default Access Level in Project Template.
- Create Project - the Project Settings gets value from Project Template.
- Create Project Team Member (manually or by assigning them work) - the Project Team Member gets Access Level value from the Project Settings.
- As necessary, override the default Access Level to provide individual Team Members with a higher or lower Access Level.
- When projects are first created, their Owning Business Unit (OBU) will be inherited from their parent Portfolio (see Portfolio Security & Access).
- For Projects created from content templates, their OBU will be taken from the source project.
- Customers that wish their custom tables to be included in the Project move Program and Program move Portfolio flows will need to request assistance from their Customer Success Partner to update the child flows in their custom solution.
Customers are advised to use generic names for planned confidential projects as the project names will be visible to all users in various places in the app and in PowerBI / SharePoint (Approvals, Content Templates). Confidential projects should not contain confidential information in their project name.
Project Security - Details
Configure User Project Access
- In the project's Teams tab, click the name of the relevant user.
- Set the Access Level to None or Edit.
- Changing a user's Access Level to None only removes access for those users who are not the actual Project Manager of the project, or do not have any security roles in the business unit that is associated with the project.
- Users cannot access the parent Program and Portfolio in which the Project they were given access to is located, unless they also have access through standard business unit membership. See Portfolio Security & Access for more information.
- The default Access Level for a project is set in its associated Project Template.
- Only the actual Project Manager of a project and users with the BrightWork PMO Manager security role can edit the project team member Access Level.
When a user is made the actual Project Manager of a project outside of any business unit provided access, they will be given admin rights to the project. The Project Manager field in a project is populated with all BrightWork Project Manager security role users, irrespective of any business unit provided access.
Deleting a Project Team Member removes their access, assuming they don’t have access via business unit membership or a business unit security role.
Can move a project to a different portfolio which will change its security.
++++++
- Users with the BrightWork PMO Manager or System Administrator security role automatically get access to everything in BrightWork 365.
- The actual Project Manager of the project always gets access to the project. Therefore, if you want to setup a confidential project but not let the project manager have access to it yet, make yourself the project manager until you are ready to let the planned project manager know about the project.
- Deleting the Project Team Member record of the actual project manager from the Team tab will not revoke access for that user.
If you’re created as a team member, either by assigning work or manually in the Team tab, you’re automatically added to the Edit team, or if you’re nominated as the Project Manager then you’re automatically added to the Project Admin team. Done through the Team tab. Select the team member name to open a new window where you can alter the user’s Access Level = None or Edit.
If a user has no access they will only be allowed to have work assigned to them.
If you remove assignments from a team member, they still have their access to the project. To get them out you’ll need to delete them from the Team tab.
What happens to the team members when the project moves to a different program/portfolio? The user's project access level moves with them to the new portfolio, it does not get reset to none.
- The Access Level for users with the BrightWork PMO Manager security role must be set to Edit; if an attempt is made to change their Access Level it will be reset to Edit and an email explaining this change will be sent to the actual project manager of the project.
- When a security role is granted to a user after they are added to the Team tab in a project, and that user had an Access Level of None prior to being given the security role, the Access Level will continue to display as None even though the user now actually has Edit access.
Check User Project Access
- From within a project, select the Check Access link in the toolbar of the Project.
- Search for the relevant user in the User lookup field and view their project access details.
- Click the Who has access link to see information about all users that have access to the project.
++++++++
Set 'Access Level' value for new Project Team Members using Project Settings 'Default Access Level'
When a user is assigned work for the first time in the project, the Access Level value in the newly created Project Team Member record should be set from the value in the Project Settings record. If the user is the actual Project Manager, the value will always be set to Edit. When a project is created, the Default Access Level value in the Project Settings record should be set from the corresponding Default Access Level column in the Project Template. The Default Access Level column is a Boolean that has None and Edit as the two options.
The Access Level toggle also appears on the quick create form for manually adding a new Project Team Member with the Access Level taken from the Default Access Level specified in the Project Settings.
Approval coordinator and sponsor (from outside the Business Unit) will need to be manually added as project team members. To be noted in documentation that customers will need to include them. Approvers can approve via email and will not need access to the record.
Frequently Asked Questions
If a user does not have any access to a Project, Program, or Portfolio by any method, will they still display as a choice option in user drop-down fields?
Yes, this is by design.