Benchling's Registry serves as a centralized system for managing and tracking samples such as plasmids, cell lines, and small molecules. It enables teams to standardize data, enforce validation rules, and maintain a comprehensive record of research materials throughout their lifecycle. 

In Benchling, the relationship between Registry schemas and the objects created by them, or entities, drives structured data capture. By configuring the Registry, you can define schemas, set naming conventions, enforce data integrity, and control user permissions, ensuring consistent and accurate data management across your organization. 

This guide provides comprehensive instructions on creating, configuring, editing, and archiving Registry schemas to support your team's data management needs.

Structure metadata with Registry schemas 

Registry schemas are a specific type of schema that you can configure in Benchling. They define the structure and metadata of your entities and serve as an authoritative source for a given entity and are linked to key Benchling features such as Inventory, Results, and Workflows. 

When creating a Registry schema, you are required to define: 

• A prefix used to generate IDs when an entity is created
• A name
• An entity type
• Naming options that help generate the ID when an entity is created 

Benchling supports the creation of schemas for the following entities:

Note: Molecule entities are an add on feature. If you are interested in using molecule entities, contact support@benchling.com or your account representative. 

When configuring a Registry schema, you can optionally define: 

• Uniqueness constraints
• Fieldsets
• Entity fields 

In this way, Registry schemas provide a foundation for structured, contextualized scientific data, ensuring entities are consistently represented, accurately related, and traceable across the platform.

Set uniqueness constraints

Uniqueness constraints are set on a per schema basis to prevent the registration of duplicate entities by enforcing rules on specific fields or combinations of fields. To set a uniqueness constraint:

1. In the schema configuration page, click the + next to the Unique Constraint section
2. Select the field(s) that should be unique across entities
3. Click Add to enforce the constraint

For example, you might enforce uniqueness on the combination of heavy and light chains in an antibody schema to prevent duplicate entries.

About Fieldsets

As you build out your data model, you may notice overlap in the fields used across them. Rather than manually recreating those fields each time, you can use Fieldsets, which are reusable collections of fields that promote consistency and simplify schema configuration and are designed to help model rich and varied scientific data relationships. 

Fieldsets define the structural constraints that can be enforced on one or more schemas to improve governance across your data model. For example, Fieldsets allows you to refine how links are used to improve data quality. Fieldsets have the ability to be used as Categories. Categories represent the group of schemas that apply a Fieldset. The category name is always the same as the Fieldset’s name. For example, if two different schemas called X and Y exist, a Fieldset can be created that groups schemas X and Y in a category called Z. Both X and Y can be referred to as type Z. Users within your organization will be able to interact with the Fieldset category just like they would any other schema.

When configuring lookup columns or snapshot fields that traverse a Fieldset, users will see an option to Restrict to Schema or Type-cast the link. Restricting the lookup through a specific schema type means the link will only traverse those schema entities rather than any schema in the Fieldset. This provides value because you can hoist any field value defined in the schema and not just the Fieldset field values.

Type-casting is helpful when you need a lookup field to find metadata that is specific to a schema and is not configured on the Fieldset. If you decide to type-cast a link, all schema specific metadata will be available to continue your lookup. If you type-cast a link but the lookup finds an Entity that is not part of the schema that the lookup is restricted to, no value will be returned. If you leave the Restrict to schema dropdown blank, you will only be presented with metadata fields that are enforced by the Fieldset.

Example Fieldset use case 

The data model below shows one way that you may have created linkages between schemas without using Fieldsets. This data model shows how Cell Line A and Cell Line B schemas can be linked to the Cell Line Batch schema through entity links.  

However, looking deeper at the data model, you might notice: 

• The first two fields of Cell Line A and Cell Line B are tracking the same information, but they are using different names and definitions.
• In the Cell Line Batch schema, there are optional entity link fields to either Cell Line A or Cell Line B to allow data entry for both entities. Users are meant to enter either a value for Cell Line A or Cell Line B, however, this can not be made required and is thus not enforceable. Therefore, this setup increases the likelihood that no entity is entered into the Cell Line A or Cell Line B fields.

