Direct Data Share: Data Shape | Benchling Documentation

Outbound Direct Data Share exports a fixed catalog of Benchling object types as tables. This page covers how those tables and columns are shaped, including schema field joins, and lists stable and beta object types, alphabetically, with whether each is available. See Direct Data Share: Outbound for how to connect and write basic queries against this data.

Outbound Data Shape

Tables mirror the V3 API object model

There is one table per shareable object type, named after the object type rather than after one of your schemas. Entry becomes ENTRY, DnaSequence becomes DNASEQUENCE, CustomEntity becomes CUSTOMENTITY. Columns are the object’s V3 API fields, so a field documented in the REST API reference is the field you get in SQL.

This means the table set is the same on every tenant. A query you write against CONTAINER keeps working when you add a new container schema. A dashboard built on ENTRY does not break when an entry schema is archived.

Identifier casing

Schema and table names are uppercase. Column names are not. Snowflake folds unquoted identifiers to uppercase, so:

Schemas and tables need no quoting: BENCHLING_TEN_ABC123.ENTRY
Columns almost always do: "createdAt", "schema_id", "entityRegistryId"

-- Works
SELECT "id", "name", "createdAt" FROM BENCHLING_TEN_ABC123.ENTRY;
-- Fails with "invalid identifier 'CREATEDAT'"
SELECT id, name, createdAt FROM BENCHLING_TEN_ABC123.ENTRY;

Table aliases and output-column aliases do not need quoting, because Snowflake folds them consistently on both sides. SELECT e."name" AS entry_name FROM ... AS e is fine.

Field naming conventions

V3 API shape	Column	Example
Scalar field	Same name, camelCase	`"name"`, `"createdAt"`, `"isCircular"`
Reference to one object	`<field>_id`	`"creator_id"`, `"schema_id"`, `"folder_id"`
Reference to many objects	`<field>_ids`	`"authors_ids"`, `"fieldDefinitions_ids"`
Nested value object	`<field>_<nested field>`	`"quantity_value"`, `"quantity_unit_id"`, `"checkoutRecord_status"`
Schema field values	Separate related tables	See schema fields

Direct Data Share flattens reference fields to IDs rather than nested objects, so you join to the referenced table yourself. There is no automatic denormalization. ENTRY."creator_id" gives you an ID, and USER."name" gives you the name.

Schema field values are separate tables

Your tenant-configured schema fields are not columns on the parent object’s table. They arrive as rows in a set of SCHEMAFIELDVALUE_<TYPE> tables, one per value type, each with the same shape:

Column	Meaning
`"id"`	ID of this field value
`"linkedEntity_id"`	The object the value is on. Join this back to `ENTRY."id"`, `CONTAINER."id"`, and so on
`"fieldDefinition_id"`	The field definition. Join to `SCHEMAFIELDDEFINITION."id"` to get the field’s name
`"value"`	The value itself
`"value_id"`	For link fields only: the ID of the linked object

The value type determines the table:

Table	Holds
`SCHEMAFIELDVALUE_TEXT`	Text and long-text fields
`SCHEMAFIELDVALUE_INTEGER`	Integer fields
`SCHEMAFIELDVALUE_DECIMAL`	Decimal fields
`SCHEMAFIELDVALUE_BOOLEAN`	Boolean fields
`SCHEMAFIELDVALUE_DATE`	Date fields
`SCHEMAFIELDVALUE_DATETIME`	Date-time fields
`SCHEMAFIELDVALUE_TEXTANDURL`	Text-and-URL fields
`SCHEMAFIELDVALUE_OBJECTLINK`	Single entity, dropdown, and other link fields
`SCHEMAFIELDVALUE_OBJECTLINKLIST`	Multi-select link fields
`SCHEMAFIELDVALUE_JSON`	JSON fields
`SCHEMAFIELDVALUE_ARRAY`	Array-valued fields
`SCHEMAFIELDVALUE_NULL`	Fields explicitly set to no value

