- Contents
Permissions and Policies
Permissions grant users the authority to use program features and policies define the limitations of permissions. For example, you can set a permission to allow a user to add a post-dated check (PDC) transaction for an Automated Clearing House (ACH) payment. You can then set a policy indicating that the user cannot add transactions that are less than $20.
It's possible for the system to apply permissions and policies differently, based on the user or other criteria. The system uses a tier (scope) method to create permission and policy layers. So, permissions and policies applied at the base (system) level apply to other scopes, unless an administrator modifies the particular permission or policy. For example, a system level permission applies to all roles, unless an administrator customizes it for the role. Likewise, permissions applied at the role level apply to all users assigned to the role, unless an administrator customizes the permission for an individual user.
Scopes
There are 10 scopes in the permission/policy structure, broken into four categories (system, user, desk, and customer). These scopes create a hierarchical tree that extends back to the system level. Following is a diagram that shows each scope within its hierarchical structure.
Scopes available for each permission vary. The system determines which permissions to use by following hierarchy lines. For example, if a permission doesn't apply at the user scope, the system checks the role scope. If it doesn't apply at the role scope, the system checks the system scope. It's also possible to check permissions for both a specific user and a specific client. For example, if the user can add post-dated checks, but the client on the account does not permit post-dated checks, the user cannot add post-dated checks for that client.
The system checks branch permissions based on the user's assigned branch, along with the branch permissions for the user's assigned desk. The system merges these permissions and their settings when all of the following occurs:
-
An administrator assigns the user to a desk and a branch not associated to that desk.
-
An administrator configures the same permission for the user's branch and the desk's branch.
Policies take the permissions one step further. For example, the user-level and client-level permissions allow post-dated checks. At the user level, the permission stipulates that the minimum check amount is $5.00 and the maximum number of days that a user can post-date a check is 30. The permission understands that with the minimum amount a higher number is more restrictive, while with the maximum number of days the lower amount is more restrictive. The system considers this logic when creating the intersection for the effective permission. The user can add a post-dated check that is at least $15.00 and within 30 days (unless the administrator doesn't configure the user to observe client rules).
These scenarios can become complicated. To determine the exact policy for the user and customer combination, run the Resultant Set of Policies Wizard.
Permission categories
The system groups permissions into categories. Some permissions have policies associated to them. For more information about a permission and its policies, see the permission topic.
Related Topics
Permissions and Policies Editor