Using a Fieldset will allow this data model to maintain links between the two Cell Line schemas and the Cell Line Batch schema and enforce the desired data entry.

Apply a Fieldset

A good starting point for creating a Fieldset is assessing the fields that overlap between schemas. Recall from the data model above that the first two fields of Cell Line A and Cell Line B are tracking the same information but are using different names and definitions. Use these overlapping fields and standardize the names and definitions to create a Fieldset.  

The image below shows how you could apply a Fieldset to the data model from above. The Cell Line Fieldset holds the common fields required by the Cell Line A and Cell Line B schemas. The Cell Line A and Cell Line B schemas apply the Fieldset to ensure data consistency for the defined fields while retaining the fields that are unique to each schema.

Creating a Fieldset and applying it to multiple schemas enables the use of Category links as a way to link schemas. In this example, the Category link allows you to require that data about a Cell Line entity be entered in the Cell Line Batch schema. 

In this way, Cell Line A and Cell Line B schemas are linked to the Cell Line Batch schema, but rather than having multiple, optional entity link fields, Fieldsets allows this to be done with a single required entity link. In this data model, users will be required to enter either a Cell Line A entity or a Cell Line B entity when registering a new Cell Line Batch. 

Note: Entity link fields defined with a Category cannot be set as Parent links. 

Configure Fieldsets 

In order to leverage Fieldsets, you must first create the Fieldset(s) and define the settings, properties, and Access Policies that should be enforced before deciding which Entity Schemas the Fieldsets should apply to. You have the option to create a Name Template after the Fieldset object is created. In order to have a schema apply a Fieldset, the schema must match the exact field names and definitions that are defined by the Fieldset. To configure a Fieldset: 

1. Click the avatar icon in the bottom left of the Benchling platform, hover over Feature Settings, and select Fieldsets
2. In the Fieldsets menu, click the Create button in the upper right corner to create a new Fieldset
3. Define the Fieldset Settings. At minimum, you are required to specify the Name, Organization, and Available Registration Naming Options
   • Name - Enter a descriptive name for your Fieldset into the textbox. This is the name that users will see when they use the Fieldset
   • Organization - Use the dropdown to designate the organization for the Fieldset. Only the associated Entity Schemas of the designated Organization’s Registry will be able to apply this Fieldset
   • System name  - This name is used to access Fieldset data in both the Warehouse and the API. You may edit this name if desired
   • Entity Type - Choose an Entity Type if you would like to restrict the Entity Schemas that are allowed to apply this Fieldset. This ensures that administrators can only apply this Fieldset to specific types of entity schemas
   • Prefix - Configuring a prefix is optional as prefixes can be set on the Fieldset or on the schemas themselves. However, when configured the prefix will be applied to all schemas that apply the Fieldset. If you would like each schema to have its own unique prefix, leave the prefix blank on the Fieldset configuration page
   • Constraint - Configuring Fieldset constraints is optional. However, when configured the constraint will be applied to all schemas that apply the Fieldset. A constraint ensures uniqueness on the field(s) added to the constraint. This is used to ensure uniqueness between two entities registered across all schemas that apply the Fieldset.
4. Configure the fields for the Fieldset, these will be the names and definitions that will be used for all schemas that apply the fieldset. Do this by clicking the + icon next to the Fieldset field table, complete the following components:
   • Name - Name your Fieldset field. Ensure the name is meaningful and intuitive
   • System name  - This name is used to access field data in both the Warehouse and the API for any schema that applies the Fieldset. You may edit this name if desired
   • Required - Determine if the field value is required or optional. If this box is checked, a user cannot register an entity if they do not provide a value for a required field
   • Multi-select - Determine if the field should be multi-select. Some definitions, such as Dropdowns, allow you to check the multi-select box which ensures multiple values can be entered
   • Definition - Choose the type of data that will be stored when a user enters a value for the field
5. Use the check boxes to select which Registry naming options will be available to the user when they register entities with the schema
6. After all settings have been specified, click Next
7. Define access policies. Fieldsets have two general sets of permissions:
   • Read - Allows users to filter the Registry by Fieldset, allows for inserting Fieldset lookup tables
   • Admin - Allows users to edit the Fieldset itself