Benchling splits values by type, so each "value" column has one concrete SQL type. This keeps numeric and boolean fields queryable as numbers and booleans instead of strings. JSON and array payloads arrive as JSON strings; use Snowflake’s PARSE_JSON to read into them.

This is a key/value layout, so a schema field you think of as a column takes a join. Schema field joins below has worked examples, including how to pivot schema fields back into columns.

Archived records

Archived objects stay in the tables with "archived" set to true, and "archiveReason" set where the object type has one. Unless you are specifically auditing archived work, filter them out:

SELECT "id", "name"
FROM BENCHLING_TEN_ABC123.CUSTOMENTITY
WHERE NOT "archived";

Timestamps are strings

"createdAt" and "modifiedAt" arrive as ISO-8601 text, not Snowflake TIMESTAMP. Wrap them before doing date arithmetic, truncation, or comparison against a timestamp:

SELECT DATE_TRUNC('week', TRY_TO_TIMESTAMP("createdAt")) AS week, COUNT(*) AS n
FROM BENCHLING_TEN_ABC123.ENTRY
WHERE NOT "archived"
GROUP BY week
ORDER BY week DESC;

ISO-8601 text happens to sort correctly, so a plain ORDER BY "createdAt" works. Do not rely on that for anything else.

Registry census

Registered entities carry "entityRegistryId" and "registry_id"; unregistered ones leave both null. This counts registered custom entities per schema and shows when each schema was last used:

SELECT
    s."name"                                           AS schema_name,
    s."systemName"                                     AS schema_system_name,
    COUNT(*)                                           AS entity_count,
    MAX(TRY_TO_TIMESTAMP(ce."createdAt"))              AS most_recent_entity
FROM CUSTOMENTITY AS ce
JOIN CUSTOMENTITYSCHEMA AS s ON s."id" = ce."schema_id"
WHERE NOT ce."archived"
  AND ce."entityRegistryId" IS NOT NULL
GROUP BY schema_name, schema_system_name
ORDER BY entity_count DESC;

Inventory with storage hierarchy

Containers point at their storage through "parentStorage_id", which can be a box, plate, or location. Joining to LOCATION keeps only the containers stored directly in a location:

SELECT
    l."name"                     AS location_name,
    cs."name"                    AS container_schema,
    COUNT(*)                     AS container_count,
    SUM(c."quantity_value")      AS total_quantity
FROM CONTAINER AS c
JOIN LOCATION        AS l  ON l."id"  = c."parentStorage_id"
JOIN CONTAINERSCHEMA AS cs ON cs."id" = c."schema_id"
WHERE NOT c."archived"
GROUP BY location_name, container_schema
ORDER BY container_count DESC;

Note "quantity_value" and "quantity_unit_id": a nested value object on the API becomes two prefixed columns. Group by the unit, or join to the unit table, before summing quantities across container types that use different units.

Schema field joins

Every SCHEMAFIELDVALUE_<TYPE> table joins back to its parent object and field definition the same way — see schema field values are separate tables. The examples below put that join to work.

Discover which fields exist

Before writing a field query, find the field definitions. "systemName" is the stable machine-readable identifier; "name" is what users see in the UI and can be renamed.

SELECT "id", "name", "systemName", "isRequired", "derivationType"
FROM SCHEMAFIELDDEFINITION
WHERE NOT "archived"
ORDER BY "name";

Read one field’s values by name

Join through the field definition so your query refers to the field by name instead of a hard-coded ID:

SELECT
    ce."name"       AS entity_name,
    ce."entityRegistryId",
    sfv."value"     AS cell_line
FROM CUSTOMENTITY AS ce
JOIN SCHEMAFIELDVALUE_TEXT  AS sfv ON sfv."linkedEntity_id"   = ce."id"
JOIN SCHEMAFIELDDEFINITION  AS fd  ON fd."id"                 = sfv."fieldDefinition_id"
WHERE fd."systemName" = 'cell_line'
  AND NOT ce."archived"
  AND sfv."value" ILIKE '%CHO%';

