This is one of a series of articles designed to help your organization get the most out of PPM Pro.
PPM Pro provides great flexibility in managing what users can see and act on what entities, but with great flexibility comes great complexity (and responsibility ;). It is easy to get lost in the weeds of permissions management, so the purpose of this topic is to clear cut a path for you and enable you to more easily manage your users' permissions and access given your company's needs. If you have any questions about any of the following or other permissions management needs not addressed here, please contact Customer Care or Consulting Services. If you have another example or a helpful tip not portrayed below that you would be willing to share, please email productmanagement-ppmpro@planview.com and we will gladly add it!
The steps covered in this topic include:
Step 1: Inventory your users' permission needs
Step 2: Ensure users have appropriate user types
Step 3: Add users to legacy entity teams
Step 4: Create/update groups and organization hierarchy for easier permissions granting
Step 5: Add users, groups, and/or units to standard groups
Step 6: Review and update your permission profiles
Step 7: Maintain and trouble-shoot permissions
The key to getting your arms around permissions management is first understanding what permissions your various users need and then determining which of the various ways users can be granted access to an entity (project, resource, tasks, request, and so on) should be used. The KISS principle (keep it simple, silly) applies: grant permissions to users, groups, and units only as needed, to simplify long term management and because it is a lot easier to giveth than to taketh away.
The permissions a user has are additive across the 5 different ways in which they are granted permissions. Three of these ways, User Type, Standard Group Permissions, and Profile-based Permissions, are where you will primarily be living when it comes to permissions management. The fourth, Legacy Team Memberships, only applies if you are using Enterprises (Accounts), Divisions (Business Units), or Departments (Programs); most customers are no longer using these because the organization hierarchy is becoming a more powerful method for organizing and granting permissions in lieu of these legacy entities. The fifth way is through Implicit Permissions, which really are automatic and do not require your management, they are just good to be aware of (these are covered in Step 7).
A user's permissions are the combination of all permissions granted in these ways
Before you begin assigning or updating permissions, take a fresh inventory to determine what permissions are needed by what users. You'll particularly want to ensure you identify which users need the same permissions, because it is much easier to maintain your user permissions when you can manage them in sets of users, for example as groups or units of users. It is strongly recommended that you create an initial spreadsheet or chart of your sets of users to help organize their needed permissions so that you can reference it when managing permissions (here is a Sample Permissions Spreadsheet in case it helps). Some considerations that might help you as you inventory include:
Resources must be users in order to access PPM Pro and to be granted permissions. When users are created, they are assigned a user type, which inherently gives them the ability to take advantage of certain permissions and not others. Think of the user type as a way of automatically constraining what permissions are possible. For example, a Request user type will allow a user to be granted permissions on requests, but not on any other entity (even if a Request user had a profile-based permission that gave all project view permissions, they still could not view projects because their user type limits them to only requests).
The four user types that apply to people who will be accessing the PPM Pro user interface are:
Because the different user types allow different types of access, you'll want to make sure your existing users and new users have the appropriate user type. When you create or edit a user, choose the user type based on the user's needs:
Note that if you are creating or editing a user and receive a message that you do not have enough licenses for the selected user type, please contact Customer Care or your Account Executive. User types are tied to license, which in some cases can be adjusted (for example, increasing the number of Request Users, as their licenses are effectively free) or potentially shuffled or added based on your needs.
Hopefully you can skip this step to save you time and maintenance. There are still some legacy entities in PPM Pro that do not have the ability to have profile-based permissions: Enterprises (Accounts), Divisions (Business Units), and Departments (Programs). If you do not use these entities, excellent, do skip to Step 4! If you do use these entities, then a Full user may be granted permissions on them by being a member of the entity's team, with any of the following rights configured user-by-user:
For any of your users who need one or more of the above permissions on Enterprises/Accounts, Divisions/Business Units, and/or Departments/Programs, add them to the relevant entity's Team with appropriate permissions (see Creating Permissions-Based Entity Teams).
Once your user types are in good shape and before you begin granting other permissions, use the inventory you took in Step 1 to identify any common sets of users that you could potentially create groups for or make use of existing organization hierarchy units. You'll want to update existing groups and organization hierarchy memberships and/or create new ones, so that as possible you can apply the same permissions to these groups and units. Both groups and units can be assigned to standard groups (Step 5) and to profile-based permissions (Step 6). Taking advantage of groups and units can simplify your permissions management because you don't need to add (and continually update) user by user.
The two types of groups you can create are user-defined and filter-based. The primary difference between these two groups is how their members are identified. With user-defined groups, you explicitly add individual users, other groups, and/or units. This is a great group to create if you need to be able to ensure only certain people are part of the group. The downside is that you will need to manually maintain this group to ensure the correct people are in it. With filter-based groups, a resource filter determines who the members are. This is a great group to create if you want to ensure all users with a certain property are automatically included, meaning much less maintenance for you. The downside is that you need to make sure the resource filter you use pulls in only those users that you want in the group.
For example, if you know that certain roles (such as financial managers) will need the same permissions (such as viewing all financial information across the organization), you can create a filter-based group focused on that role and then add it to a standard group (such as Internal Cost Visibility). Or, if you have a set of project managers who need access to view all projects across an organization, you can create a filter-based on that role and assign the group a global rule in profile-based permissions (such as Full View Access). Another example of a filter-based group is based on a common property shared by a group of users, such as a particular set of skill categories or sharing the same timesheet approver.
Unit membership hopefully is already organized in a meaningful way for your company. Oftentimes all members of a unit will need similar permissions, allowing you to add them to user-defined, filter-based, and/or standard groups as well as to a global rule in profile-based permissions. For example, if you know that all members of an organization hierarchy unit (such as Finance) and any child unit members should have the same permissions (such as financial data access), you can add that unit to a standard group (such as Billable Rates and Internal Cost) or global rule in profile-based permissions (such as Organization Finances - Full Edit).
The ability to access certain views and functions in PPM Pro have not yet been included in the profile-based permissions model. A Full user, other group, and unit may be granted permissions to these views and functions by being added as a member to certain standard groups (other user types will not appear for selection within the standard group's Add Team Member modal).
Based on your permissions inventory (Step 1), consider the following needs and add relevant Full users, groups, and/or units to standard groups as appropriate:
User, Group, and/or Unit Permissions Need | Add to Standard Group | FYI |
---|---|---|
Access to Admin view and functions | Admin |
|
View all bill rate, billable amount, profit and margin information, including in rollups and reports | Billable Rates |
|
Access to the Capacity & Demand facility | Capacity and Demand |
|
View all internal cost, profit and margin information, including in rollups and reports | Internal Cost |
|
|
Organization | |
Publish and unpublish dashboards | Publishing | Users, groups, and units who need to publish dashboards should be granted separate profile-based permission to Create dashboards |
|
Resource | |
Make corrections or additions to users' timesheets from Organization > Manage Time & Expense > Resource Time | Timesheet Manager | This is a very powerful capability and should not be granted lightly or to many users |
Note that there are a three other standard groups that convey permissions that you are unlikely to see, due to the feature being deprecated or in low usage. If you see these standard groups, please see About Groups for their permissions: Enterprise (Account), Fixed Bid Manager, or Expense Manager.
Profile-based permissions can be applied to any user type and are used to grant granular permissions on various entities. An individual 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 = Permissions + rule + who + entity