This article is for BrightWork 365 Release 2024-2 and newer.

Project Management Context

Organizations do not always want 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 several options to accommodate both of these security requirements through a flexible security and access model that includes business units, portfolios, and projects.

What's In Scope for Security & Access?

Items included in Security & Access	Items excluded from Security & Access
Portfolios Programs Projects Team Member Security Default Team Member Access Status Reports Risks Issues Actions Costs Custom table support (via customizations)	SharePoint Power BI Microsoft Teams Requests Content Templates

Due to the items excluded from Security & Access noted in the table above:
- If you have confidential programs and portfolios, do not create templates with confidential information, and leave the Portfolio and Program fields blank, otherwise everyone can potentially become aware of their existence.
- Customers are advised to use generic names for confidential projects as the project names will be visible to all users in these and other various places in the app.
- Remove from the Power BI workspace those users that you do not want to view confidential projects, since these projects will be displayed in Power BI dashboards.
Users with the BrightWork PMO Manager security role have access to everything in BrightWork 365, including confidential projects, regardless of the chosen security model or their assigned business unit.
Security will not work if you have customized any out of the box BrightWork 365 security roles. If necessary, create your own custom security roles instead. If you have already customized any of the BrightWork 365 security roles in a custom solution, security is not going to work until you upgrade the environment that the unmanaged version of the custom solution is in and reimport the managed custom solution into the environment.
If you have an unmanaged layer on any of the out of the box BrightWork 365 security roles, security is not going to work until you remove it.

Security Model 1: Open Access (default model)

In the default open access model, all BrightWork 365 users have access to all portfolios, programs, and projects within the BrightWork 365 app. Note that open access can be mixed together with a restricted security model as needed.

Example: Single Open Portfolio

One business unit and one portfolio with access to all app content.
All users have access to all portfolios, programs, and projects.

Security Model 2: Portfolio Security

The Portfolio Security model explained in this article uses Power Platform business unit membership (see Microsoft article) combined with BrightWork security roles to grant users access to a portfolio attached to a business unit, and all the portfolio's child projects and records.

The BrightWork 365 business unit setup for Security and Access can divide access into a Confidential Projects and a Contoso Projects hierarchy. Further business units can then be created to minimize access and more easily manage restrictions, as required.

The high-level steps to implement (further details down below):

Create business units and a business unit hierarchy.
Assign BrightWork 365 users to a home business unit.
Assign users security roles in their home business unit.
Assign users security roles in secondary business units as needed.
Create portfolios that will act as the top parent levels of the hierarchy in BrightWork 365.
Within each portfolio select an Owning Business Unit.
Assign programs to a portfolio associated with the business unit desired for the program and its child projects.

After the above steps are completed, users will have access to the portfolios, programs, and projects that are associated with the business units in which they have been given security roles.

Example: Projects Secured by Department

Engineering users are added to the Engineering business unit and only see its portfolio, program, and projects.
Marketing users are added to the Marketing business unit and only see its portfolio, program, and projects.

Note that a user can be given security roles in both the Engineering and Marketing business units so that they have access to both portfolios, programs, and projects.

Example: Portfolio Security with Confidential Projects

Users who need access to all confidential and non-confidential projects would be in the parent Contoso All Access business unit.
Users who need to see only non-confidential projects would be in the Contoso Projects business unit.
If users should only be given access to individual confidential projects by exception instead of all projects in the Confidential Projects portfolio, then instead of giving them access via membership in the Confidential Projects business unit, you would give them access to the individual projects from within each project.
- This exception user project access is managed by the Access Level in each project team member record in each individual confidential project.

Security Model 3: Portfolio Security with Project Security

After setting up your organization's top-down Portfolio Security model, you may find the need to provide access to specific projects for some users outside the configured access boundaries. This can be accomplished with the project security option (in conjunction with portfolio security) which provides this capability. For more information see Project Security & Access.

Example: Portfolio & Project Access by Exception Using Holding Pool - without Confidential Projects Business Unit

A select group of users are given membership in an All Access business unit.
Majority of users placed in a Holding Pool business unit that has no portfolio, program, or project access. These users are given access to either a portfolio or to individual project by exception, as needed.

Example: Portfolio & Project Access by Exception Using Holding Pool - with Confidential Projects Business Unit

A select group of users are given membership in an All Access business unit.
A select group of users are given membership in a Confidential Projects business unit for additional granularity.
A select group of users are given access to a somewhat less restrictive group of projects (Contoso Projects business unit).
Majority of users are placed in a Holding Pool business unit that has no portfolio, program, or project access. These users are given access to either a portfolio or to individual project by exception, as needed.

Portfolio Security Configuration Steps

If you need to manage project access for individual users by exception after setting up Portfolio Security, see Project Security & Access.

Only users with the System Administrator security role can manage business units and security roles in the BrightWork 365 environment.
Customers that want 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.

Before proceeding:

