Schema permissions are designed to align with higher-level Registry permissions, not override them; but they play an important role in deciding the access a user has to individual schemas. This article covers:
Schema permissions behavior
Registry permissions determine who can view and edit Registered entities, configurations, and settings. Schema permissions determine if users can interact with entity objects or modify a specific schema.
If there are overlapping permissions or access policies assigned to users, teams, and/or organizations, Benchling allows the most permissive access policy to that user or user group.
For example, if a team needs access to the Registry and permissions to create new entities for a specific schema, then their Registry access level would be Write and their schema level access policy would be Create.
Project-based schema permissions
Registry schemas can derive permissions from the Registry or Projects assigned in Registry Settings. Permissions default to Registry-based permissions, but entities might use Project-based permissions in specific scenarios.
To determine if a schema has Registry-based or Project-based permissions, view the schema in the Schema Access Policy.
To make schema permissions Project-based, tenant admins can contact Benchling Support for reconfiguration.
Schema access policy descriptions
Access policies determine the actions a user can take with individual permission types. For example, you might set an access policy allowing a user with Read permissions to edit existing schema descriptions. You can customize Registry access policies in Registry Settings. At this time, schema access policies cannot be modified.
The table below explains each schema action and what it controls.
Default schema access policies
You can grant the following permissions to users, teams, and organizations:
The table below displays the default actions users can perform at the schema level with these permissions. To configure schema permissions, visit Managing Schema Permissions.
*Registry schema objects might also depend on higher-level registry permissions.
Only organization owners can assign None permissions to collaborators. The organization owner cannot be removed. For example, an organization assigned None permissions is the same as not being listed as a schema collaborator.
If a user is not added as a collaborator on a schema and their higher-level permissions allow, they can view schema objects, but they cannot use the schema for structured options, like registration tables or searches.
In the example below, a user with entity permissions but no permissions to the Donor schema can view the entity page, but cannot search for the Donor schema in the drop-down menu.
Can you set all schema policies in bulk?
No, it is not currently possible to bulk assign schema policies. Each schema must be updated manually.
What are the default policies when creating a new schema?
Each schema can have either Read, Create or Admin access policy applied.
Can you set schema policies from the API?
No, currently you can only set schema policies in Registry Settings.
Can you remove schema access for all users?
No, at least one admin must be assigned schema access. The same is true for Registry Settings.