Skip Ribbon Commands
Skip to main content
In ContactsLaw, permissions determine the access rights and security options for each member. These security features are highly granular and a number of advanced concepts are supported.

Classes of permissions

The types of permissions that can be controlled are broken into two main areas; access levels and activities.
 
Activity permissions provide granular control over each activity in the system. They can be used to control which members have access to the various steps in each workflow. These should be thought of in terms of responsibility; permission to any given step should only be assigned if the member(s) have primary responsibility for completing the process in question (see "Permissions and member relationships" below). Access to whole activities can be toggled as well.
 
Access levels represent permissions that apply outside of the workflow system, or after the workflow for a given record as been completed. They determine:
  • Whether records (e.g. contacts, files, documents, etc) can be viewed or edited, or if they are blocked completely.
  • Access to specific parts of the program (e.g. areas under The Practice tab).
  • Management policies that differ between members.
  • The dollar value limits on different types of transactions that members can authorise.
Some permissions are made up of on/off toggles (represented as checkboxes), while others are set by choosing a pre-defined level (represented as radio buttons).

Inheritance

For the two main categories above, ContactsLaw operates on the principle of least permission; where access to features is denied unless otherwise configured. However, it is not necessary to set the full list of permissions for each member. It is considered best practice to first configure a sensible set of permissions for each member group. All members within the group will inherit permissions for a given class unless overridden. Likewise, changes to permissions for a group will directly affect all members unless specific overriding permissions are set for those members.
 
If a member belongs to multiple groups with the 'permissions' indicator, their default permissions will be equal to the union of the sets provided by their group.

Permissions and member relationships

Member relationships influence the permissions system as well. Supervising members gain the permissions of their subordinate staff, but not the notion of primary responsibility; this means that members with secondary/incidental responsibility for any given activity are still granted permission to perform the activity, but do not receive tasks and notifications relating to the activity. It is especially important to be conservative when assigning permissions if these benefits are to be realised.
 
Although members in a collaboration relationship do not gain each other's permission sets, they will be granted access to their peers' task lists, activities, files and so on.

Other types of permissions

See also