Pivot schema fields into columns

This is the query most teams want: one row per object, with named columns for the schema fields. The result looks like the table scientists see in Benchling.

Union the value tables into a single key/value stream, resolve each row’s field name, then pivot with conditional aggregation. Each new field you want is one more line in the SELECT:

WITH field_values AS (
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING AS value FROM SCHEMAFIELDVALUE_TEXT
    UNION ALL
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING FROM SCHEMAFIELDVALUE_INTEGER
    UNION ALL
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING FROM SCHEMAFIELDVALUE_DECIMAL
    UNION ALL
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING FROM SCHEMAFIELDVALUE_BOOLEAN
    UNION ALL
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING FROM SCHEMAFIELDVALUE_DATE
    UNION ALL
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING FROM SCHEMAFIELDVALUE_DATETIME
),
named AS (
    SELECT fv."linkedEntity_id", fd."systemName", fv.value
    FROM field_values AS fv
    JOIN SCHEMAFIELDDEFINITION AS fd ON fd."id" = fv."fieldDefinition_id"
)
SELECT
    ce."entityRegistryId",
    ce."name" AS entity_name,
    MAX(CASE WHEN n."systemName" = 'cell_line'  THEN n.value END) AS cell_line,
    MAX(CASE WHEN n."systemName" = 'passage_no' THEN n.value END) AS passage_no,
    MAX(CASE WHEN n."systemName" = 'titer_g_l'  THEN n.value END) AS titer_g_l
FROM CUSTOMENTITY AS ce
LEFT JOIN named AS n ON n."linkedEntity_id" = ce."id"
WHERE NOT ce."archived"
GROUP BY ce."entityRegistryId", entity_name;

Casting to STRING makes the union type-compatible. Cast back where you need arithmetic with TRY_TO_DECIMAL(titer_g_l) or TRY_TO_TIMESTAMP(thaw_date). Add SCHEMAFIELDVALUE_TEXTANDURL to the union if you use those fields; handle link fields separately, since their useful column is "value_id" rather than "value".

Resist the shortcut of joining several value tables directly to the parent table and keying each CASE on a single shared SCHEMAFIELDDEFINITION alias. If an object has two fields of the same type, the cross product pairs a field name with another field’s value. The pivot then silently reports the wrong value in the wrong column. Either resolve the field name on the same row as the value, as the union above does, or give each value table its own SCHEMAFIELDDEFINITION alias.

For a handful of fields you can skip the union and join each value table alongside its own field-definition alias, which keeps each name/value pair together:

SELECT
    ce."entityRegistryId",
    MAX(CASE WHEN fd_t."systemName" = 'cell_line'  THEN t."value" END) AS cell_line,
    MAX(CASE WHEN fd_d."systemName" = 'titer_g_l'  THEN d."value" END) AS titer_g_l
FROM CUSTOMENTITY AS ce
LEFT JOIN SCHEMAFIELDVALUE_TEXT    AS t    ON t."linkedEntity_id" = ce."id"
LEFT JOIN SCHEMAFIELDDEFINITION    AS fd_t ON fd_t."id" = t."fieldDefinition_id"
LEFT JOIN SCHEMAFIELDVALUE_DECIMAL AS d    ON d."linkedEntity_id" = ce."id"
LEFT JOIN SCHEMAFIELDDEFINITION    AS fd_d ON fd_d."id" = d."fieldDefinition_id"
WHERE NOT ce."archived"
GROUP BY ce."entityRegistryId";

Each additional value table multiplies rows before the GROUP BY collapses them, so prefer the union form once you are past a few fields.

Mirror one schema exactly

The pivot above hard-codes field names you already know. To reproduce a specific schema’s shape without guessing, first resolve which fields belong to it. SchemaFieldDefinition has no column pointing back to its parent schema, so go the other direction, through the schema’s fieldDefinitions_ids list.

SELECT
    fd."id"         AS field_id,
    fd."name"       AS field_name,
    fd."systemName" AS field_system_name
