- Contents
Liquid Latitude Help
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 Latitude to apply permissions and policies differently, based on the user or other criteria. Latitude 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 and policy. For example, a system-level permission applies to all roles, unless an administrator customizes the permission 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 permissions and policy structure, split into 4 categories: system, user, desk, and client. These scopes create a hierarchical tree that extends back to the system level. The following diagram shows each scope within its hierarchical structure.
Scopes available for each permission vary. Latitude determines which permissions to use by following hierarchy lines. For example, if a permission doesn't apply at the user scope, Latitude checks the role scope. If it doesn't apply at the role scope, Latitude checks the system scope. It's also possible to check permissions for both a particular user and a particular 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 particular client.
Latitude checks branch permissions based on the user's assigned branch, along with the branch permissions for the user's assigned desk. Latitude 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. Latitude 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).