8. Click Create

Implement the Fieldset on the relevant schema(s)

Once you’ve configured the Fieldset, you must now select which schemas it should apply to. You can apply a Fieldset to existing schemas or to new schemas.

1. If not already created, create the entity schema(s) that will implement the Fieldset
2. Navigate to the schema that will apply the Fieldset
3. Use the schema Fieldsets dropdown to select the Fieldset that should be applied
4. Choose an available naming option
5. Click Add 

Note: After applying a fieldset, you can still reorder or hide fields for a specific schema view. You can also add or maintain fields that are specific to a schema and not the fieldset. However, updates to fieldset-specific fields must be made from the fieldset itself. Updates to field tooltips must be made from the schema itself, either before adding the fieldset, or by temporarily removing the fieldset, editing the field tooltip, then re-adding the fieldset.

Update a Fieldset

Updating a Fieldset relies on the principles of how a Schema and Fieldset depend on one another. Generally, the Schema is dependent on the Fieldset. 

Fieldset settings require uniqueness across the applying schemas. For example, this means that the Prefix of a Fieldset will be consistent across all Schemas that successfully apply the Fieldset. If a schema has already applied a Fieldset with a prefix or any other settings (e.g. name template, fields, etc), then you cannot apply another Fieldset with a prefix even if the fields from that Fieldset are unique. The entire Fieldset definition must be applied for it to be successful.

Adding or updating a setting on an existing Fieldset requires you to plan ahead and will likely require you to modify the Schemas that apply the Fieldset before you update the Fieldset, itself.

The following list explains how each setting can be updated:

• Name - Updating the name of a Fieldset will succeed without a failure. You will need to refresh your browser to see the new Fieldset name in Notebook entries and Categories.
• Prefix - Adding or updating a Prefix on a Fieldset is dependent on the schemas that apply the Fieldset. When you add or update the prefix, Benchling will attempt to apply that prefix to all Schemas that apply the Fieldset.
  • If the Schema has already applied a Prefix from another Fieldset, you will not be able to add the prefix because there would be a conflict.
  • If the Schema has its original prefix, it will be overwritten and updated by the prefix from the Fieldset.
  • A prefix cannot be removed from a Fieldset that is applied by 1 or more schemas. To workaround this, you first need to un-link each schema from the Fieldset, remove the prefix on the Fieldset, and finally re-apply the Fieldset to all schemas.
• Entity Type - Adding or updating the Entity Type of a Fieldset will work as long as all schemas applying the Fieldset are the type you are setting on the Fieldset.
  • Check all of the applied Schemas before adding or changing the Entity Type of a Fieldset to avoid errors. To correct any conflicts, choose to either update those Schemas with the correct Entity Type and/or remove the Fieldset relationship on any Schemas with conflicting Entity Types.
  • If you set the Entity Type to None, it removes the Entity Type constraint relationship to each schema. This operation will always succeed. This will not change the Entity Type on any of the associated schemas.
• Name template - When you add or update a Name Template, Benchling will propagate it down to each Schema that applies the Fieldset. The name template from the Fieldset will propagate even if the schemas already have a name template.
  • Removing the Name Template from the Fieldset removes the constraint relationship between the Schema and the Fieldset. This operation will always succeed. This operation will not change the Name Template on any of the associated Schemas.
• Constraints - If you add or update a constraint on a Fieldset, Benchling will attempt to propagate the changes down to all schemas that apply the Fieldset.
  • If any of the schemas already have an existing constraint, even a constraint on the same Fieldset field, the operation will fail.
  • A Fieldset constraint applies across the group of schemas that are part of the Fieldset. All schemas applying the Fieldset have to first remove their constraints to allow them to apply a Fieldset with constraints.
  • When all of the schemas do not have constraints, you will be able to add the constraint to the Fieldset.
  • Updating a Fieldset constraint will always succeed. The changes will propagate down to the constraints of the associated Schemas.
  • Removing a Fieldset constraint will always succeed. This will not affect the constraints of the associate schemas.