FROM CUSTOMENTITYSCHEMA AS s,
     LATERAL FLATTEN(input => PARSE_JSON(s."fieldDefinitions_ids")) AS fid
JOIN SCHEMAFIELDDEFINITION AS fd
    ON fd."id" = fid.value::STRING
WHERE s."name" = '<Your Schema Name>'
  AND NOT s."archived"
ORDER BY fd."name";

Then feed the resulting field_system_name values into the pivot, scoping the parent table to the same schema so only entities of that type appear:

WITH schema_fields AS (
    SELECT fd."id" AS field_id, fd."systemName" AS field_system_name
    FROM CUSTOMENTITYSCHEMA AS s,
         LATERAL FLATTEN(input => PARSE_JSON(s."fieldDefinitions_ids")) AS fid
    JOIN SCHEMAFIELDDEFINITION AS fd ON fd."id" = fid.value::STRING
    WHERE s."name" = '<Your Schema Name>'
      AND NOT s."archived"
),
field_values AS (
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING AS value FROM SCHEMAFIELDVALUE_TEXT
    UNION ALL
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING FROM SCHEMAFIELDVALUE_INTEGER
    UNION ALL
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING FROM SCHEMAFIELDVALUE_DECIMAL
    UNION ALL
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING FROM SCHEMAFIELDVALUE_BOOLEAN
    UNION ALL
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING FROM SCHEMAFIELDVALUE_DATE
    UNION ALL
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING FROM SCHEMAFIELDVALUE_DATETIME
    UNION ALL
    SELECT "linkedEntity_id", "fieldDefinition_id", "value"::STRING FROM SCHEMAFIELDVALUE_TEXTANDURL
),
named AS (
    SELECT fv."linkedEntity_id", sf."field_system_name", fv.value
    FROM field_values AS fv
    JOIN schema_fields AS sf ON sf."field_id" = fv."fieldDefinition_id"
)
SELECT
    ce."id"             AS entity_id,
    ce."entityRegistryId",
    ce."name"           AS entity_name,
    -- one line per field_system_name from the discovery query above
    MAX(CASE WHEN n."field_system_name" = '<field_system_name_1>' THEN n.value END) AS "<field_system_name_1>",
    MAX(CASE WHEN n."field_system_name" = '<field_system_name_2>' THEN n.value END) AS "<field_system_name_2>"
FROM CUSTOMENTITY AS ce
JOIN CUSTOMENTITYSCHEMA AS s ON s."id" = ce."schema_id" AND s."name" = '<Your Schema Name>'
LEFT JOIN named AS n ON n."linkedEntity_id" = ce."id"
WHERE NOT ce."archived"
GROUP BY ce."id", ce."entityRegistryId", entity_name;

This covers scalar-valued fields only. A schema with link fields needs the value_id join from Follow entity link fields below instead. Link values live in OBJECTLINK/OBJECTLINKLIST, not in the scalar value tables unioned here. The same two-query shape works for any schema-bearing object type. Substitute the matching schema table (CONTAINERSCHEMA, ENTRYSCHEMA, and so on) and its parent table (CONTAINER, ENTRY) for CUSTOMENTITYSCHEMA and CUSTOMENTITY.

Follow entity link fields

Link fields are the interesting ones: they connect objects to each other, and they are how you walk from a result to the entity it measured. The linked object’s ID is in "value_id", so you join straight to the target table without parsing anything.

This reports assay results against the registered entity each one links to:

SELECT
    ce."entityRegistryId",
    ce."name"                        AS entity_name,
    rs."name"                        AS result_schema,
    TRY_TO_TIMESTAMP(r."createdAt")  AS result_created_at,
    e."displayId"                    AS source_entry
