Restricting Access to Cases and Links on Cases

LegalServer provides several ways to restrict access to cases and links on cases.

In this Article:

• Restricted Offices/Programs
• Restrict Selection Options based on User's Office
• Restrict Access to Cases Assigned to Certain Grants
• Case Restrictions Field
• Case Exclusions Field
• Exclude from Search Results Field
• User Role Restrictions
• User Role Permissions on Links (Dynamic Processes)
• Permission Block
• Reports
• Search Results
• API Results

Restricted Offices/Programs

Administrators can restrict access to groups of cases based on office and/or program on the Admin > Restricted Programs/Offices page. A case that is assigned to a restricted office or program can only be viewed by:

1. Users who are assigned to that office or program (in the user's profile)
2. Users who are specifically assigned to the case (regardless of that user's office or program)
3. Users whose role has the "View All Cases" permission (typically administrators); this permission may alternately be labeled "Cases: View All".

Administrators can also set the Restriction Type to Intake, Assignment, or Both. This determines the assignments that are checked when determining if a user can view a case. "Intake" applies the restriction based on the intake assignment while the matter is an incomplete intake. "Assignment" applies the restriction based on the primary assignment after the matter is set to a pending or open case.

A "user's office" and "user's program" includes any Additional Offices and Additional Programs set for the user. Example: A faculty member's Program is set to "Criminal Defense", but they also have "Civil Appeals" selected as an additional program. That faculty member could see cases assigned to either program.

A user must pass all office and program tests to view a case (or meet one of the exceptions in 2 or 3).

Administrators may want to remove the "Edit Own Office" and "Edit Own Program" permissions from most user roles to prevent a user from bypassing an office restriction by changing their office and/or program.

Sites using dynamic user forms and processes can prevent users from changing both office and program in the usual ways. For example, by removing permission on a dynamic Edit System Information process.

Restrict Selection Options based on User's Office

In beta testing (June 2023), there is an option to restrict some dropdown selectors by office (colloquially: office restricted lookups, though they are not always technically lookups). In process settings, you'll notice options to limit: User Select, Program Select, Judge Select, Contact Select and/or Case Contact Select by Current User's Office. You can associate programs with offices in your offices list. You can associate contacts with offices by adding the "Related Offices" field to your contact create and edit forms.

Restrict Access to Cases Assigned to Certain Grants

Administrators can restrict access to groups of cases based on the grant/funding code the cases are assigned to. Then only allow certain users to view cases assigned to those restricted grants/funding codes.

This function requires two steps. First, a site administrator must select which funding codes should be restricted. This selection is made under Admin>Restricted Programs/Offices on the multiselect list at the bottom of the page. If you are restricting more funding codes than you are leaving unrestricted, consider using the Invert/Flip Selection box to save clicks.

Next, a site administrator must set which users are allowed to view each restricted funding code. This requires having the "Funding Code Restricted Cases Allowed to View" block on a user form. The block displays a multi-select list of grants. If one or more grants are selected for a user, that user will be able to view cases assigned to that restricted grant. Users that do not have a restricted grant selected in this block will not be allowed to view cases under restricted funding codes- clicking on the case number for a case assigned to such a grant will tell the user "You are not allowed to view this profile".

Administrators can add the Funding Code Restricted Cases Allowed to View to their Create New User process for added convenience.

To add a funding code to the list of restricted funding codes when creating a new grant, administrators can add the Restrict Viewing of Cases with this Funding Code field to their Add New Grant process.

Case Restrictions Field

Use this field to restrict access to cases on a case-by-case basis to any combination of: Currently Assigned, Current Office, or Current Program.

Anyone with a user role that has the "View All Cases" permission can access the case regardless of any restriction set with this field.

A common use of this field is with an auxiliary process and form. The auxiliary process, often called "Case Access Restrictions", is added to the Actions menu. Administrators often set the role permissions on the auxiliary process so only users assigned to certain roles will see the Actions menu link. The auxiliary form contains the Case Restrictions field.

Another way to use the Case Restrictions field is to place it on an intake form. If the intake becomes a case, the case keeps the restriction created during the intake. Administrators can hide this field on an intake form, choose one of the 3 options to be set, and restrict access to any cases created with that intake process.

Case Exclusions Field

Use this field to exclude selected users from accessing cases on a case-by-case basis.

Anyone with a user role that has the "View All Cases" permission can access the case even if they are selected. A user being assigned to a case does not override the exclusion. Like the Case Restrictions field, administrators would typically put this field on an auxiliary form and create an auxiliary process that only the Administrator role has permission to use.

Exclude from Search Results Field

Setting this field to Yes on a case will prevent the case from showing up in searches on the client's name. Like the Case Restrictions and Case Exclusions fields above, this field is typically placed on an auxiliary form, behind an auxiliary process that is limited to Administrators or a select set of user roles.

Caveat one: A search by Case ID will still display the case, assuming the person searching has permission to view the case.

Caveat two: This does not hide a case on a client profile page. For example, assume Jane Smith has two associated cases (Case A and Case B). Case B has this field set to Yes. Case B will not show up in a search for Jane Smith, but Case A will. If you click on her name to view her client profile, both Case A and Case B will be listed.

User Role Restrictions

Several user role permissions can affect the links that are available on cases. See User Roles and Permissions for more information.

The Pro Bono Restricted Access Role is designed to allow users to only see and work on cases they are specifically assigned to.

User Role Permissions on Links (Dynamic Processes)

Dynamic processes generally place links on specific pages. Each dynamic process can be restricted by user role. For example, an Edit Closing Information link may be restricted to only the Administrator role. See Process Management for more information.

Permission Block

Controlling permissions by user role on dynamic processes generally provides more flexibility than this block. This block prevents information on a form from being saved unless the user has at least one of the permissions selected in the block configuration. It does not prevent a user from seeing the form. The list of permissions is from the User Roles Permissions page.

Reports

The above case restrictions do not limit what users can see in reports. If a user clicks on a case number in a report, case restrictions will apply and may deny permission to view that case, but any information in report columns can be seen.

Each report can block viewing it by User Role and there are ways to limit report results based on the user running the report.

Search Results

The above case restrictions do not limit what users can see in search results. If a user clicks on a case number in search results, case restrictions will apply and may deny permission to view that case, but any information in the search results columns can be seen.

Administrators can restrict People and Conflict Search results to the cases where the intake or assigned office matches the user's office or additional offices. 

You must submit a ticket (Help menu > Support Request) from your site to enable these search restriction features.

Once enabled, the People Search settings are on the Search tab of the Admin > Top Level Navigation Bar/Search page. Administrators can also set restrictions in the Conflict Search Results and Adverse Party blocks. 

API Results

In the Core v2 API there are two new user role Permissions that interact here:

• API View Cases restricted to Assigned Users
• API View Cases excluded from Search

If the first permission is not enabled, then cases with Case Restrictions set to Currently Assigned cannot be accessed. The GET and PATCH endpoints will return a 403 error and the Search GET endpoint will exclude those cases.

If the second permission is not enabled, then cases with Exclude from Search Results set to True will be similarly inaccessible.