• Fields - Adding a Field to a Fieldset requires the associated schemas to have that same field already defined.
  • Updating any attribute (e.g. definition) on a field will propagate to all associated schemas
  • Fields from a Fieldset can be referenced in look-ups, so removing a Field from a Fieldset may not work. To remove a field from a Fieldset, you must first remove any references to that Field.
  • Removing a field will not affect any fields on the associated schemas.

Archive a Fieldset

To archive a Fieldset, first remove all dependencies to the Fieldset. Dependencies include entity links to the category, look-ups to a field via the category, and schemas that apply the Fieldset.

1. Navigate to the Fieldsets menu of Registry Settings
2. Hover over the Fieldset you wish to archive and click the Archive icon
3. Select an archive status and click Archive to confirm the action

For more about how Fieldsets can be used across the Benchling platform once you’ve configured them, see the linked article.  

Establish relationships between entities with parent child links

Biological samples often have a relationship between one another; for example, a plasmid can be engineered to express a certain protein, then prepared in multiple ways for different experiments. In Benchling, the original plasmid is referred to as a parent entity while the various preparations are referred to as child entities. 

Child entities track the differences between one another whereas the parent entity represents the similarities between the child entities. You can designate the parent-child relationships on the child schema(s). In Benchling, child entities: 

• Allow you to link data from one entity to another entity
• Represent lots, dilutions, or preps of a specific entity
• Allow for additional fields to track unique information about the child entity
• Can be parents of other child entities so as to model multi-stage production work 

Create and manage entity schemas

Create a schema when you need to define a new type of entity that requires its own structure, rules, and metadata. Common reasons to create a schema include:

• Introducing a new sample type not yet captured (e.g., cell pool vs. cell line)
• Tracking a category of materials with unique naming, validation, or relationship rules
• Segregating data types for access control or reporting purposes

Each schema is a distinct blueprint for how entities of that type should be named, stored, validated, and linked to other data. Be intentional about schema creation to avoid duplication and to maintain a clean registry structure. To create a new entity schema:

1. Navigate to Registry Settings by clicking your user avatar and selecting Feature Settings then selecting Registry Settings from the menu
2. From the Entity schemas menu, click Create
3. Enter a unique name and prefix for the schema. You can choose to enter a schema description, which will be visible in registration tables for this schema
4. Define the schema entity type (e.g., DNA Sequence, Custom Entity). This category helps determine which features the schema supports
5. After selecting a category, you should define the schema’s entity fields, type and settings (required, multi-select, parent link). Field types include:
6. The Containable Type field defines whether entities under this schema can be stored in physical containers within the Inventory. By default it is set to “None”, meaning entities under this schema cannot be stored in containers. Changing this to “Entity” means entities under this schema can be stored in containers
7. Click Next to save the entity settings and proceed to the access policies page
8. From the Access Policies page, you can customize who can create and edit entities or manage access to the schema
9. Click Create to create the schema

Entity field configuration options 

Entity field configuration options represent the attributes or metadata that will be captured for an entity and are central to how information is captured, displayed, and validated in the Registry. You can add multiple entity fields to your schema, and settings for each field include: 

• Required: this checkbox makes a field value required at the time an entity is created (i.e. if the field value is blank, then an entity cannot be registered)
• Multi-select: this checkbox enables inputting more than one dropdown option or entity link in a field value
• Parent: this checkbox indicates the entity linked on this line is the parent schema of the current one (i.e. the current schema is a child entity)

The table below summarizes the options for entity field definitions that you can use when configuring your registry schema. 

Configure units in integer and decimal fields 

Benchling supports unit-aware fields, which let you capture values like concentration or temperature with associated units (e.g., "5 mg/mL"). These fields reference a central Unit Dictionary, enabling consistent reporting and comparisons across schemas. Tenant admins can customize units in the Unit Dictionary under Feature Settings to match team conventions.

To add unit awareness on an entity field:  

1. In the schema configuration page, click Add field and enter a unique name for the schema
2. Select a unit-supported data type (integer or decimal)
3. Click the gear icon and select Set unit and select the unit for the field
4. Click Save to apply

To update an existing field to a unit-aware field:

1. In the schema configuration page, hover over the field of interest (must be a unit-supported type like integer or decimal)
2. Click the gear icon and select Set unit and select the unit for the field
3. Click Save to apply

Note: the unit of a given field cannot be changed once it’s been set and the field has been created. To change the unit of a field, archive the field and create a new field with the appropriate unit. 

Computed fields

Computed fields may pull, or hoist, information directly from a specified field on an entity or indirectly from other linked entities within the Registry. Results can also be pulled onto an entity in a couple different formats.

Your Benchling admin must assign a formula configuration to the computed field, which informs Benchling of the data type you need pulled or calculated. For a comprehensive list of formulas offered in Benchling, visit Computed field types.

Computed fields are specifically used in the Registry to track live data across all registered entities. Say you have a computed field on a protein that displays the resistance gene linked to its parent plasmid. If that resistance gene were edited at a later time point, the computed field would recalculate its value and display the new resistance gene.

Computed fields can only be set up internally by Benchling. If you need computed fields configured for your tenant, please contact Benchling support at support@benchling.com. When requesting a computed field, include the following details or download and fill out the computed fields request form:

• Tenant name or URL
• Schema name
• Name for the computed field to be configured
• Computed field formula type
• The metadata lineage or where to hoist the Metadata field from

Note: existing computed fields can also be modified via Benchling Support request but existing fields (not computed) cannot be modified into computed fields. If you need to change an existing field into a computed field, you must archive the existing field and request a new one to Benchling Support.

Registry schema naming conventions

The Registry standardizes the way you name each item of a schema. Each entity has a Registry ID and descriptive name. 

• Registry ID: this is a systematic ID generated by Benchling for every entity based on a prefix defined at the schema level
• Name: user defined or configured to be systematically created by Benchling

Both the Registry ID and the descriptive name must be unique in the Registry and either can be used to reference and link to the entity. Consistent naming conventions help maintain clarity and prevent duplication, and there are several options for how to generate the descriptive name of each entity: 

• Provide your own name: when you create an entity, you’ll be prompted to provide a descriptive name (this can include text, symbols, numbers)
• Use the Registry ID as the name: this generates a name based on the systematic Registry ID (they match exactly). This option is useful for standard, non-descriptive nomenclature

You also have the option to use naming templates, as described below. 

Set a naming template

Once you have created a schema, you are able to generate a systematic name based on a combination of the fields you have configured. This is useful for standardizing nomenclature and doesn’t require manual naming. 

1. In the schema configuration page, click Set name template
2. Define the components of the name, such as prefixes, field values, or parent entity information, components include:
   • Separator - For symbols to separate the components of your name template. Example: “-”, “_”, “ “
   • Text - For any character you’d like displayed in the name template
   • Parent Lot number: parent schema name - Only an option if the schema has a parent schema. This lot # is automatically generated by Benchling based on the number of lots (children) created from one entity (parent).
   • Creation year - Example: “2023”
   • Creation date - Example: “20230714”
   • Field: schema field name - Present if schema has schema fields. Text displayed in the UI for any schema field. Entity link fields render the entity name in the naming template
   • Registry ID: parent schema name - Only an option if the schema has a parent schema. Numbers at the end of a registry value string of the parent entity
   • Registry ID number - Numbers at the end of a registry value string
3. Click Set to apply the template

For example, a naming template for cell lines might be: Vendor-Organism-LotNumber, resulting in names like ABC-Human-001.

Entities in the Registry can also have multiple aliases. This is often useful if different people have different names for the same entity. Aliases are searchable and can be used to refer to the entity, but they also must be unique.

Note: For historical data, if you are using a numbering system, Benchling can generate an ID based on the highest number to reduce confusion (i.e. if you already have entities numbered up to 945, you can start numbering new entities beginning with 946).

Configure container name templates 

Naming templates for containers are set on the entity schema configuration page. This means that container name templates depend on the entity type they contain. To set a container naming template: 

1. Click on your Avatar, go to Feature Settings, and select Registry settings
2. In the Registry settings page, click on the entity schema of your choice
3. In the schema, click Container name template at the bottom of the page
4. In the modal that opens, use the dropdown list to select the components you’d like to include in the naming template, then click Set to save them 

