User Roles

Modified on Thu, 6 Feb at 12:38 PM

Cora, through configuration, provides several security and access features available to administrators so that all users are not daunted with the many features available in Cora. Furthermore, Cora provides the administrators with a level of comfort that users cannot make changes to either the configuration or the data by accident.

System access and data access is a vital step in the implementation of Cora and it is important to avoid giving users access to change system settings that affect other users. It is also just as important to make sure users are not being given access to projects and data that they don’t need to have access to. This means giving each user access to only the project(s) that they need to see, and then, defining which of the project(s) they actually update on those projects that they see.

There are three key components of Cora that drive this, the user type as in license type, the system role assigned to the user, and then group access (or Project Access and matching Project Profile). Note that there are further access settings available to administrators to add further granularity, however this article will focus on user roles.

User roles enable certain functionality to become visible to an end user. For example, if you want to add a Benefit’s Manager to your Cora instance, and you need that Benefit’s Manager to be able to create benefits, assign them to projects, add Outcomes and Strategies to benefits, you need them to have this role. However, you don’t need to give end users who just update benefits assigned to their projects with this role, that is driven by the project profile, see next section.

User Roles can also be used for permissions. For example, it is possible to restrict access to a feature or field for a particular role, e.g., the Properties tab in the ‘Home’ menu is only visible to users that have the role of ‘Project Administrator’. In other words, Cora administrators can create additional ‘custom roles’ which can be further used for security of features.

Note: Users can be assigned one, many or no roles at all. A user must have a Full License in order to be assigned role(s). The following are some examples of roles that may be utilised in Cora PPM.

The following is a list of SYSTEM roles, their descriptions and prerequisites. Thereafter an administrator can create additional custom roles. Therefore, if you see a role that is not in this list, it has most likely been created as a custom role.

KPI Executive

The KPI Executive system role is a role that when enabled on a user’s account makes the KPI Dashboard available for that user.

Please note that the “KPI” module has now been deprecated and therefore can be ignored.

KPI Executive cannot be enabled unless the KPI module is enabled in Cora.
This is accessed via: ADMINISTRATION / SYSTEM / MY INSTALLATION / FEATURES / KPIs
Only ADMINSTRATOR user types can enable KPIs
Only KPI Executives can add KPIs
Adding KPI Module to Cora adds a new Project Profile rule:
All Project Owners inherit this rule automatically
All other Project Profiles may opt in

Time Sheet Administrator

With this role the user can update any other user’s timesheet as well as approve and un-approve time.

There are no prerequisites for this System Role to be enabled, all Cora sites have this role available always, it is part of the Cora Core Engine
All user types can be Timesheet Approvers, including Full Users; Administrators; Resource Only and even Portal Users, however Portal Users cannot perform any Timesheet Administration.
For more information, see: https://cst.corasystems.com/support/solutions/articles/156000179549-what-does-the-timesheet-administrator-system-role-allow-

Portfolio Manager

This role is needed to approve the project baseline, and delete projects, manage interproject dependencies and to update PROJECT status in Project Properties.

There are no prerequisites for this System Role to be enabled, all Cora sites have this role available always, it is part of the Cora Core Engine
All user types can be Portfolio Managers, including Full Users; Administrators; Resource Only and even Portal Users, however Portal Users cannot perform any Portfolio Manager tasks.
Since the release of custom workflows for baseline approvals, this system role has might not apply to Baseline approvals ONLY if they are in use. But the other items are still controlled by this role. For more information on this, see: https://cst.corasystems.com/support/solutions/articles/156000179551-baseline-approval-step

Benefits Manager

This Benefits Manager role provides access to the Benefits Management area of the system. This is where benefits are set-up and managed.

Benefits Manager cannot be enabled unless the Benefits module is enabled in Cora.
This is accessed via: ADMINISTRATION / SYSTEM / MY INSTALLATION / FEATURES / Benefits
Only ADMINSTRATOR user types can enable the Benefits Module
Only Benefits Manager can access the Benefits Management page the Navigation Bar. All other users will not see or be able to access this.
Adding Benefits Module to Cora adds 2 new Project Profile rules:
All Project Owners inherit this rule automatically
All other Project Profiles may opt in

Resource Manager

The Resource Manager role controls access to the Resource Manger Report.