Confirm that Modern business units have been enabled in the BrightWork 365 environment as described in the BrightWork 365 Install Guide.pdf and BrightWork365 Upgrade Guide.pdf
Have a clear understanding of the business unit and portfolio hierarchy that you want to create, which business unit users will reside in, and the security roles they will be given in their home business unit and in other business units if you plan to provide some users with extra access.

Prerequisite Step: Design your organization's security access hierarchy

Prior to physically implementing a security access hierarchy and configuration, map out the design 'on paper' along with an analysis of practical implications and future needs.

Step 1: Create an all-access parent business unit for users that need access to all app records, i.e., "{org name} All Access"

This step is a best practice for future design flexibility.

Click Business Units > See all and + New business unit.

Fill out the form - pay attention to the Parent business unit that you select.

Click Save.

Step 2: Create a business unit hierarchy under your All Access business unit

Child business units inherit user security role assignments from their parent business units.

Business Units

Business units are created in the Power Platform Admin center by a System Admin.
All business units, apart from the Default Business Unit, have a parent business unit.
New business units get non-editable copies of all the security roles found in the automatically created environment Default Business Unit (e.g., all the security roles that ship with BrightWork 365).

Business Unit Hierarchy

Setting the Owning Business Unit in a Portfolio sets what child users will see or not see.
Portfolios are the top-level grouping for Projects.
Programs are a second-level grouping for projects.

Step 3: Assign BrightWork 365 users to a home business unit

A user with the BrightWork PMO security role will have organization-wide global access regardless of their assigned business unit. They will have access to all content within BrightWork 365 including confidential projects.
If a user’s business unit is changed, all of their security roles are removed from all business units. They will need to be reassigned all of their security roles in the new business unit, even if they already had security roles in that new business unit. It is recommended to make note of their current security role assignments prior to the business unit change.

Assigning users to a business unit will in turn control which portfolios, programs, and projects they have access to.

It can take 30-60 seconds per user when their business unit is changed using the admin center Modern UI.
User business units can be viewed in person views in the Admin Area.

Users can be bulk assigned to a new Business Unit in the Dynamics view by the environment administrator.

Click Users > See all and then Manage users in Dynamics 365.

Change the view from BrightWork Users to Enabled Users.

Select all the users that you want to move to the same business unit.

Select the business unit and click OK.

Step 4: Assign users security roles in their home business unit

Users will display as a choice option in the various app user drop-down fields even if they have not been given any access to the project, program, or portfolio.

Security Roles are assigned at the Business Unit level. Typically, users are only assigned security roles in their own business unit.

When you are bulk updating security roles, all users must belong to the same business unit and be receiving the same security roles.

From the view on the previous step, select the user you want to apply the same security role to and click Manage Roles.

Select the roles that you want to assign and click OK.

Step 5: Assign users security roles in secondary business units as needed

Users can only be a member of one business unit but can be given security roles in another business unit to broaden their access to portfolios, programs, and projects.

For example, Alex is a BrightWork Project Manager in Marketing, which is his home business unit. He can also be given the BrightWork Team Member security role in the secondary Product Development business unit.

In the Microsoft Power Platform admin center:

Select the BrightWork 365 environment.
Navigate to Settings > Users.
Select the relevant user.
Click Roles > Manage roles.
Select the desired secondary business unit in the Business unit drop-down.
Select the Basic User and BrightWork Team Member security roles (at a minimum), and any other desired security roles the user needs.
Click Save.

Step 6: Create portfolios that will act as the top parent levels of the hierarchy in BrightWork 365 (Portfolios > Programs > Projects)

See Portfolios for details.

Step 7: Within each portfolio select an Owning Business Unit

Only users with the BrightWork PMO Manager or System Administrator security role can configure a Portfolio's Owning Business Unit.
A business unit can own as many portfolios as necessary.
If a Portfolio's Owning Business Unit is changed to one that is above its current Owning Business Unit in the hierarchy, the change will be automatically reversed, and an email notification of this reversal will be sent to the person who attempted the change.

In the Portfolio's Statement tab, select the relevant Owning Business Unit in the Owning Business Unit field.
Read the warning message, choose the new Owning Business Unit, and click Confirm or Cancel.

If the Owning Business Unit of a Portfolio is changed, the Owning Business Unit of all the child Program and Project related records will also be updated. This means that some users in the previous business unit may lose access to this portfolio and the other records. It also means that users in the new Business Unit will now be able to access records in this Business Unit.
Concurrent usage is not supported, e.g., before moving a Portfolio's Owning Business Unit, the BrightWork PMO Manager should inform the team to exit any child Projects of the Portfolio.

Step 8: Assign programs to a parent portfolio associated with the business unit desired for the program and its child projects

Programs inherit the Owning Business Unit from their parent portfolio.

To associate a program with a parent portfolio, select the relevant portfolio as you normally would in the program's Statement tab.

If a program is moved to a different portfolio with a different associated business unit, or if a portfolio's associated business unit is changed, some users who never had access to that part of the hierarchy will now have access, and some that had access previously will no longer have access; this will be determined by either their own business unit, or from access granted at the project level.

Portfolio Security & Access