Note: you can select multiple components to your naming template and drag and drop the components to re-order them if needed.   

Container name templates can only be applied to “containable” entities. To make an entity schema “containable,” click Entity in the “Containable Type” dropdown above the “Container name template” section.

In the container naming template configuration window, the components you can choose for the template will vary depending on the schema you are setting the template for. The table below describes the all of the options for container naming: 

Name template behavior in the Inventory

• Transferring contents between containers: When the destination container is empty and the source container has multiple contents, the same name template chosen for the source container will be applied to the destination container
• Multiple contents within a container: The naming template of the entity transferred in first will be applied to the container
• Empty name generated by the naming template: If there are no values for the configured name template, an error will appear and prevent you from creating the container

Archive and edit existing schemas and fields 

Over time, your team may outgrow certain schemas or fields, or move to newer versions. Through archival, you can retire schemas or individual fields from active use without deleting historical data. This preserves system performance, reduces clutter, and maintains a clean experience for end users.

Archiving hides schemas or fields from active use without deleting data.

To archive a schema:

1. Navigate to the Entity schemas menu of Registry Settings
2. Hover over the schema you wish to archive and click the Archive icon
3. Select an archive status and click Archive to confirm the action

To archive a schema field:

1. In the schema configuration page, locate the field to archive
2. Click the Archive icon next to the field
3. Select an archive status and click Archive to confirm the action

To edit schemas or fields: 

1. In the Entity schemas menu of Registry Settings, select the schema you wish to edit
2. Make the necessary changes to the schema's fields, naming conventions, or other settings
3. Some changes such as updating the naming options save automatically. Other actions like renaming the schema or changing entity fields require you to save changes by clicking the ✓ icon, or discard changes by clicking the ✕ icon 

Unarchive schemas and fields

1. Navigate to the Entity schemas menu of Registry Settings
2. Under the Archive status dropdown menu, select one or more statuses from the list Archived schemas are shown in light gray text with the archive status next to the schema name
3. Hover over the schema you wish to unarchive and click the Unarchive icon

To unarchive a field: 

1. In the schema configuration page, click Show archived fields
2. Click the Unarchive icon next to the field

Manage dropdown options

Dropdown lists are reusable value sets that can be referenced across multiple schemas. You can use dropdown lists to standardize how users enter structured values like organism type, status, or method. By centralizing these values, dropdowns improve data quality, simplify updates, and enable consistent filtering and reporting.

To create or update a dropdown list:

1. Go to Registry Settings and find Dropdowns from the menu on the left side
2. Click Create or select an existing list
3. If creating a new dropdown, give it a unique name (e.g. Organism Type) and provide the options by clicking the + next to the Options section
   1. To add multiple dropdown options, click Import Options and enter each value on a separate line in the text box (e.g. E. coli, Yeast, CHO), then click Import Options
4. If you’d like to rearrange your options in alphabetical order, click Alphabetize
5. Add, edit, reorder, or archive the values in the list. Some changes such as reordering options save automatically. Other actions like editing an option require you to save changes by clicking the ✓ icon, or discard changes by clicking the ✕ icon. These updates apply to all fields using that dropdown

If creating a new dropdown, click Create to save

Note: Benchling generally recommends creating all the dropdowns you need before you configure your schema. You can edit the field type to add a dropdown after configuration, but configuring them before makes it 

Configure specific schemas

Configure mixture schemas

Mixtures are useful for processes where ingredient ratios, batch variability, or preparation methods significantly impact results. One common approach for setting up Mixtures is to create two Mixture schemas.

1. Parent Mixture Schema (ex. “Recipe”): Captures the list of ingredients and their respective ideal quantities for a mixture - this should represent a reusable base formulation
2. Child Mixture Schema (ex. “Preparation”): Captures the list of ingredients and their actual quantities used to create the mixture - this should represent individual batches made from Recipes

Configure oligo duplex and oligo conjugate schemas 

