Skip to main content
Planview Customer Success Center

Transitioning to Profile-based Permissions for Projects

This topic might be of interest to PPM Pro users who have been using the product since June 2017 or earlier. The transition to profile-based permissions for project is complete, and the information in this article will be left here for a while as these users become accustomed to the new model. Users who started with PPM Pro after June 2017 were provisioned with the new permissions model.

Innotas provided an automated process for converting existing customers onto this new permission model. The main things to remember is that the script mapped a subset of standards groups to profiles:

  • Full Users group was mapped to Project Viewer profile

  • Org group was mapped to Project Full Edit profile

  • PMO group was mapped to Project PMO profile

Things to Keep In Mind

The migration created a set of profiles - these profiles can be changed or deleted. So if you don't see a profile referenced here, it just means that you removed or renamed.

Treatment of Full Users:
  • In the legacy permissions model, Full users were implicitly granted permission to view all projects by virtue of being a Full user. 

  • In the profile-based permission model: Full users are placed in a new Full Users group that has been mapped to a global permissions profile ("Project Viewer"), which grants view rights to all projects. This mapping provides equivalent behavior to the legacy permissions system by default (Full users can view all projects). You are not required to keep this configuration. For example, now your organization can now distribute different permissions to different users, rather than giving the same permissions to a static group of users. For example, you can remove the profile and distribute permissions by user, group, or unit.

Permission to Create Projects
  • Legacy permissions model: User must be on the team of the Department (was Program) to which the project belongs, with "Create Projects" permission, or be a member of the Organization standard group.

  • In the Profile-based permission model: User must have global Create permission. This gives you the flexibility to remove users from the Organization group who were only there for project Create/Edit permissions.

Dashboards and Reports
  • To create or run reports on a specific project, you must be on the team of the project with a profile that minimally grants View permission

  • To create or run reports on all projects, you must have permission to view all the projects (either global permission, or team permission on each project). Rule of thumb: if you can see it in the UI, you can see it in a report.

Ability to Grant Permissions by Hierarchy Unit (Division and/or Department)
  • Legacy permissions model: this was not possible. You could not grant privileges to projects for different divisions

  • Profile-based permissions model: you can create an organization hierarchy that contains units which correspond to divisions. Using the Association permission rule, the members of one unit/division can be given team profiles for one set of projects, and members of the another unit/division can be given team profiles for a different set of projects. Or, you can simply place the appropriate user/groups/units on the teams of selected projects. See Permissions FAQs.

Use Permissions Explorer to Verify Permissions

The Permissions Explorer is a tool that helps users with administrative privileges manage profile-based permissions. You can use the Explorer to debug a variety of situations. For example:

  • Why does Prof. McGonagle have access to project 2017 Hogwarts' Finances?

  • Why can Hermione Horricks edit the Sorcerer's Stone project but Ron Beasley can only view it? They are supposed to have the same permissions.

  • Why can Hagrid see the Rollups page on all Hogwarts projects? He should not be seeing any financial information.