Skip to main content
Language Selector

  1. Other Languages

    (machine translation)

Planview Customer Success Center

Permission Access Levels

  1. Last updated
  2. Save as PDF

Overview

In addition to the various types of Permissions available in AdaptiveWork, Permission Access Levels let you manage editing/viewing permissions for users, groups or profiles, on Work Items, Cases and Customers. This eliminates the need for granting individual permissions.

For example, in a project, grant Editor permissions to a specific user and users of a specific profile, and Viewer permissions to a specific user group.

360001324453_mceclip8.png

See also Extended Permissions for External Users in User Groups

Note: To learn more about the relationships between user types, roles and permissions, see Introduction to User Types, Roles, and Permissions.

This section covers:

Enabling and Setting Up Permission Access Levels

To enable Permission Access Levels in your organization:

  1. Go to Settings > System Settings, and expand the Permissions settings. Enable Permission Access Levels.
    mceclip0.png
  2. Add the Permissions field to relevant view/property cards.
  3. With the Permissions field added, a user with full manager/owner/editor capabilities can assign any of the items below with Permissions.
    • Group - user groups and predefined system groups (Admins, Super Users, External, etc.)
    • Profile
    • Specific user
  4. Select permissions on the Work Item:
    • Editor - Read/write (same permissions as Manager)
    • Viewer - Read (same permissions as Reviewer)

Note: The new permissions are in addition to current permissions and roles on the Work Item, cases or customers (Project Manager, resources etc.).

360001341434_mceclip9.png

Work Items

Permissions set on a Work Item cascade to all child Work Items.
Note: User, group and Profile names will not be repeated in all child fields, however permissions will be applied based on the parent object.

Sub-Groups

By default, Permission Access Levels (Editor or Viewer) are inherited from parent groups to all sub-group levels. You can change this behavior in the System settings.

Basic mode

Note: For more about Basic and Enhanced modes, see Permissions.

  • Internal users – As all internal users have basic permissions, this feature applies only to Editor Permissions
  • External users – In Basic mode, this feature applies to both Editor and Viewer

Enhanced mode

For an internal user with full license - The permissions are the same for the user, profile and group. If granted on the hammock level, Work Item level permissions roll down to all sub Work Items.

Notes:

  • The child (sub-item) Permissions field does not display the user/group/profile, however the permission is active.
  • When granted on the project's sub-work item, and System Setting 3.2 Enhanced permissions project visibility is enabled, the user/group/profile can view the entire project. (If granted in the sub-system, the user will have access to view all levels above.)
  • When in System Setting 3.3 Display related items is Show name, the user/profile/group can view all related items (cases, predecessors, successors).
    Access is limited to name only without a being able to view content.
  • As current permissions allow - the user/profile/group can continue to view related files, resources, reviewers, groups, topics, and notes.
    360000731754_mceclip4.png

External user

The specific user has the same permissions as the internal user.

Users that are part of a profile or group –

  • When the user (in the profile/group) is assigned on the project level, the permissions roll down to the project sub-items, and the user can see the sub items as part of the detailed work plan view (the user will not see the sub-items in the relevant module).
  • In Global search, the user will see only the project (without access to the project’s sub-items). Therefore all searches should be done on the project level.
  • When in the Work Item module, the user will only see the project level.

Notes:

  • When you remove a user from the hammock, the user is removed from all related sub-items. This is unless the user/group has been added explicitly at a sub-item level.
  • A user with multiple permissions/role set (based on current profile or as part of a group in current profiles) gains access based on the highest permissions (editor over viewer).
  • Editor and Manager can manage the permission field on a Work Item if they are defined as editor/manager.

Filters

A user with Viewer/Editor permissions will view the Work Item under the Mine role in the module.

Two exceptions are:

  1. When the user has permissions based on a Group or Profile – the Work Item will not be in the Mine view (because the user does not have direct permissions for the specific item).
  2. When an internal user has Viewer permissions on a project – the user will see the Work Item on the project module under the Mine role, but this will not be visible in Milestones and Tasks.

Cases

The Permission Access Levels are in addition to current permissions and roles.

  • Upon creation, the Owner = case owner
  • When the Case owner is deleted, no Owner exists in the Permissions field

Customer

As there are no permissions for the Customer object, you can manage who can view or edit the Customer object, allowing more scalable security for large organizations.

Permissions apply to both Basic and Enhanced modes.

Default Permissions

Internal users and Technical account owner receive Editor permissions by default.

Creating a Customer

  • There is no Owner in the Permissions field
  • Internal users have Editor permissions

Updating the account owner

  • The account owner is Owner
  • Internal users have Editor permissions
  • When account owner is empty, there is no Owner in the Permissions field

Permission Access Levels Panel

