Gaurav Diwanji
ServiceNow Employee
ServiceNow Employee

Legal Service Delivery (LSD) application in ServiceNow is a scoped application – which means that customers can protect sensitive data by assigning users application specific admin roles.

 

Based on product documentation, setting up application administration allows customers to:

  • Prevent unauthorized users from accessing sensitive data such as financial records or personally identifiable information.
  • Restrict who can assign application-specific roles such as the administrator and designated developers for the application.
  • Prevent users with the system-level admin role from:
    • Assigning themselves a protected application role.
    • Assigning themselves to a group containing a protected application role.
    • Bypassing existing access controls to a protected application by creating access controls.
    • Changing the password of users who have a protected application role.
    • Impersonating a user who has a protected application role, unless the developer or administrator also has that role.
    • Inheriting a protected application role.
    • Overriding existing access controls to a protected application.
    • Running scripts that access protected application records.

 

Out of the box, the admin role contains application admin roles for all the LSD apps that have been installed.

 

The following is an example of how one would go about accomplishing removing these LSD admin roles from IT Administrators to ensure only designated members of the Legal team can view Legal data:

 

Note: The steps below are for instructional purposes only and please work with your implementation teams and refer to the product documentation for additional assurances on security. A reference to a similar exercise in the HR application can be found here.

 

  • As an admin user, navigate to System Security > Roles. Select admin role.

GauravDiwanji_0-1728507540382.png

 

  • In the ‘Contains Roles’ related list, filter for Legal roles (starting with ‘sn_lg’).

Depending on the LSD applications installed, you may see the list of LSD admin roles contained within the IT admin role.

GauravDiwanji_1-1728507540406.png

  • In this example, let’s say we want to ensure the IT administrators do not access data related to Legal Request application, governed by the sn_lg_ops.request_admin  role.

 

  • An important step is to explicitly assign yourself, or other designated users the sn_lg_ops.request_admin role. This is to ensure we do not get locked out of this role.

Note: The LSD application has scoped admin roles specific to managing requests, matters (sn_lg_matter.matter_admin), as well as admins for all practice area applications that can be assigned out as needed.

Alternatively, you can also assign the sn_lg_ops.legal_admin role which contains all LSD admin roles if you have identified users who will be the administrators for all Legal apps in the organization.

 

GauravDiwanji_2-1728507540427.png

  • Once we have ensured we will not get locked out of the role we are about to remove, navigate to the admin role as detailed previously.

While in the Global Scope, click on Edit button in the Contains Roles related list and remove the ‘sn_lg_ops.request_admin’ from this list.

 

GauravDiwanji_3-1728507540451.png

 

GauravDiwanji_4-1728507540468.png

 

  • Check the related list ‘Contains Roles’ again to ensure this role has been removed.
  • Moving forward, only users who have been granted the the ‘sn_lg_ops.request_admin’ role (or other specific Legal roles) explicitly have access to Legal Requests data, including associated attachments and emails. The system administrator is no longer able to access this information.
  • The same steps can be repeated for other applications as needed.

 

Which data elements are protected from access by IT admins after carrying out the steps above?

 

Legal Requests, Legal Matters, Legal task data: Completely secure from IT admin access.

 

Outbound Emails on Legal Requests/ Matters: Completely secure from IT admin access if glide.enforce_security_scope.sn_lg_ops , glide.enforce_security_scope.sn_lg_matter are set to true.

 

Attachments on Legal Requests/ Matters: Completely secure from IT admin access if glide.enforce_security_scope.sn_lg_ops , glide.enforce_security_scope.sn_lg_matter are set to true.

 

Inbound Emails: IT admins can momentarily access since Legal does not have a dedicated mailbox like HR has as documented here so system cannot distinguish emails meant for Legal. The inbound email will be accessible to IT admins until the Inbound email action executes.            

 

Attachments on Sys Approval Tables related to Legal: In the rare case that there are attachments on the approval record for Legal requests or matters, IT admins will be able to access these. If this scenario applies to you, in order to alleviate this, updates are needed on Global ACLs to uncheck 'Admin Override'.  Platform admins may still be able to edit these Global ACLs and revert the changes to get access to these attachments.

 

Please note that this use case is relevant only if we have a business case where we expect attachments on the approval records for Legal.

 

Sys Approvals related to Legal: IT admins can access approval records related to Legal requests and matters. Script update to Global ACLs proposed as a fix. Platform admins may still be able to edit these Global ACLs and revert the code to get access to approvals.

 

Note: Please ensure glide.approvals.restrict_by_record is set to true to ensure only users with access to the target record can view the approval record.

 

Creating scoped ACLs does not help secure sysapproval_approver and related attachments, as the platform will not honor them over Global ACLs as it does for attachments and email tables.

 

 

In conclusion, please note that this blog is a general overview of the Legal Service Delivery module's out-of-the-box security configuration. Behavior may vary slightly based on additional ACLs, properties, etc. that may be configured in your platform. We encourage customers to carry out testing before loading sensitive production data.