System Role Security General Rules

If the standard roles included with the system do not meet your needs, you can add new roles that better reflect the work flow within your organization. If you add new system roles, you should review these general rules and keep them in mind as you proceed.

• You should set up your system roles in layers. Create the most basic, lowest level layer first. Build up from there, but for higher levels of access and permissions, don’t include the permissions in the lower levels. Simply include the application users in the system role for the higher level layer as well as in the system role for the lower level layer. The user will get access for the items in each roles. This way, when a new feature is added, you can make the change in the lowest level needed only. Users in that role and above will gain access.

• Deny always take precedence over grant or unspecified rights.

• If a user belongs to multiple roles and one is granted access to a feature while another is denied access, the user does not have access to that feature. If one role has access and the other is unspecified, the user does have access.

• Tasks are really navigational elements, so they are not secured in the same way as actual feature permissions. If no features within a particular task are granted for a role, then even if that task is specifically granted to the role, it will not be visible (and directly accessible) to the users in that role.

• Tasks can either be granted or not specified. There is no deny option for tasks.

• When you grant permissions for ad-hoc queries to a role, you must grant rights to the root query view for the feature in the tree view. The user will not be able to create new ad-hoc queries without access to the root query view, such as constituents or mailings.

• Because dashboards are driven by datalists, when a dashboard feature is granted for a role, the datalists that populate that dashboard are implicitly granted. Therefore when you grant rights to a dashboard, it is not necessary to also grant rights to the datalist(s) used by the dashboard.

• Constituent security groups can be used to limit access to certain constituents for a role. For example, you could create a “Major Donors” constituent group and limit access to that group to only selected roles. Similarly, sites can be used to limit access to certain record types such as events and appeals.