The May 2022 Nebula release incorporated numerous features that will help case management teams efficiently analyze, review, and produce meaningful case data, while controlling access like never before. At the heart of this release is the latest enhancement to the already robust Nebula User Management system: Object Security.

Object Security enables users and administrators to secure or limit access to individual objects in a Nebula project. This system also allows users to control objects they create by making them private, or conversely, by making them public. Object types that are supported by the initial feature rollout:

• Coding Forms 
• Fields (work-product fields only)
• Keyword Categories - Cull & Review 
• Lists - Cull & Review 
• Markup Sets 
• Productions
• Search Folders/Searches - Cull & Review 
• Workflows

Background on Nebula User Management

Introduced in March 2021, the Nebula User Management system brings powerful access controls to administrators that are tasked with assigning rights to different users of the platform, on a project-by-project basis. Within Nebula User Management, every active Nebula user is associated with at least one Group, and every active Group is assigned to at least one Nebula “project” (eg. a Repository and/or specific Matters). The User Group “assignment” is where administrators define the level of access these Groups have – both by default when first assigned to a project, and also customized as-needed within each assignment.

Customizing project-level access controls (often referred to as “permissions”) is an action performed by administrators from the Admin interface, outside of the project. The UI for this is intuitively designed to loosely mimic the Nebula page layout and comes with time-saving features such as templates, filtering, and auto-select of inferred permissions. Generally speaking, each page in Nebula, and each feature/function, is access controlled by some corresponding permission. Some permissions are binary and explicit to specific functions, while others are incremental with a View | Edit | Delete | Create framework (aka “CRUD”).

Object Security

In the permissions UI, administrators will now notice a “Secure” permission for certain items in the Group’s permissions settings. These are the items listed above that – with the introduction of Object Security – are now able to be individually securable from within a Nebula project. Unlike project-level permissions that are typically only handled by administrators, object-level permissions can be customized by normal users that have the necessary “Secure” permission for that object-type. As noted above, even users without the “Secure” permission can take advantage of Object Security to control whether an object they created is private to them, or public.

Users can access an object’s security from most listing or detail pages where the object is viewable with a “3dot” menu. From this menu, selecting “Object Security” will launch the settings dialog.

Setting “Custom” permissions or changing access on an object you don’t own requires the “Secure” permission for that object-type. The “Custom” setting behaves slightly different depending what type of user is doing the customization. For administrators, Object Security allows permission specificity for every Group that is assigned to the project. For normal users, Object Security allows Group-level customization only for Groups that are part of the same Firm as the user (external Firm access is instead controlled at the Firm-level). Note that an object is completely restricted from all Groups in a Firm unless the “Share” toggle is enabled for that Firm.

It is important to note that object-level permissions will never supersede the Group's project-level permissions. As such, administrators and managers do not need to be concerned about inadvertent disclosure due to a user tweaking an object’s permissions. Further, object-level permissions can be intentionally set very high in anticipation of an administrator subsequently elevating a Group’s project-level permission for that object-type. Project-level permissions that are beyond a Group’s access are represented in the Object Security UI with an asterisk.

Because external Groups are hidden from normal users (and Firm Admins), permissions must be set for external Firms at the Firm-level. This is accomplished through the “Maximum Access Level” selector that appears when an object is shared. This not only allows Groups within an external Firm to have limited access to an object, it also ensures that users from different Firms are not elevating permissions for that object beyond what that Firm’s manager or administrator have previously dictated.

Conclusion

Object Security adds a new, powerful layer of access controls for Nebula User Management. It brings extremely precise customization to users that are tasked with keeping project work product within certain Groups. It’s also a super convenient way for all users to manage objects they own, and even manage other objects on behalf of their Firm (given the permissions to do so). In future releases, we will be adding more items to the list of support object-types, such as Predictive Coding projects, AutoRedact patterns, and Doc List Views.