The Permission Access levels panel displays who has access to the items, at which level, and how the user received access.

The panel is available for all work items, cases and customers for all users, groups and profiles with permissions to the item, whether by direct role (such as owner or project manager), granted permissions, or by inheritance from the parent item, or aggregated from a child item.

Each row represents a user, group or profile, its access level (Viewer or Editor) and whether it was granted directly or inherited from another item.

perm.png

The Permission Access Levels panel can be added as a related item in the Profile settings.

2018-02-22_11-18-54.jpg

Access Level displays the actual access level the user, group or profile has, and not necessarily what was granted directly for this item.

  • A user who was granted viewer permissions on a project, while his group was granted Editor, will be displayed as Editor in the Access Level field, and as Granted = No, in the Granted field.
  • On Work Items:
    • Owner, Project Manager, Managers - will be displayed as Editors
    • Reviewers - will be displayed as Viewers
    • Resource - will be displayed as a Partial Editor on task and milestone and as a Viewer on a Project
    • Resource Manager - will be displayed as an Editor if managed users (with Primary set on the Resourcing Group) are assigned as a resource to the Work Item
  • On Cases:
    • All members in the case lifecycle - will be displayed as Editors
    • Team member and reviewers - will be displayed as Viewers
  • On Customers:
    • Account owner and technical account owner - will be displayed as Editors

Advanced Configuration Options

Using AdaptiveWork's Configurations, you can add or remove permission access levels for work items, cases and customers, to users, groups or profiles based on business rules. This is achieved using the Permissions Definition link when creating custom actions and workflows.

Examples include:

  • Add Profile as viewer on project
  • Add specific group as editor based on project type

It is also possible to copy permission access levels between related objects such as from a customer to its related projects.

Example

In the following example we will explain how to assign editor permissions for the Group A user group on newly created or edited projects that have the Development project type.

  1. Go to Settings > Configure. Select the Project Work Item from the main navigation panel.

    360001321873_mceclip1.png
  2. Click Create New > Workflow.
  3. Enter the name of the rule and fill in the optional fields.
  4. For Set Time Run, select Every time a record is created or edited.
  5. For Set Evaluation Criteria, select Always run.

    360001321893_mceclip2.png
  6. In Set Actions, select Conditional Action List.
  7. Enter the Project Type (available in the Fields tab of the Formula Editor) and the name of the project type, like this:
    $ProjectType = 'Development'

    360001337974_mceclip3.png
  8. Click Add Another Action to add a new subsection of Set Action, and select New Item. Run the rule on the CurrentObject.
  9. From the list of objects and links, select Permission Definitions.

    360001337994_mceclip4.png
  10. In the $Entity field, enter the current object (available in the Functions tab of the Formula Editor): CurrentObject()

    360001321973_mceclip5.png
  11. In the $Resource field, enter the name of the user group, in our example, ‘Group A’.

    360001338014_mceclip6.png
  12. Click Another Field... > Access Level.
  13. In the $Role field, enter the permission type. Open the Formula Editor and from the Functions tab, select PermissionsRole. Replace role with the 'editor' or 'viewer', for example: PermissionsRole('editor')

    360001869174_mceclip0.png
  14. Click Save. Enable the rule.
  15. Test the above procedure by creating a project of type Development, and verify that members of Group A have editor permissions.

Notes:

  • Owner and virtual system groups such as admins, financial user, super users (when they are in their default role - viewer) cannot be added, deleted or copied using the configuration engine.
  • If a user, group or profile already has a link to the object, as specific role (Viewer or Editor), it cannot be edited to a different role. You will need to delete and add again with the new role.
  • You cannot edit definitions from the Permissions field. For example:
    • User A and User B are defined as viewers for project X
    • Then they are copied to a related risk - Risk has User A and User B as viewers
    • Add User C and remove User B
    • Unless there is a workflow rule that handles the deletion as well, this action will cause the related risk to include User A, User B and User C

Best Practices

  1. For executives, who mainly view items in AdaptiveWork - create a group or a profile of all relevant users, and assign this group/profile using workflow rules to all relevant work items, cases, customers, views or reports they need to view. There is no need to add them individually as reviewers.
  2. In case a group of users needs to be able to edit a Case or Work Item, and they are not managers of this Case/Work Item, you can create a group with those team members and add it as ‘Editor’.
    If they are managers on this Case/Work Item, once done, remove them from the Manager field.
  3. Group manager receives the group permissions, so there is no need to create a workflow rule to grant the manager permissions in addition to the group access level.
  4. User, group and profiles granted permissions will not be added as followers to the item. In case the users need to receive notifications from the item, add them as reviewers, and not in the Permissions field.

See also Extended Permissions for External Users in User Groups