About Profile-Based Permissions

This video provides an overview of profile-based permissions. Duration: 5 min.

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.

A profile-based permission is a basic CRUD permission packaged in a special container called a profile. The profile holds the permission(s), plus the scope for how to grant the permissions, who to grant the permissions to, and on what entities.

Profile = Permission + rule + who + entity

The permissions include create, view, edit, delete (there are some exceptions but let’s stick to basic CRUD for the purposes of this explanation).

The “rule” determines the scope of the permissions: global, entity teams, entity owners.
The “who” specifies who is granted the permission - an individual user, a group, or a unit.
The “entity” is any of the supported entities: projects, tasks, issues, portfolios, assets, reports, filters, dashboards, and requests.

Each profile contains a rule that determines the scope:

Global - Keeps the scope very wide – meaning you want to apply a set of permissions to all projects, or all tasks, or all reports.
Team - Narrows the scope to specific entity instances – specific projects, or specific tasks, or specific reports. This is referred to as a “Team” permission, because you apply the permission on a entity-by-entity basis and always associate it with a member of the entity team.
Owner - Kind of narrow and wide at the same time - an Owner permission is applied to any user who is the owner of an entity (like a project or a task). Owner permissions are automatically applied to any owner, and are simply a way to give standard access to each type of entity. You can configure different permissions for different types of entities. For example, project owners have permission to edit and delete their own project, but task owners can only create/edit tasks and cannot delete.

The complete list of rules types is described below.

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 or entity category. For example, you can configure a profile with a Global rule and project View permissions or project category ABC View permissions. Assign either global rule to the All Users group, and the result is All Users can now view all projects or all projects of category ABC. You'll probably want to create at least one group before you use this rule type.
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 - (Note: With the ability to now grant permissions on projects of specific categories, we think the Associations rule type will become obsolete and we are considering deprecating. Please avoid using, and if this confuses you, please enter a support case to ask for assistance.) 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.
Unit Manager - Applies only to resource-related permissions. Unit Manager rules gives each unit manager permissions on the resources in the manager's unit.
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). Note also that Create permission is required for changing the category of an existing entity. For example, if you are working with projects and notice that a project is using the wrong category, you'll only be ale to change the category if 1) the Category field is on the project Details or grid, and 2) you have Create project permission.
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 Managed 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

Permissions and Units

Generally speaking, permissions applied to/on a parent unit cascade to members of child units - with one exception: permissions are not always granted on the unit managers. See below:

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), those permissions are granted on all the unit members and all child/grandchild units, but NOT on the corresponding managers.
Granting permissions at the root unit should be analogous to granting permissions on All Users.

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 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.

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.