FROM RESULT AS r
JOIN SCHEMAFIELDVALUE_OBJECTLINK AS link ON link."linkedEntity_id" = r."id"
JOIN SCHEMAFIELDDEFINITION       AS fd   ON fd."id"   = link."fieldDefinition_id"
JOIN CUSTOMENTITY                AS ce   ON ce."id"   = link."value_id"
LEFT JOIN RESULTSCHEMA           AS rs   ON rs."id"   = r."schema_id"
LEFT JOIN ENTRY                  AS e    ON e."id"    = r."entry_id"
WHERE fd."systemName" = 'sample'
  AND NOT r."archived"
ORDER BY result_created_at DESC;

For multi-select link fields, use SCHEMAFIELDVALUE_OBJECTLINKLIST, where "value" holds a JSON array of IDs. Flatten it to get one row per link:

SELECT
    r."id"                  AS result_id,
    linked.value::STRING    AS linked_entity_id
FROM RESULT AS r
JOIN SCHEMAFIELDVALUE_OBJECTLINKLIST AS ll ON ll."linkedEntity_id" = r."id"
JOIN SCHEMAFIELDDEFINITION           AS fd ON fd."id" = ll."fieldDefinition_id",
     LATERAL FLATTEN(input => PARSE_JSON(ll."value")) AS linked
WHERE fd."systemName" = 'related_samples'
  AND NOT r."archived";

Join Benchling data to your own

The point of outbound sharing is joining Benchling records to data Benchling never had. With the share mounted in your own platform, that is an ordinary join.

This attaches your own process-history table to Benchling-registered batches, keyed on the registry ID your two systems share:

SELECT
    ce."entityRegistryId",
    ce."name"                                                       AS batch_name,
    MAX(CASE WHEN fd."systemName" = 'titer_g_l' THEN d."value" END) AS benchling_titer,
    mfg.bioreactor_id,
    mfg.harvest_date,
    mfg.final_yield_kg
FROM BENCHLING_TEN_ABC123.CUSTOMENTITY AS ce
LEFT JOIN BENCHLING_TEN_ABC123.SCHEMAFIELDVALUE_DECIMAL AS d  ON d."linkedEntity_id" = ce."id"
LEFT JOIN BENCHLING_TEN_ABC123.SCHEMAFIELDDEFINITION    AS fd ON fd."id" = d."fieldDefinition_id"
JOIN my_warehouse.manufacturing.batch_history AS mfg
      ON mfg.lot_number = ce."entityRegistryId"
WHERE NOT ce."archived"
GROUP BY ce."entityRegistryId", batch_name, mfg.bioreactor_id,
         mfg.harvest_date, mfg.final_yield_kg;

The registry ID is usually the best join key, because it is the identifier that appears on physical labels and in other systems. Benchling’s internal "id" works too, if your systems already exchange it.

Model coverage

106 of 236 object types are available.

A table only appears in your tenant’s schema once your tenant has at least one record of that type. Run `SHOW TABLES` against your schema to see what you actually have.

