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. Then, click the 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|
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.
- Click the link.
- 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.
- Click the button.
- Click .
- Click .
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.
- If the permission constraints are of different types (e.g., an OU constraint and a Provider constraint), then the constraints act as AND statements.
To add permission specific constraints:
- Click the Add Constraint icon next to the constraint.
- 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.
- Click the button.
- Click .
- Click .
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."
- 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.