There are no prerequisites for this System Role to be enabled, all Cora sites have this role available always, it is part of the Cora Core Engine
All user types can be Resource Managers, including Full Users; Administrators; Resource Only and even Portal Users, however Portal Users cannot perform any Resource Manager tasks.
In addition to allowing the user with this role to access the Resource Manager Report, it allows the user to see planned effort from other users in the report, the user can add other users to the report other than just themselves.

Workflow Manager

The Workflow Manager role provides access to the ‘Workflow Management’ section. This enables the user to stop and start workflows. For example, if a nominated workflow approver is off ill or has left, the Workflow Manager role can pause, re-start and cancel any workflow.

Workflow Manager cannot be enabled unless the Workflow module is enabled in Cora.
This is accessed via: ADMINISTRATION / SYSTEM / MY INSTALLATION / FEATURES / Workflow
Only ADMINSTRATOR user types can enable the Workflow module
Only Workflow Manager can access the Workflow Management page the Navigation Bar. All other users will not see or be able to access this.
The Workflow Manager only allows access to the page on the Navigation Bar, however, in order to actually administrate any workflow, that user needs to be selected as a workflow administrator for each workflow.
For more information on workflow configuration, see: https://cst.corasystems.com/support/solutions/articles/156000067625-administration-workflow-configuration

Finance Manager

This role is needed to approve the budget in the Financial Management module and unlock a budget that has been approved if it needs to be changed. It also allows Finance Managers to access the Finance page to manage the import and import service.

Finance Manager cannot be enabled unless the Finance module is enabled in Cora.
This is accessed via: ADMINISTRATION / CONFIGURATION / FINANCIALS
Only ADMINSTRATOR user types can enable the Finance Module
Only Finance Manager can access the Finance page the Navigation Bar. All other users will not see or be able to access this.
Adding Finance Module to Cora adds 6 new Project Profile rules:
All Project Owners inherit this rule automatically
All other Project Profiles may opt in

Capacity Insights

The Capacity Insights Role gives access to Capacity Management, the insights views (portfolio, project and resource) and scenario planning.

Capacity Insights cannot be enabled unless the Capacity Management module is enabled in Cora.
This is accessed via: ADMINISTRATION / SYSTEM / MY INSTALLATION / FEATURES / Capacity Management
Only ADMINSTRATOR user types can enable the Capacity Management Module
Only Capacity Insights can access the Capacity Management page the Navigation Bar. All other users will not see or be able to access this.

Second Level Project Time Approver

Only users with this role can be selected on projects configured for second-level approval. Any time submitted against that project must first be approved by the Project Owner (or other user with time approval permission) and then by the designated second-level approver. Only once both levels of approval have been completed will the time sheet be approved.

Second Level Project Time Approver cannot be enabled unless the Second Level Project Time Approver is enabled in Cora.
This is accessed via: ADMINISTRATION / CONFIGURATION / Time sheet
Only ADMINSTRATOR user types can enable the Second Level Project Time Approver
Adding Second Level Project Time Approver to Cora adds a new Project Profile rule:
All Project Owners inherit this rule automatically
All other Project Profiles may opt in

Project Import

This role is needed to for non admin users to be able to import projects into Cora.

Project Import cannot be enabled unless the Project imports feature is enabled in Cora.

This is accessed via: ADMINISTRATION / SYSTEM / MY INSTALLATION / FEATURES / as below

Only ADMINSTRATOR user types can enable the Project imports feature
Only Project Import can access the Project Import page the Navigation Bar. All other users will not see or be able to access this.

Import Builder

This role is needed to provide users with the ability to import project, task, register and financial data into Cora PPM via the Management menu.

Import Builder cannot be enabled unless the Project imports feature is enabled in Cora.
This is accessed via: ADMINISTRATION / SYSTEM / MY INSTALLATION / FEATURES / as below
Only ADMINSTRATOR user types can enable the Imports Builder feature
Only Import Builder can access the Import Builder page the Navigation Bar. All other users will not see or be able to access this.
For more information on Import Builder, see

https://cst.corasystems.com/support/solutions/articles/156000179582-import-builder

“Custom Roles”

You can define and add further ROLES such as, for example, Change Request Manager, or whatever additional attribute you may want to assign to any user.

Only ADMINSTRATOR user types can add Custom Roles
User Management users can assign Custom Roles to users, but not add Custom Roles, see here for more information on User Management https://cst.corasystems.com/support/solutions/articles/156000179583-user-management
Custom Roles added cannot have the same name as any of the User Roles described in this list in the first column.