Model	Available
AaAnnotation	Yes
AaMonomer	No
AaPartLinkFieldDefinition	No
AaSequence	Yes
AaSequenceLinkFieldDefinition	No
AaSequenceSchema	Yes
ActiveAntibodySchemaMigration	No
AlignedNucleotideSequence	No
Analysis	Yes
AntibodyComponentSchema	No
AntibodyEnforcedDataModel	No
AnyEntityLinkFieldDefinition	No
AppCanvas	No
AppConfigValue	No
AppDefinition	No
AppDefinitionVersion	No
AppInstallation	No
AppSession	Yes
Assembly	Yes
AsyncTask	No
Attachment	No
AttachmentLinkFieldDefinition	No
AuditLog	No
AutomationInputFileConfig	No
AutomationOutputFileConfig	No
AutomationStep	Yes
AutomationStepData	No
AutomationTemplate	Yes
AutomationTemplateDataFrameVariable	Yes
AutomationTemplateVariable	Yes
AvScanRecord	No
BaseFieldDefinition	No
BooleanFieldDefinition	No
Box	Yes
BoxSchema	Yes
CanvasDefinition	No
CanvasFolderArtifact	No
CanvasVersion	No
Chart	No
Collaboration	No
ConfigImportHistoryEntry	No
Container	Yes
ContainerSchema	Yes
CustomEntity	Yes
CustomEntityLinkFieldDefinition	No
CustomEntitySchema	Yes
DataFrame	No
Dataset	Yes
DateFieldDefinition	No
DateTimeFieldDefinition	No
DecimalFieldDefinition	No
DisplayMessageChatEvent	No
DnaOligo	No
DnaOligoLinkFieldDefinition	No
DnaOligoSchema	Yes
DnaPart	Yes
DnaPartLinkFieldDefinition	No
DnaSequence	Yes
DnaSequenceLinkFieldDefinition	No
DnaSequenceSchema	Yes
DocumentPart	No
DocumentPartAnalysis	No
DocumentPartAttachment	No
DocumentPartAttachmentPlaceholder	No
DocumentPartBenchlingItem	No
DocumentPartCodeBlock	No
DocumentPartHeader	No
DocumentPartImageGrid	No
DocumentPartListItem	No
DocumentPartResultsTable	No
DocumentPartRun	No
DocumentPartSection	No
DocumentPartText	No
DocumentPartTextBox	No
DocumentPartUnavailable	No
DocumentPartUnstructuredTable	No
DocumentPartUnstructuredTableDetail	No
Dropdown	Yes
DropdownLinkFieldDefinition	No
DropdownOption	Yes
EntitySchema	Yes
Entry	Yes
EntryLinkFieldDefinition	No
EntrySchema	Yes
EntrySubtemplate	Yes
EntryTemplate	Yes
Enzyme	Yes
EnzymeList	Yes
EquipmentLinkFieldDefinition	No
EquipmentSchema	Yes
EventSubscription	No
FeatureLibrary	Yes
FeatureLibraryItem	Yes
Fieldset	Yes
FieldsetLinkFieldDefinition	No
File	Yes
FileVersion	No
FixedPlate	No
FixedPlateWell	No
Folder	Yes
Germline	Yes
GroupMembership	No
InAppNotification	No
IntegerFieldDefinition	No
InternalPipeline	No
JsonFieldDefinition	No
LabelTemplate	Yes
LegacyAppInstallation	No
LibraryParameterDefinition	Yes
Location	Yes
LocationSchema	Yes
LongTextFieldDefinition	No
MatrixPlate	Yes
MatrixPlateSchema	Yes
Mixture	Yes
MixtureLinkFieldDefinition	No
MixtureSchema	Yes
ModifiedNucleotide	No
Molecule	Yes
MoleculeLinkFieldDefinition	No
MoleculeSchema	Yes
NucleotideAlignment	No
NucleotideAnnotation	Yes
NucleotideMonomer	Yes
NucleotideSequence	No
OligoConjugate	No
OligoConjugateLinkFieldDefinition	No
OligoConjugateSchema	Yes
OligoDuplex	No
OligoDuplexLinkFieldDefinition	No
OligoDuplexSchema	Yes
Organization	Yes
Plate	No
PlateDesignTemplate	Yes
PlateRecord	Yes
PlateSchema	No
Policy	No
PredictionBatch	Yes
PredictionJob	Yes
Primer	Yes
Printer	Yes
Procedure	Yes
ProcedureFlowchart	Yes
ProcedureFlowchartConfigVersion	No
ProcedureFlowchartConfigVersionProxy	No
ProcedureFlowchartVersion	No
ProcedureMethodDefinitionVersion	No
ProcedureMethodExecutionInstance	No
ProcedureMethodExecutionInstanceAssociation	No
ProcedureParameter	Yes
ProcedureParameterConfirmationValue	Yes
ProcedureParameterMeasuredValue	No
ProcedureParameterPlannedValue	No
ProcedureParameterVersion	Yes
ProcedureRun	Yes
ProcedureRunCondition	No
ProcedureRunConditionReplicate	No
ProcedureRunPlan	No
ProcedureRunPlanCondition	No
ProcedureStepDefinitionVersion	No
ProcedureStepExecutionInstance	No
Project	Yes
Protein	No
ProteinAndComponents	No
ProteinFormat	Yes
ProteinLinkFieldDefinition	No
ProteinSchema	No
ProteinVersion	No
Reaction	Yes
Registry	Yes
Request	No
RequestLinkFieldDefinition	No
RequestSchema	No
RequestTask	No
RequestTaskSchema	No
RequestV2Definition	Yes
RequestV2Submission	Yes
Result	Yes
ResultLinkFieldDefinition	No
ResultSchema	Yes
Review	Yes
ReviewChange	Yes
ReviewProcess	Yes
ReviewProcessStage	Yes
RnaOligo	No
RnaOligoLinkFieldDefinition	No
RnaOligoSchema	Yes
RnaPart	Yes
RnaPartLinkFieldDefinition	No
RnaSequence	No
RnaSequenceLinkFieldDefinition	No
RnaSequenceSchema	Yes
Run	Yes
RunLinkFieldDefinition	No
RunSchema	Yes
Salt	Yes
SchemaFieldDefinition	Yes
ScratchFile	No
ServicePrincipal	Yes
Solvent	Yes
SqlDashboard	Yes
SqlDashboardBlock	Yes
StageEntry	Yes
StorableLinkFieldDefinition	No
StructuredTableRow	No
Study	Yes
StudyItemAssociation	No
StudySchema	Yes
SystemCategory	No
SystemCategoryLinkFieldDefinition	No
Team	Yes
TemplateCollection	Yes
TestDefinition	Yes
TestOrder	No
TextFieldDefinition	No
TranscriptionLinkFieldDefinition	No
Translation	Yes
TranslationLinkFieldDefinition	No
Unit	Yes
UnitType	Yes
UnstructuredTableRow	No
User	Yes
ValidationRule	No
WarehouseCredential	No
WarehouseCustomView	Yes
WellPlate	Yes
WellPlateSchema	Yes
WorkflowOutput	No
WorkflowOutputSchema	Yes
WorkflowTask	Yes
WorkflowTaskDefinition	No
WorkflowTaskDefinitionVersion	No
WorkflowTaskGroup	Yes
WorkflowTaskSchema	Yes
Worklist	Yes
Worksheet	Yes

