Groups & Access Control

Contract Lucidity uses a combination of user roles and project-level access grants to control who can see and interact with each project. Groups let you manage access for teams of users in bulk.

How Access Filtering Works

Key rule

Admins see everything. The access control system only applies to users with the user role.

Access Levels

When granting access to a project, you specify an access level:

Access Level	Can View	Can Upload / Edit	Can Manage Access
viewer	Yes	No	No
editor	Yes	Yes	No
admin	Yes	Yes	Yes

The default access level when granting access is editor.

Groups

Groups are named collections of users. They simplify access management -- instead of granting project access to each user individually, grant it to a group and add users to that group.

Creating a Group

Navigate to Settings > Groups and click Add Group.

Field	Required	Description
Name	Yes	Unique group name (e.g., Legal Team, External Counsel)
Description	No	Optional description of the group's purpose

Managing Group Members

From the group detail view:

• Add member: Select a user from the user list
• Remove member: Click the remove button next to a member

A user can belong to multiple groups. Group membership is tracked in the user_groups table with a timestamp and the admin who added them.

Deleting a Group

Deleting a group cascades to:

• All user_groups memberships for that group (users are removed from the group)
• All project_access grants for that group (project access via this group is revoked)

warning

Deleting a group immediately revokes all project access granted through that group. Affected users with the user role will lose access to those projects unless they also have a direct user-level grant.

SCIM-Provisioned Groups

When SCIM provisioning is configured (see SSO & SCIM Setup), your identity provider can automatically push groups to Contract Lucidity. SCIM-provisioned groups:

• Are created with the group name (displayName) from the IdP
• Have a description noting they were provisioned via SCIM (e.g., "Provisioned via SCIM from Azure AD")
• Have their membership managed automatically by the IdP -- members are added and removed as the IdP syncs
• Can still be used for project access grants just like manually created groups

How SCIM Group Sync Works

tip

After a SCIM-provisioned group is created in CL, an admin can grant that group access to projects. From then on, any user the IdP adds to the group in the IdP will automatically gain access to those projects in CL.

SCIM Groups vs Manual Groups

Aspect	Manual Group	SCIM-Provisioned Group
Created by	Admin via CL UI or API	Identity provider via SCIM
Membership managed by	Admin via CL UI	Identity provider (automatic sync)
Project access	Granted by admin in CL	Granted by admin in CL (same as manual)
Can be renamed	Yes, by admin	Yes, by IdP via SCIM (or by admin in CL, but IdP may overwrite)
Can be deleted	Yes, by admin	Yes, by IdP via SCIM (or by admin in CL)

warning

If you manually edit the membership of a SCIM-provisioned group in CL, the next SCIM sync from the IdP may overwrite your changes. Manage membership of SCIM-provisioned groups through the IdP only.

Assigning Project Access

Project access can be granted to either an individual user or a group. Each grant is a single record specifying one user OR one group (not both).

Granting Access

From a project's settings or from Settings > Projects, select a project and use the access panel to:

1. Choose User or Group
2. Select the user or group
3. Set the access level (viewer, editor, or admin)
4. Save

Searching for Users and Groups

For large organizations with many users and groups, the access modal provides paginated search:

• User search: Type a name or email to search across all users. Results are paginated (20 per page by default, up to 100).
• Group search: Type a group name to search. Results are paginated with the same limits.

The search is case-insensitive and matches against the user's email, first name, or last name (for users), or the group name (for groups).

Revoking Access

Remove an access grant by clicking the revoke/delete button next to it. The user or group will immediately lose access to that project (unless they have another grant through a different path).

Access Resolution

A user's effective access to a project is determined by the highest access level across all their grants:

Deny Permissions

In addition to allow grants (viewer, editor, admin), groups and users can have deny permissions on projects. A deny permission blocks all access to a project, regardless of any allow grants the user may have through other paths.

How Deny Permissions Work

Deny permissions override all allow permissions. If a user has an allow grant at admin level through one group and a deny through another group, the result is deny -- the user cannot access the project.

This follows a hybrid conflict resolution model:

• Among allow grants: The most permissive level wins (e.g., viewer + editor = editor)
• Deny vs allow: Any deny overrides all allows, regardless of source

Setting Deny Permissions

From a project's access panel, when granting access to a user or group, select Deny instead of an access level. The deny grant appears in the access list with a visual indicator.

Permission Scenarios

Scenario 1: Multiple group allows

• User is in "Legal Team" (editor on Project A) and "Senior Staff" (admin on Project A)
• Result: admin access (most permissive allow wins)

Scenario 2: Allow + group deny

• User has direct editor grant on Project A
• User is in "Restricted" group which has a deny on Project A
• Result: denied (group deny overrides user allow)

Scenario 3: Ethical wall + admin role

• User has admin role (normally sees all projects)
• An ethical wall screens the user from Project A
• Result: denied (ethical walls override the admin role)

For the full 6-step permission resolution hierarchy, see Security > Permission Resolution Hierarchy.

Ethical Walls and Group Members

Ethical walls can reference groups directly. When a group is added to an ethical wall, all members of that group are screened from the wall's covered projects. This includes SCIM-provisioned groups -- if your IdP adds a user to a group that is on an ethical wall, that user is automatically screened.

For full details on ethical walls, see Ethical Walls (Information Barriers).

SSO Default Group

When configuring SSO (see Single Sign-On), you can set a default group. New users created automatically via SSO login will be added to this group, giving them immediate access to any projects the group has been granted.

API Reference

All endpoints require admin authentication.

Groups

Method	Endpoint	Description
GET	/api/admin/groups	List all groups with member counts
GET	/api/admin/groups/search	Search groups by name (paginated)
POST	/api/admin/groups	Create a new group
PATCH	/api/admin/groups/{group_id}	Update group name or description
DELETE	/api/admin/groups/{group_id}	Delete a group (cascades)
GET	/api/admin/groups/{group_id}/members	List group members
POST	/api/admin/groups/{group_id}/members	Add a user to a group
DELETE	/api/admin/groups/{group_id}/members/{user_id}	Remove a user from a group

Project Access

Method	Endpoint	Description
GET	/api/admin/projects/{project_id}/access	List all access grants for a project
POST	/api/admin/projects/{project_id}/access	Grant a user or group access to a project
DELETE	/api/admin/projects/{project_id}/access/{access_id}	Revoke an access grant

Search Endpoints (for API Integrations)

These paginated search endpoints are useful for building custom integrations or automation on top of CL:

Method	Endpoint	Parameters	Description
GET	/api/admin/users/search	q (search term), limit (max 100), offset	Search users by email, first name, or last name
GET	/api/admin/groups/search	q (search term), limit (max 100), offset	Search groups by name

Both endpoints return a paginated response with a total count field for building pagination UIs.