Granting Access Group Permissions to Users

An access group is a container of projects, users, reference tables, and/or planning elements (in Accolade Innovation Planning) that enforces information security. Access groups restrict which process models, projects, reference tables, or planning elements users can see or find using search. See Designing the Access Group Hierarchy for more information about planning the access groups for your company.

Assign each user account within your system to one or more access groups to grant access to the data available within that group.

Note:  Selecting the top-level access group (i.e. Root) grants permission to all access groups in the tree. Additionally, selecting a parent within the tree structure grants permissions to all access groups within that tree.

To assign permissions to an access group:

1. From the System menu, select Security & Groups > User Admin.

To filter the list of users, enter one or more search criteria to filter by name, login name, email address, function, or extended field by selecting one or more of the following options and clicking Search. More...
• Selecting a Function in the drop-down will display available users that are assigned to the function.
• Select a Group By option to arrange the user list by roles, functions, resource pools, or access groups.
• Click More options check box displays or hides the additional filter options.
• In the Active/Inactive drop-down, select to filter users by active and inactive status from the following options:
• Active Users Only - excludes inactive users.
• Show All Users - displays active and inactive users.
• Inactive Users - displays only users marked as inactive. Inactive status is indicated with grey italics.
• In the Roles drop-down, select a specific role to apply to filter the user list.
2. In the Users list, click the name of the user to open the user details for editing.
3. Click the Access Groups tab.

The access groups display in the tree on the left. Use the check boxes to grant the user certain permissions within selected access groups.

Note:  Selecting a parent access group in the tree structure automatically includes the child access groups, except for the Member Of column.

4. Define user admin rights for users with the Administrator role:

User Admin Right	Description
Member Of	When checked, the user becomes a member of that particular access group. Users must be a Member Of at least one access group.
Admin Of	Only enabled if the user has the Administrator role checked on the Roles and Rights tab. Administrators are granted create/edit ability only within the access groups for which they have Admin Of checked. All other rows will be disabled. Users with the Administrator role must be the Admin Of at least 1 Access Group. Only a root level administrator can grant a user Admin Of rights if they are not already an Administrator (roles and rights). If multiple users are selected and the editor does not select Admin Of for ALL users, they will appear to be read only.

5. Check the access group that the user belongs to for project access in the Access column.
6. Define project management rights for users with the Process Manager, Project Manager or Idea Manager user roles:

• The Project Manager role will be disabled if the user being edited has Manage Team checked in their Access Groups tab.
• The Process Manager and Idea Manager roles will be disabled if the user being edited has any of the following components checked in their Access Groups tab outside of the editors Admin Of groups.
• Manage Team
• Manage Process
• Migrate Project
• Add Project
• Delete Project
• Delete Activity
• Only Administrators at the highest level of the Access Group hierarchy (Root) can Create/Edit/Remove the following roles on the Roles and Rights tab:
• Administrator
• Process Designer
• Service Account

Note:  When creating a new user through Copy From, the same access group logic applies. Access group permissions will apply based on the administration permissions of the user creating the user profile. Administrator, Process Designer, and Service Account roles will not be copied over unless the editor is a root level Administrator.

Management Right	Description
Manage Team	The ability to edit the members of a team. Your company may have highly sensitive data and projects that require restriction around who can be assigned to the project. Use this option to define which Project Managers and Process Managers within your organization have the ability to add team members to their projects and change project team leaders. For example, if you are developing products in other countries, or developing products or services that require specific security clearance, it becomes increasingly important to manage the team based on location or specific security credentials. You want to ensure that once a team is set for the product, team members who do not meet the criteria for working on the project are not added. Users with the Project Manager user role do not require Manage Team rights at the access group level to manage a team: Use the Project Manager can manage team option when assigning a Project Manager to indicate that the user assigned as the Project Manager can add, remove, or replace members on the project's team. If a Project Manager user does have Manage Team rights at the access group level, you can override their Manage Team rights for a single project on project creation, migration, import, and when changing the Project Manager on the team. Users with a Process Designer role can only select a class for the model that is within the same Access Group branch.
Manage Process	The ability to assign gate owners and project managers, add team members to upload documents without a document owner and to enter metric values. As a best practice, only one user should have Manage Process rights for a project. Keeping Manage Process rights separate helps to prevent accidentally overwriting another user's changes.
Add	The ability to add a new project using an existing class and model.
Migrate	The ability to migrate or copy a project to a different process model.
Delete	The ability to delete a closed project from the system.
Delete Activity	The ability to delete activities that do not apply from within projects.

7. Define configuration permissions for users with the Administrator or Process Designer user role:

Configuration Rights	Description
Edit	The ability to edit configuration components. Your organization may be structured to have multiple Administrators or Process Designers in different branches. Restrict users to edit only the configuration components relevant to their branch of the organization. See Restricting Configuration via Access Groups Overview. View is automatically checked when Edit is selected.
View	The ability to view configuration components. Your organization may be structured to have multiple Administrators or Process Designers in different branches. When you grant users View access only, configuration components such as process models, gate documents, and deliverables and activities will display as read-only.

8. (Optional) Define the Security permissions via the Security Lists or Security Profiles tabs.

• Security Lists provide a regional list. See Security Lists Overview.
• Security Profiles provide a list of access for Class and Metrics to choose from for a user account. See Security Profiles Overview.

9. Click Save to save your changes.