If a model you need is marked No, ask your Benchling representative whether it is on the roadmap.

Troubleshooting

invalid identifier 'CREATEDAT': you left a column name unquoted. Snowflake folded it to uppercase and the column is camelCase. Write "createdAt".

A table does not exist: tables appear only once there is at least one record of that type. Run SHOW TABLES to see what your tenant actually has. If an object type you do use is missing, check with your Benchling representative that it is in your share’s object list.

A schema field is missing from a pivot

Confirm which value table holds it. A field’s type determines its table, so a decimal field will not appear in SCHEMAFIELDVALUE_TEXT. Look up the field’s ID in SCHEMAFIELDDEFINITION, then search the value tables for it:

SELECT 'TEXT' AS tbl, COUNT(*) AS n FROM SCHEMAFIELDVALUE_TEXT
    WHERE "fieldDefinition_id" = '<tsf_id>'
UNION ALL SELECT 'DECIMAL', COUNT(*) FROM SCHEMAFIELDVALUE_DECIMAL
    WHERE "fieldDefinition_id" = '<tsf_id>'
UNION ALL SELECT 'INTEGER', COUNT(*) FROM SCHEMAFIELDVALUE_INTEGER
    WHERE "fieldDefinition_id" = '<tsf_id>'
UNION ALL SELECT 'OBJECTLINK', COUNT(*) FROM SCHEMAFIELDVALUE_OBJECTLINK
    WHERE "fieldDefinition_id" = '<tsf_id>';

Fields explicitly cleared land in SCHEMAFIELDVALUE_NULL. For connection, authentication, and data-freshness issues, see Troubleshooting on the Outbound page.