Benchling's Inventory application offers a digital representation of your lab's physical storage system, allowing you to track the location, quantity, and status of samples and containers. By mirroring your physical inventory within Benchling, you can efficiently manage samples, streamline workflows, and maintain data integrity across experiments.
Benchling Inventory is structured to reflect the physical hierarchy of your lab storage, encompassing:
| Inventory schema type | Description | Example |
| Location | Physical storage areas in your lab that track inventory hierarchy and may contain boxes, plates, or container | Room, Freezer, Shelf |
| Container | Items that directly store samples | Eppendorf tube, plate well |
| Box | Box with grid layout that can store containers | 9x9 Box |
| Plate | Fixed or matrix plates that contain wells | 96-Well plate |
And samples, which are the Registered entities (e.g., DNA, proteins) stored within containers
Configuring the schemas that define these object types - and how they relate to one another - lays the foundation for standardized, scalable sample management across your lab. By configuring schemas, constraints, units, naming templates, and permissions, you can tailor the Inventory to fit your organization's specific needs.
Configure location schemas
A location schema defines large storage locations such as buildings, rooms, freezers, fridges, racks, and shelves. Configure location schemas to mirror your physical lab layout in Benchling. To configure a location schema:
- Navigate to Registry settings and select Location schemas
- Click Create
- Specify a unique Name and Prefix for the schema.
- The Prefix is used to generate a unique barcode for the location (e.g., FRZ001)
- Add any relevant metadata fields (e.g., Temperature) by clicking the blue + next to Location fields or Add field
- Click Create to save the schema
After configuring location schemas, create specific locations in the Inventory application using a top-down hierarchy (e.g., Building → Room → Freezer → Shelf → Rack). You can create any number of nested locations (e.g., Racks in Shelves in Freezers) to match your physical storage setup. Establishing a clear hierarchy supports your team’s ability to efficiently navigate from high-level areas down to precise storage locations, improving sample traceability and simplifying audits. For details and examples, refer to the create and track samples with the Inventory article.
Configure box and plate schemas
Boxes and plates group containers in a defined grid layout.
- Box schemas are used to define storage formats like freezer boxes that hold tubes or vials (e.g., 10×10 freezer boxes containing cryovials).
- Plate schemas are used to define plates with dimensions that match lab hardware (e.g., 96-well plates with 8 rows and 12 columns).
Defining these schemas helps you standardize storage formats for consistency and traceability across your organization.
Configure a box schema
- Navigate to Registry settings and select Box schemas
- Click Create
- Specify a unique Name and Prefix
- (Optional) Restrict the box schema to containing only a specific container schema by selecting a container type from the Container Schema menu. Do not select a container type for container-agnostic boxes
- Add metadata fields by clicking the blue + next to Box fields or Add field
- Click Create to save the schema
Configure container schemas
Container schemas define the types of vessels used to store samples in your lab, such as cryovials, tubes, or wells.
Benchling will innately track the location of the container as well as the contents (entity) of the container. Container fields such as volume and concentration are available by default in the platform; there is no need to configure specific metadata fields to capture this information. If there is other container metadata you need to capture to achieve your organization’s goals, this is a good application for the container fields.To configure a container schema:
- Navigate to Registry Settings and select Container schemas
- Click Create
- Enter a unique Name and Prefix for the schema
- Add metadata fields by clicking the blue + next to Container fields or Add field
- Click Create to save the schema
In general, we recommend using the fewest number of container schemas that will still be reflective of your physical laboratory storage system. For instance, many customers are successful with just one generic Tube container schema as opposed to a different tube schema for each tube type (e.g., Eppendorf tube, Cryovial, 1.5 mL tube, etc.).
Configure well schemas
Well schemas are a specialized type of container schema used within plate schemas. Well schemas allow you to define what metadata should be tracked per well. Metadata fields configured on well schemas are what appear and can be edited within plate maps and the plate design tool. Without a well schema, you cannot capture well-level metadata or apply structured well roles in experiments. To configure a well schema:
- Navigate to Registry Settings and select Container schemas
- Click Create
- Enter a unique Name and Prefix for the schema
- Add any fields needed to capture well-level metadata (e.g., sample type, replicate number)
- Click Create
Note: if you or your team wants to take advantage of using plate designs or plate maps in the Notebook to record experimental data or plan to use Benchling Analysis to analyze the data, consider configuring fields for what they need to track both in the plate record, but also when they analyze the data.
Configure plate schemas
Note: To configure a plate schema, you must first configure a compatible container schema (e.g., Well).
- Navigate to Registry settings and select Plate schemas
- Click Create
- Specify a unique Name and Prefix
- Specify the plate Size for the appropriate plate dimensions
- Specify the Type (Well plate or Matrix plate)
- Specify the Container Schema to be used
- Add metadata fields by clicking the blue + next to Plate fields or Add field
- Click Create to save the schema
Once schemas are created, you can build boxes and plates in the Inventory application.
Set location constraints and restrictions
To prevent misplacement or exceeding storage capacities, location constraints help enforce what types of containers or boxes can be stored where and capacities. Location constraints ensure that inventory items are stored appropriately, preventing errors such as placing loose containers directly onto shelves.To configure location constraints:
- Navigate to the specific location's metadata page
- Set Allows boxes, plates, and containers to No to prevent direct storage of items
- Specify Allowed inventory schemas to restrict the types of items that can be stored
- Define Inventory Capacity to limit the number of items in the location
These settings help maintain the integrity of your inventory system by enforcing storage rules.
Units in the Inventory
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.
The units in the Unit Dictionary are applied to the quantity and concentration fields of the Inventory. If you use units in these fields that don’t appear, add those units to the Unit Dictionary. Likewise, if units appear in these fields that your team doesn’t use, they can be removed from the Unit Dictionary.
Note: you cannot put units on custom fields for Inventory objects.
Inventory schema naming conventions
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:
- Click on your Avatar, go to Feature Settings, and select Registry settings
- In the Registry settings page, click on the entity schema of your choice
- In the schema, click Container name template at the bottom of the page
- 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:
| Component | Definition |
| Content Fields | |
| Entity Name | Name of the entity(s) in the container |
| Metadata field | Any metadata field configured on the entity, excluding computed fields |
| Sample aliquot number | Aliquot # based on the number of containers created from one entity |
| Registry ID | Registry ID of contained entity |
| Registry ID Number | Only the numbers at the end of a registry value string |
| Container Fields | |
| Barcode | Barcode of container. Either autogenerated or defined by user upon creation of container |
| Barcode number | Only the numbers at the end of the barcode value string |
| Concentration value | Concentration value of the contents in the container |
| Concentration units | Concentration units of the contents in the container |
| Fill date | Date the container was filled with the first contents, which should be the same date that the name template was applied |
| Fill year | Year the container was filled with the first contents, which should be the same date that the name template was applied |
| Parent location barcode | Barcode of parent location. Such as box, shelf, freezer, etc. Note that this will not update if the container moves locations |
| Parent location name | Name of parent location. Such as box, shelf, freezer, etc. Note that this will not update if the container moves locations |
| Grid position | Position of container if within Box or Plate |
| Project | Project folder of contents |
| Quantity Value | Quantity of contents |
| Quantity Units | Unit of recorded content quantity |
| Restriction status | Restriction status of container. Example: “Unrestricted”, “Restricted”, “N/A” |
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
Permissions and access
Permissions ensure the right people can create, edit, and manage inventory data—while others may only view it. This is especially helpful in shared labs or regulated environments where access needs to be controlled at the object or schema level.
Inventory items (containers, boxes, and plates) derive permissions from where they reside:
- If in a project/folder, project permissions apply
- If not in a project, registry permissions apply
Locations cannot be placed in projects and always use registry permissions. To view items in Inventory Locations, users must have at least Read permissions to the Registry.
| Action | Read | Write | Admin |
| View inventory items (containers, boxes, etc.) | ✓ | ✓ | ✓ |
| Create new inventory items | ✗ | ✓ | ✓ |
| Edit metadata fields on inventory items | ✗ | ✓ | ✓ |
| Configure location, container, or plate schemas | ✗ | ✗ | ✓ |
| Manage Unit Dictionary | ✗ | ✗ | ✓ |
| Apply or edit naming templates | ✗ | ✓ | ✓ |
| Set location constraints | ✗ | ✗ | ✓ |
| Update barcodes (manually or via spreadsheet) | ✗ | ✓ | ✓ |
| Assign collaborators and set permissions | ✗ | ✗ | ✓ |
Note: Schema-level permissions must be configured through Registry Settings or schema configuration pages. Permissions can also be inherited via project-level access where applicable.—while others may only view it. This is especially helpful in shared labs or regulated environments where access needs to be controlled at the object or schema level.
While some objects might be shown in both the Registry and a Project, or in the Inventory and a Project simultaneously, the permissions for simple actions such as viewing or editing that object will only be derived from one of those locations. More complicated actions such as using a Registration table to create new entities might check multiple permissions to cover all the actions involved, as laid out below in the Creating new objects section. Furthermore, permissions only depend on the current state; it doesn’t matter how an object got to a particular location or the history of being registered or unregistered, all that matters is the object’s current state when determining what permissions apply now.
Objects in the Inventory
Inventory objects like containers, plates, and boxes can be put into Projects and sometimes Project Folders, but they can also just exist in the Inventory with no association with any Project at all. Whether or not an Inventory object is in a Project or Folder determines which permissions are used:
- If the Inventory object is in a Project or Folder, the Inventory object will use the permissions applied to that Project or Folder where the Inventory object is located
- If the Inventory object is not in any Project or Folder (in other words, it is only in the Inventory) then the Inventory object will use the permissions set on the Registry
- This includes Locations, which cannot be put into a Project or Folder so they will always use the permissions set on the Registry
However, Inventory objects that are in an Inventory Location (which is true for most Inventory objects) also require the user to be able to view that parent Location, which typically requires the user to have at least View access to the Registry in order to view and use Inventory objects.
Frequently asked questions
Q: Can I restrict certain container types to specific locations?
A: Yes, by configuring location constraints, you can specify which container schemas are allowed in each location.
Q: How do I ensure consistent naming for new inventory items?
A: Use naming templates within your schemas to automate and standardize the naming of new entities and containers.
Q: Is it possible to bulk update barcodes for multiple items?
A: Yes, you can use the bulk import feature with a spreadsheet to update barcodes for multiple inventory items simultaneously.
Q: How do unit-aware fields benefit my inventory management?
A: Unit-aware fields ensure that all measurements are recorded using standardized units, facilitating accurate data analysis and reporting.