To model siRNA and ASO bioconjugates, Benchling supports oligo conjugate and oligo duplex schema types. These allow you to view the unique components of a bioconjugate, which may otherwise be represented as distinct schemas in Benchling. Oligo conjugates also allow users to create and view chemical connections and biophysical properties in one place. 

Oligo conjugates are composed of an oligo-type schema (RNA or DNA) and a molecule-type schema. One example use-case is for ASOs. Oligo duplexes are composed of two oligo-type schemas (RNA or DNA) and a molecule-type schema. One example use-case is for siRNA. 

In order to configure the oligo conjugate or oligo duplex schema types, you need to first configure these component entities, then you will configure a custom entity and select the option to configure as a complex polymer. 

Note: Modeling attachments to complex polymers requires chemical awareness capabilities that are an add-on to core Benchling capabilities. To enable this for your organization, contact your CX representative and account manager. 

For more information on configuring schemas for oligo conjugates or oligo duplexes, see the linked article. 

Validate data with the Registry 

Benchling can validate your organization's registry to ensure data integrity using uniqueness constraints, and with tools to identify registration errors. 

After registration, the metadata of these entities can be modified by users - potentially by mistake. These errors can cause unseen errors that can affect downstream experiments.

Use cases that lead to entity invalidation include:

• Editing fields such that two entities contain exactly similar metadata
• Removing metadata that was initially required for registration
• Archiving an entity/part that was linked to a required field

To identify these errors, Benchling will perform weekly validation checks on the registry, split deterministically across Friday, Saturday, and Sunday when running these comprehensive checks has the least impact on end user experience. If Benchling perceives that entities are invalid, it will mark those entities and provide information about their invalidation.

Interpret notifications about invalid entries

Benchling will notify users of registered entities that fail validation:

• A user will receive an email notification if they invalidate an entity by modifying its metadata
• Invalidated entities will have a red "Failed" tag next to it

• Clicking into the "Failed" entity will provide more information on what is causing the failed validation check and how to fix said errors. Click into the "?" icon to get more information about the error type

• Users can screen for invalidated entities by navigating to Benchling's search bar and filtering based on "Validation Status"

• Users can also further investigate invalidated entities by filtering based on "Failure Reason" which include
  • Constraint violation
  • Invalid entity link
  • Invalid multi-link
  • Invalid field value
  • Missing required
  • Other

• Invalidated entities that are @-mentioned will be indicated with a red chip, however it does NOT stop a user from utilizing it - users can still click the chip to get the entity information

• Invalidated entities can be manually overridden only by registry admins. However all organization members will be able to see that the validation check was overridden. Note: These checks can be overridden in bulk
• To resolve uniqueness conflicts, unregister one of the duplicates and re-register it to merge it into the other entity that remained registered

Example: "Plasmid A" and "Plasmid B" were registered in the Registry, and a user changes one of the fields in the plasmids such that they both had similar metadata. Benchling will invalidate these entities. If a user checks their notes, unregisters Plasmid A, and re-registers it, "Plasmid A" will be merged to "Plasmid B". All notes and linkages associated with "Plasmid A" will be transferred to "Plasmid B".

Validation rules for fields

Rules can be configured on schema fields to enforce business requirements and maintain data quality. Which rules can be set depends on the type of field: 

• Number fields
  • Required, Not equal, Min, Max
• Text fields 
  • Required, Not equal, Contains, Doesn't contain
• Boolean fields
  • Required, Must equal
• Entity, Entry, and Attachment fields
  • Required, Multi-select allowed
• All other fields 
  • Required

These rules can be configured on each field using the Set validation rules option. When set, they will prevent users from registering objects that don't follow these requirements 

Auditability of schema changes

Changes to schema configurations, including edits to fields, naming templates, uniqueness constraints, and fieldsets are logged for audit purposes if your Benchling environment has audit logging enabled. This is particularly important for regulated teams or those who need traceability of changes for quality management.

Admins can access audit logs to view:

• Who made schema changes
• What was changed (field names, field types, validations, etc.)
• When the change was made

This audit trail helps enforce change control and supports compliance with internal and external standards.

Permissions and access

