Schemas are the structural foundation for how your information is categorized in Benchling. They provide the framework to track and manage relationships between entities, how they are used, where they are stored, and results collected against them.
What are schemas?
Schemas are categories created specifically for your tenant that can represent materials, data, storage methods, and tasks. For example, schemas can represent plasmids or cryovials. Schemas can describe entities, which represent physical items or theoretical concepts, or they can standardize information gathering.
When configuring your organization’s schemas, you can create the fields your team needs to capture standardized information about your materials, data, or tasks. For example, on a plasmid schema, you might configure a field to record antibiotic resistance.
You can also configure schema-specific permissions to individuals, teams, and organizations. To learn more about schema permissions for the Registry, visit Registry schema permissions overview.
Schema types and their functions
Schemas are configured in Feature Settings by organization admins or teams with admin-level permissions, depending on the schema category. Schema categories define where its schemas are used. The table below lists all schema categories and their schema types.
A run is part of an experiment performed through an assay instrument, robot, or software analysis pipeline. Run schemas define the metadata tracked on a run. This metadata may include fields for attaching raw instrument output files or other parameters to instruct the instrument.
Entry schemas help organizations tag specific metadata associated with entries across experiments, projects, and groups. When the schema fields are completed, users can search for the information by filtering for these tags. Organizations can link entries or other data together across different departments or groups.
Inventory schemas describe physical locations and containers in your lab to match how your team uses your space and materials.
Container schemas describe a physical container in your lab that directly stores a biological sample. In Benchling, this means containers that store entities. Common container schema examples include cryovials, Eppendorf tubes, bottles, and plate wells.
Box schemas describe the physical boxes you use in your lab. They can be configured to match the sizes and types of storage containers used to store smaller containers, like cryovials and eppendorf tubes.
Plate schemas describe plate-based storage systems, like microplates or cell culture plates, and can be configured as fixed or matrix plates. Matrix plates contain wells that can be moved to other locations, while fixed plates contain wells that cannot be moved.
Location schemas describe a physical location in your lab that might house plates or boxes holding containers of biological samples. For example, within a room, you could have a freezer. Within that freezer, you could have a box containing bottles.
When configuring your container schemas, we recommend reflecting your physical laboratory storage system as closely as possible. Benchling automatically tracks container locations and entities, so you can find an entity’s location directly in its metadata to quickly find samples in your physical lab.
Registry schemas describe categories of samples and chemical solutions, represented in Benchling by entities and mixtures. Registry schemas are commonly used for plasmids, cell lines, strains, and antibodies, but can be used to categorize any sample. They are also used to track exact quantities of ingredients, like media and buffers. Registry schemas include:
Entry (Enterprise only)
Result schemas determine the information your Result tables capture on your experimental and assay data in lab notebook entries. Standardizing your results capture ensures database clarity, centralization, and searchability.
Task schemas determine the identity and behavior of task groups. Tasks schemas must have Tasks and Outputs tables configured to standardize how tasks are requested and fulfilled.
The fields in a Tasks table specify the information a requester completes when creating a task group. The fields in an Outputs table standardize the information the fulfiller shares with the requester.