Security Lists Overview

Security lists are hierarchical lists of different object types that control access to projects and unowned resource pools. Security lists grant access based on matches between security list selections in a user account and security list selections in projects and resource pools. Security lists manage access based on a combination of factors rather than just on the structure of the access groups tree. Accolade supports the definition of up to five security lists, with a maximum of 10 levels in each list.

Security lists prevent the following:

  • Users without access from seeing or navigating to project data in Upcoming Gates, Charts and Reports, or in optional components such as Accolade Portfolio Optimizer, Dashboards for Accolade, Accolade Innovation Planning, and the Accolade Office Extensions add-ins
  • Users without access from linking to a related project to which they do not have access.
  • Process Managers without access from managing projects to which they have Manage Process rights.
  • Resource Pool Administrators from seeing or creating pools that are outside their scope of access.
  • Resource Planners without access from seeing and modifying demand on resource pools they do not own.
  • Resource Planners without access from modifying capacity.

Users can still access projects of which they are a member of the project team through All My Work, My Project, and through Search, regardless of their security list settings. Project members not assigned to the project cannot search for project data or refresh Accolade Office Extensions reports on their projects.

If security lists are enabled, the combination of both access groups and security lists controls access to projects. User settings for both access groups and security lists must match those set for a project for users to have access to that project. To base access primarily on security lists, you can give most users high level access or even access at the Root level within the access groups. However, because security lists do not affect the management rights of Process Managers and Idea Managers or access to data in Reference Tables, the access groups must be developed at least to the level at which you want to define these rights.

Note:  Security lists do not control access to reference tables, and they do not affect the management rights of Process Managers and Idea Managers. Access groups control access for these roles.

Once defined, security lists are assigned to user accounts, projects, and resource pools.

Example Icon

A user with Paris selected in the hierarchy below could see reports on projects that also had Paris selected as long as the user and project also had the same check boxes selected in the other security lists in the system.

Security list example

But this user could not search for projects in Dijon, Asia, or in projects that only had France selected. Note also that check boxes that are filled in Multiple Selected Check Box do not provide access. They indicate that one or more of their child items are selected.

Combine the settings from multiple security lists to create a more intricate security framework. For example, one security list could define sales territory as in the example above. A second security list could define products by division, product type, and brand. Access to project information would be based on a combination of location and product responsibilities.

Security list selections are available throughout the system to grant access to projects, resource pools, or planning elements in Accolade Innovation Planning.

See the following to get started: