AAD Sync

If you would like to use groups instead of assigning security roles to each user, you can leverage the Azure Active Directory sync process to Dynamics 365 teams. To do this, you add a user to either an Azure Active Directory security group or Microsoft 365 Group, then associate that group to a Dynamics 365 team, and assign the security role to the team. This way, when new users come onboard, you simply add them to the proper Azure Active Directory group. This makes management of permissions and users much easier. To set this up, you will need to have access to the AAD Azure Portal or work with your IT administrator to get the object ID for each group you set up so you can link them to your Dynamics 365 teams.

Click here for a complete guide on setting up AAD sync.

Platform Security (Group level Ownership)

The security framework in the platform leverages the capabilities of Dynamics 365 security roles. There are five basic roles which are shipped with the solution, each of which provides users of the system with access to the data they need to do their job. The platform leverages the use of Teams in Dynamics 365 to provide group level Ownership to entities. For example, if a project is owned by a Team, that Team will also be attributed Ownership for any Risks, Issues, etc., that relate to that project. This provides access to all records relating to the project to the entire project Team.

Work focuses on managing your own work items. Projects focuses on projects across your organisation. There are two security roles included in this space.

• The Project User role is the base level role for a user of the platform. Users in this role have the required permissions to create, update and delete entity records that they have created or have been provided access to.
• The Project Executive role is intended for users who require access to all projects in the platform, but who do not require the Portfolios functionality. Users in this role have the required permissions to create, update and delete entity records that relate to all projects.

Portfolios includes portfolio management assets such as portfolios, programs, proposals, challenges, and ideas.

• The Portfolio User role is intended for Users who require access to Portfolios functionality in the platform. This role provides users with access to create and manage Portfolios and Programs and with visibility of all Projects and Registers.

Strategy includes all items for Strategic Execution Management.

• The Strategy User role is intended for users who require access to Strategy functionality in the platform. This role provides users with access to create and manage Strategic Themes, Strategic Goals, and Benefits with visibility of all Portfolios, Programs, Projects and Registers.

At last, the Admin User role provides Administrator level access to all custom entities relating to the platform, including the ability to create, update and delete any entity records relating to the solution. Admin Users are also provided with access to all areas in the platform, including the Settings area.

Click here for a complete guide on security groups.

Security Model

The security model shown in this diagram highlights that each roll builds on top of each other. You should grant each user or team an appropriate role as shown. Note, you will also need to add the “Basic User” role for each user if you are accessing a non-default Power Platform environment, which we recommend for platform deployments.

Basic Security Roles

The basic security roles are shown in more detail on the image below for reference. A legend is provided to show the different levels of access, such as read or write access, and to which audiences, such as the entire organisation, the business unit, or just to the individual user.

Modular Security Roles

Other than the five basic security roles, the platform also provides some out of the box modular security roles. These are more fine-grained controls of which users have access to different functionality within the platform. Note, that modular security roles are not specifically designed to be functionally complete in isolation, as usually they are applied as a combination with existing security roles.

Some special cases also need to be mentioned. The Assigned To ownership case always takes precedence, so if you are assigned to a record, such as an issue or risk, you will have edit rights to that record, however, you will not have access to other artefacts associated including the project itself. Another special case role is the Resource Organisational Access role. This is to be used if you have configured Business Units and you want visibility to all bookable resources within your organisation rather than the default, which is only bookable resources within your same business unit.

---

Business Units

Business units are a function of Dynamics 365 security that allows you to separate your data. There is always an Organisational Business Unit at top of the Business Unit tree and all users are assigned to that by default. An administrator can create separate business units and then assign people to different business units. A user can only be directly associated to a single business unit. The portfolio, program, or project records get associated to a business unit by the business unit of the user or team that is the owner of that object. Keep in mind, if you use business units, the membership of a Microsoft 365 Group, will give that user explicit access to that record, regardless of which business unit they are in.

Troubleshooting Permissions

Troubleshooting permissions come in to play when you are creating your own custom security roles and testing access. You might get an error saying Access is Denied or Insufficient Permissions. You can use the Browser Developer Tools when accessing this error to get more details in the Response Body about the missing privileges.