Security barriers allow admins (who have the Security Barriers - Edit permission) to configure an organisation's security policies. Once in place, they effectively lock down security assignments and remove most opportunities for human error. Put another way, security barriers are used to allow a user or team to hold a specific role, or disallow a user or team from holding a specific role.

Examples of where security barriers are used include the creation of policies where:

1. Only specific internal teams or users can see a particular matter.
2. Only certain external users can see a particular matter.
3. Only internal people can be members of a particular team.
4. Only certain people from a parent matter can be the payee on a payment or offer.
5. Allow or restrict certain people/roles/teams as authorised to perform an approval.

Security barriers are configured:

1. Either globally or for a work type instance and its descendants.
2. For given roles, including those of its descendants.
3. Specifying either the superset of users, as defined by teams, roles, individual users, or parent roles that can play a specific role on a work item, or the inverse, those that cannot play a role.

Since these rules are hierarchical, you can specify them at child levels. For example, I can define a rule at contract level which applies to its child matters and then further specialise this at matter level.

A common use case for security barriers is to combine them with roles that are assigned via the hierarchy. For example, you will often create a security barrier on a Statement of Work role to stop accidental assignment of people to a client's matters. Another common use of barriers is to allow or disallow a user from being an approver for a particular work type instance.

Configuring Security Barriers

To configure security barriers globally or for a work type instance and its descendants, browse to [ShareDo]/admin/security-barriers-all or through the launchpad: Open Admin > Security > Security Barriers - All.

 To add a barrier:

1. Click the + sign at the top right to add a barrier.
2. Select a rule: Only Allow or Only Deny.
3. Select a scope for the barrier: Global or Case. For the Global scope, select the work types for which the barrier will be available. For the Case scope, search for and select the work type instance for which the barrier will be available.
4. Select the role that can play a specific role on a work type/instance. Then click Add.

The Security Barriers - Specify Access blade opens.

Select the Type and Restriction, then click Save to continue. A summary of the barrier is shown. You can either close it or add another barrier.

Configuring a Work Type to be able to use Security Barriers

1. Open the Work Type Modeller, browse to the work type, then click Open Legacy type Features. Do this for each work type that you want to be able to apply barriers to. 
   
2. Tick the Security Barriers enabled box. 
    
   

   If you want to be able to bulk assign security barriers, ensure the global feature Bulk Assign Security Barriers is enabled.

    

Applying a barrier to an individual matter

1. Create the security barrier team. This needs to include all users who should be able to access the matter (ensure the current user is also in the team).
2. Add the team to the matter in the Contributor role and remove all other contributors/entities.
3. Go to the More menu in the top right-hand corner and select Security Barriers. 
   
   Add in a new barrier, select Allow and Contributor, Reader, plus any other roles that have permission on the matter.
    
   Then add in the barrier team.
   1. Contributor
   2. Reader
   3. Matter Owner
   4. Matter Partner
   5. Client Access
   6. Creator
4. Remove your user from the barrier team.

Considerations

You must take care with security barrier configuration, or you might end up having a team set up whose members are allowed to take ownership of a case but also be configured as part of an Approval Model to not be allowed to take ownership of the case, for example.