Registry-level permissions control who can view, access, and modify Registry configurations and settings, including Registry collaborators, Entity schemas, Entry schemas, Inventory schemas (Containers, Plates, Boxes, and Locations), Dropdowns, Printers, and Label templates.

Permission levels

The table below displays the actions users can perform at the project or folder level with default general access policies.

Note: other schema types are governed by Organization Admin status; Teams can be granted access to create (but not edit) Run and Result schemas and to create and edit Workflow and Request schemas on the Team Settings page.

Set Registry permissions

You must have Registry admin permissions to update Registry permissions.

1. In Feature Settings, click Registry Settings
2. In [Org] Registry settings, click General
3. Add new collaborators in the top search bar by searching for user, email, team, organization, or app. Specify the general access policy that should be granted to the user in the right dropdown, then click Add
4. To update Registry permissions for existing users, use the dropdowns under Access Policies
5. To remove user permissions, click the … icon next to the collaborator and click Remove
6. Click Save to apply the permissions

Determine Registry schema permission source

Registered entities from each Entity schema can use either registry-level or project-level permissions. To change a schema’s permission source, contact Benchling Support.

1. In Feature Settings, click Registry Settings
2. Open the desired schema
3. Under Access Policies, scroll down to the Registering Entities section to check whether the schema uses Registry or Project permissions

Schema permissions

Schema permissions provide granular control over how users interact with schemas and their objects as defined in the table below. Schema permissions and access policies are designed to align with higher-level Registry and project permissions, not override them.

Permission levels

The table below displays the actions users can perform at the schema level with default  schema access policies. Schema access policies cannot be customized.

*Schema objects might additionally depend on higher-level Registry or project permissions.

Configure default schema permissions

Organization admins can configure default schema configurations, which automatically apply to all newly created schemas in an organization and can be set for Connection, Entity, Fieldset, Result, Run, and Study schemas.

1. In Feature Settings, click Access Policies
2. In the menu, click Schema Access Policies, then click the Settings tab
3. Select the organization from the Organization dropdown menu, then select the schema type from the list that displays below it
4. Search for users, teams, or organizations under Default Options, then click Add
5. In the Schema Access Policy column, select the default schema access policy for each collaborator
6. Click Save

Set individual schema permissions

Schema admins can configure permissions on individual schemas.

1. In Feature Settings, click Registry Settings
2. In the menu, click on the schema type that you want to update, then click the individual Connection, Entity, Entry, Run, Result, or Fieldset schema to update
3. Click the Access Policies tab
4. Add new collaborators in the top search bar by searching for user, team, organization, or app. Specify the general access policy that should be granted to the user in the right dropdown, then click Add
5. To update schema permissions for existing users, use the dropdowns under Access Policies
6. To remove user permissions, click … next to the collaborator and click Remove
7. Click Update Collaborators to apply the permissions

Frequently asked questions

Q: When should I use Fieldsets instead of creating schema-specific fields?

A: Use Fieldsets when the same set of fields appears across multiple schemas. Fieldsets are a tool for centralizing field management and help ensure consistent data collection and formatting.

Q: Can I apply more than one Fieldset to a schema?

A: Yes, you can apply multiple Fieldsets to a single schema. Each Fieldset adds a grouped set of fields, and you can also add schema-specific fields alongside them.

Q: What happens if I update a Fieldset after it’s been applied to multiple schemas?

A: Changes to the Fieldset automatically propagate to all schemas that use it. This ensures consistency, but note that modifying or removing fields can impact all linked schemas.

Q: Will I lose data when transitioning a schema from manual fields to Fieldsets?

A: No. If the field names and types match, existing entity data is preserved when replacing manual fields with fieldset versions. Always verify your Fieldset configuration before applying.

Q: Can I customize the order or visibility of Fieldset fields within a schema?

A: Yes. Once applied, you can reorder Fieldset fields within the schema and control visibility in the UI. However, the field definitions themselves are still managed from the fieldset configuration.

Q: Can I edit a uniqueness constraint after it's been set?
A: Yes, you can modify uniqueness constraints by editing the schema configuration. However, changes may affect existing entities, so you should review entities that may be duplicates and violate a uniqueness constraint before proceeding.