

The Group column lists the project groups that are part of the project team. Each project group can have roles assigned to it, which will allow members to perform certain actions within the project over and above those already granted to them via their specific system group membership. Project groups are used to designate which users or groups are assigned to a particular task within the project.
You can add project groups by clicking on the Team tab and selecting Actions → Edit. Then click Add group button. On the subsequent screen, provide the project group title, and assign roles to the project group. The roles allow the members of the group to perform actions in the application, such as create a project. Once the group is added to the team, you may select members (i.e. actual users) for the group but generally it's done within the project and not within the template.


Roles are permissions that are assigned within a project. This is how users can be given the ability to edit some projects, but not others. Since roles give permissions to members of the project groups that are assigned those roles, it can impact user licensing. For example, any user placed into a group with the role of Project Owner will occupy a user license. Roles are optional and do not need to be assigned to a project group unless needed.
An optional step after you have defined the project groups and corresponding roles is to assign system groups to the project groups. This should be done only if there are roles that should be assigned to the same system groups for all workspaces that are created from the template. For example, as an administrator, you might want to create a project group called Administrators and a system group to that project group so you will have access to all projects created using that template. It’s also possible to assign specific individuals to the project groups at the template level, but it’s not recommended. Because people get promoted, leave the company, etc., it could become burdensome to maintain the templates. In many situations, it is not necessary to assign anyone to the project groups since that job is intentionally delegated to the project creator and is usually determined on a project by project basis. Groups should only be added to templates when they are auditors or executives that need visibility into all projects.
Certain system groups or permissions are granted special abilities when they’re added to the team of a project. Examples of these are Customer Administrator, Project Administrator, and Contract Administrator. When users that have these permissions assigned to their User ID’s are assigned to the team of any project, they are automatically granted owner rights within that project because of the system level permission. System level permissions are groups that are assigned to users when they are created and are a part of their user profile. Roles are project specific and do not grant those same permissions site wide. This is how the system allows for you to have a user edit one project without the ability to edit all projects they are on the team of as in one case they might be an auditor and in the other, a stakeholder who will actively work on the project.