Security Role - Create - Step 3 - Constraints

Security Roles and Permissions allow system administrators to create a standard grouping of permissions that can be assigned to users, and these roles determine what individual users can access and do within the system. Security roles are important because they enable an organization to grant certain people access to certain data and also restrict access to certain data.

Managing Security Roles   Additional Information   Training and Troubleshooting Resources
   
  • Security Roles Feature Focus Playlist - In this playlist, you’ll find curated content specifically for security roles. Note: You must log in to the Success Center to access Playlists.
  • Knowledge Base - Review security role quick help and troubleshooting articles.

The Constraints page displays all constraints for each permission in the role. Constraints enable an organization to give permissions to users to see data or access certain functionality, but restrict them to a specific area or group of people. The following are possible reasons to constrain permissions in a role:

  • Allow certain people in the Sales division to see report data, but only for users who are in the Sales division or in a Sales position.
  • Allow the ability to assign learning, but restrict the permission to enroll only users in a particular OU or type of learning.

To create a security role, go to Admin > Tools > Core Functions > Security Role Administration. Then, click the Create New Role link.

PERMISSION NAME PERMISSION DESCRIPTION CATEGORY
Security Administration - General Constraints Grants access to apply general constraints to permissions when creating/editing a security role. This permission works in conjunction with the Security Administration - Manager permission. This is an administrator permission. Core Administration
Security Administration - Manage Grants ability to create, modify and constrain security roles within the portal, and assign users to those security roles. This permission can be constrained by OU, User's OU, User, and User Self and Subordinates. This is an administrator permission. Core Administration

Troubleshooting

For use cases that demonstrate how permission constraints are calculated when a user's permission constraints are merged between multiple roles or permissions, See Permission Constraint Calculation Use Cases.

General Constraints - Add

A general constraint can be added which will apply to all relevant permissions in that role. When a user is assigned a role, they are granted all the permissions within that role and the constraints that are related to those permissions. When a permission has more than one constraint, these constraints are considered OR statements.

  1. Click the Add General Constraint link.
  2. Select the constraint from the drop-down menu. For an OU selection, you can choose to include the subordinate OUs as well by selecting the Include Subordinates option.
  3. Click the Add button.
  4. Click Submit.
  5. Click Save.

Upon saving a new or edited role, the administrator is directed to the Security Role Administration page with the new or edited role displayed in the search results. This enables the administrator to conveniently perform additional operations on the role, such as adding or removing users.

Permission Specific Constraints - Add

A permission specific constraint can be added to any permission in a role. Permission specific constraints are helpful in the following scenarios:

  • When you want different constraints set for each permission.
  • When you want an organizational unit constraint set for an organizational unit other than the user's organizational unit (general constraint are restricted to the user's organizational unit).

When adding multiple constraints to a permission, the constraint behavior follows these rules:

  • If the permission constraints are of the same type, then the constraints act as OR statements.
  • If the permission constraints only contain OUs (Division, Position, Location, Cost Center, Grade, custom OU) and groups, then the constraints act as OR statements.
    • Note: For Reporting 2.0 permissions that begin with Reporting - Recruiting - Requisition, multiple constraints always act as AND statements.
  • If the permission constraints are of different types (e.g., an OU constraint and a Provider constraint), then the constraints work to complement each other. For example, User A has the “Assignment Tool - Standard” permission and it is constrained to Division A (OU constraint) and Provider ABC (Provider constraint). In this case, User A has permission to create standard learning assignments for users who belong to Division A and only for learning objects with the provider “Provider ABC.”

To add permission specific constraints:

  1. Click the Add Constraint icon next to the constraint.
  2. Select the constraint from the drop-down menu. Then, click the Select icon to select the appropriate organizational units. For an OU selection, you can choose to include the subordinate OUs as well by selecting the Include Subordinates option.
  3. Click the Done button.
  4. Click Submit.
  5. Click Save.

Permission Constraints Example

An administrator has permission to create email templates in the system, but is constrained to Division A. The administrator can create and set availability for emails only to users in Division A. In addition, the administrator can only view other email templates created by a user who exists within the administrator's constraints. So, if the administrator is restricted to Division A, then the administrator can only view email templates created by a user who is in Division A.

Permission Inherited from Child Role

If a role has inherited a permission from a child role, the administrator cannot add constraints to the inherited permission.

  • Any constraints that are added to the permission within the child role are not inherited by the permission within the parent role. Also, the Add Constraint icon is not available for the permission.
  • The following notification is displayed in the Constraints column to indicate that the administrator cannot constrain the inherited permission: "This permission is inherited from one or more child role and cannot be constrained."
  • If an inherited permission within the parent security role needs to be constrained, the permission should first be removed from the child role. The permission should then be directly added to the parent role with the applicable constraints. The permission can then be re-added to the child role.
  • If general constraints are applied to a security role that has inherited permissions, the general constraints are not applied to the inherited permissions.

If a permission exists in the parent role and is later added to the child role, then the permission can be constrained within the parent role.

If a permission does not have any applicable constraints, then the following notification is displayed in the Constraints column: "There are no constraints available for this permission."

Helpful Hints

  • If a user is in multiple roles with the same permission, but different constraints, the constraint that will apply will be determined when the user is added to a role in the Constraints to Existing Permissions section.
  • By default, some manager permissions are automatically constrained to Self and Subordinates while others are automatically constrained to Subordinates only. It is important to note that if any permission in the Manager security role is constrained to subordinates (e.g., Self and Subordinates, Subordinates), then this includes all direct and indirect subordinates and this cannot be changed. Applying the Direct Subordinates constraint to a permission in this role that is automatically constrained to subordinates DOES NOT result in the manager being constrained to direct subordinates only.

Security Security Security Security Security Security Security Security Security Security Security Security Security Security Security