Security:Scope

From ContactsLaw Documentation
Revision as of 12:41, 6 November 2025 by Bradley Smith (talk | contribs) (Created page with "{{Prealpha}} '''Security scopes''' provide a way of assigning different permissions to certain aspects of a matter, such as fields. This caters for situations where access to sensitive data needs to be restricted without affecting more general aspects of the matter. They are defined at the workgroup level. Matters in child workgroups inherit security scopes from parent workgroup(s). You can set permissions on each security scope...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
The information in this section relates to a pre-release version of ContactsLaw and is not representative of the final product.

Security scopes provide a way of assigning different permissions to certain aspects of a matter, such as fields. This caters for situations where access to sensitive data needs to be restricted without affecting more general aspects of the matter.

They are defined at the workgroup level. Matters in child workgroups inherit security scopes from parent workgroup(s).

You can set permissions on each security scope within a matter; if not specified, a security scope inherits permissions from its definition on the workgroup. Permissions that apply to the matter more generally do not affect its security scopes; however, members who appear in the manager or supervisor roles are granted implicit permission to administer all aspects of the matter, including its security scopes.

Fields

Custom fields can be defined for a security scope, in much the same way as they can for a workgroup. Unlike fields defined on the workgroup, however, fields defined for a security scope cannot be marked as "required" and are never shown on the matter summary.

The values of these fields can be leveraged by document templates and processes, via security scope assets. The user must have permission to access any security scopes referenced in expressions/rules.