Skip to main content
Planview Customer Success Center

About Profile-Based Permissions

Profile-based permissions refers to the permissioning model PPM Pro employs for most entities: projects, tasks, issues, portfolios, assets, reports, filters, dashboards, and the "new" requests. The remainder of the entities use what's referred to as Permissions-based Entity Teams. See also About Entity Teams.

Some terminology:

  • A profile is a container for permissions.
  • A rule determines who the permissions are applied to, and whether the permissions are applied globally or per-(entity)-instance.

You use a profile in conjunction with a rule to configure who has what permissions on what entities. The most commonly used rules rules are Global rules and Team rules:

  • Global rules grant permissions to all instances of an entity. You can grant global permissions to users, groups, and units. Note that global permissions are in effect immediately.

  • Team rules grant permissions to specific instances of an entity - for example the "Finance" portfolio or the "Servers" asset. You can grant per-instance permissions to users, groups, and units that are on the team of an instance of the entity. Note that per-instance permissions are in effect only when paired with a user/group/unit and added to an entity team.

Rule Types

A rule type determines who gets the permissions when you create a profile:

  • Global - Gives users, groups, units the specified permissions to all instances of an entity. For example, you can configure a profile with a Global rule and project View permissions. Assign that global rule to the All Users group, and the result is All Users can now view all projects. You'll probably want to create at least one group before you use this rule type.

    • Note: For the Project and Request entities (not "legacy" requests), you can grant global permission to all entities, or to specific entity categories. You will see the categories in the Permissions Hierarchy. See Profile-Based Permissions for Requests.

    • When working with units, please remember that units are unique in that they can have a manager, as well as parent/child relationships with other units. Please note the following about Units:

  • Any permission granted TO a unit (like when you add a unit to project team along with some permissions), those permissions are granted to all the unit members and all child/grandchild unit members AND to their corresponding unit managers.
  • Any permissions granted ON a unit (like from a special access rule), are granted on all the unit members and all child/grandchild units, but NOT on the corresponding unit managers. 
  • Granting permissions at the root unit is analogous to granting permissions on All Users.
  • Owner - Entity owners get implicit rights to the entity they own; these rights are in effect regardless of whether you have created an Owner profile. For example, project owners get Edit/View rights on the project Details section - these rights cannot be removed. You can use an owner profile to grant additional permissions to entity owners, such as Delete project or Edit all sections. See Implied Permissions for Entity Owners for information about the implied rights for each entity owner. 

  • Team - Team rules give users/groups/units permissions on an entity instance (a specific project, for example, rather than all projects). Users/group/units can be added to an entity instance team (such as a project team) along with a profile that describes their permissions. 

  • Association - Associations are relationships between units and portfolios or units and projects. You can use an Association rule to grant selected permissions to unit members on associated portfolios or projects. For example, you can create an association between the Finance Unit, with the association rule "Benefits Unit", and all finance projects. All Finance unit members will be granted the configured permissions to any project with the association "Benefits Unit". See About the Organization Hierarchy and How Do I Grant Units Access to Specific Projects.

If you are using Centralized Staffing, you'll have additional rule types:

  • Unit Manager - Applies only to resource-related permissions. Unit Manager rules gives each unit manager permissions on the resources in the manager's unit. PPM Pro provides a default Organization Hierarchy Managers profile that grants staffing permissions to all unit managers.

  • Special Access - Special Access rules give unit staffing permissions to users who are not members of the unit. Similar to Team rules, you supply a profile when adding a user, group, or unit to a special access list.

Permissions

The following permissions are available for each entity currently supported by permission profiles:

  • View - Allows user to view the selected entity/sections. See Using Profile-Based Permissions for Projects

  • Create - Allows user to create the entity and its child entities (for example, create project also allows you to create tasks). Remember that Create permission is always Global - you cannot grant permission to create an entity instance (meaning, you cannot grant Create permission using a Team rule).

  • Delete - Allows user to delete the entity and its child entities.

  • Edit - Allows editing of selected entity/sections and child entities. Similar to the View permission, for some entities you can select specific sections to make editable.

  • View Availability - Allows a user to view resource availability in the Resource Workbench and the capacity and demand facility.

Staffing Permissions

Additional permissions for the Resource entity if using Centralized Staffing:

  • Propose - allows users to propose resources to fulfill demand from their pool of resources

  • Staff Directly - allows users to fulfill demand from their pool of resources

  • Process Requests - allows users to act on a staffing request by fulfilling demand, partially fulfilling demand, or declining the request

Best Practice: Combine Multiple Rules in One Profile

When possible, it's a good idea to add more than one rule type to a profile. This will cut down on a lot of clutter.

There is no limit to the number of rules you can include in a profile. For example, in one profile you can include a global rule that grants global permissions to a one or more users, as well as a team rule that offers the same permissions for use on an entity instance. In the example below, the Frank True has full edit permission for ALL projects (Global rule); in addition, there a Team  rule that can be used to give one or more users full edit permission on one project (Team rule). You could have created separate profiles for the group and the user, but that is not necessary.

multiple_rules.png

 

Exploring Permissions

PPM Pro offers administrators an interface for investigating what permissions are applied to a particular entity, and the permissions granted to a specific user. Please see Using the Permissions Explorer for more information.