Note: Users with administrative privileges can create permission profiles.
A profile is a set of permissions. See About Profile-Based Permissions for more information. Note: If you are using centralized staffing, then there will be additional permissions that apply to the Resource entity. See About Centralized Resource Staffing and Creating Staffing Permission Profiles.
The Admin/Permission Profiles page is where you create permission profiles. Before creating a profile, it's a good idea to read About Profile-Based Permissions.
Anatomy of the Permission Profile page
There are two main sections: the Permission Profiles list, and the profile definition section that contains the Title, Description, Permission Rules, and the Permission Hierarchy. Remember to click the Save button any time you make changes.
Permission Profiles List
Click on any profile and see its definition by looking at the permission rules and the selected permissions. Create a new profile by clicking the New button. Give the profile a title, and optionally, a description of what the profile does. The title and the description appear in the list of profiles so you can quickly scan the list and get a sense of each profile's content.
Delete profiles by right-clicking a profile and choosing Delete, or select the profile and choose Actions > Delete. You will be reminded that the profile might be in use and if deleted its permissions will be removed from all users to whom the permissions apply. If you delete a team profile that is in use, the team members using the profile will be removed from the entity team. If you are using centralized staffing and remove a Special Access profile that is in use, the users assigned the profile will also be deleted from the Special Access List. Special Access lists are a tab on organization hierarchy units.
The Permission Rules determine the type of rule granted and to whom: Team, Global, Owner, Association, Unit Manager, and Special Access.
A profile can contain multiple rules that can apply to multiple entities. For example, the PPM Pro-supplied 'Read Only Permissions' profile has five team rules in it, one for each entity to grant team members View permission. See Rules Types for more information.
Helpful tip: Open the Add menu and hover your cursor over any rule type to see a description of the rule.
When you add a permission rule it is active by default - that is, the rule will be in effect if you use the profile. If you want to remove a permission but want to retain the profile for future use, you can inactivate one or more rules. This will remove the permissions described in the profile from users identified by the rule. Remember to click the Save button after activating or deactivating a rule, or click Cancel if you change your mind.
To delete a rule, select it and click the Remove button. There will be no warning when deleting permission rules, because you are simply deleting part of the profile definition, and not the profile itself that gets physically assigned to some set of users. Remember to click the Save button after deleting a rule, or click Cancel if you change your mind.
Using the Permission Hierarchy
The Permission Hierarchy is sometimes referred to as a tree. Different branches of the tree can be collapsed and expanded by clicking on the arrow to the left of a permission. Permissions are organized by entity, with each entity representing a leaf on the tree. You can select the entity leaf (click the checkbox) to automatically select all the permissions for that entity. Or, you can expand the entity and select individual permissions by clicking the checkbox next to each permission. A check mark next a permission means the permission is selected. If an entity leaf has a check mark, that means that all sub-ordinate permissions are selected. If an entity leaf has a minus sign (-), that means that at least one subordinate permission is selected, but not all subordinate permissions. Selecting the All Permissions leaf is a shortcut to select all the permissions in the tree (deselect to turn off all permissions).
Note that assets, portfolios, projects, and requests offer specific classes or categories on which to grant permissions. So you can have a global permission on all portfolio classes or all portfolios of a specific class. Similarly you can have a global permission on all projects, or all projects of a specific category. The same applies to assets (for classes) and requests (for categories).