Registration table

A registration table is a spreadsheet inside a document that writes the rows you fill into a workspace data environment. It's the cleanest way to register samples, animals, or compounds without leaving your protocol notebook.

When to use it

Use a registration table when:

• You're authoring a protocol or study document and the document itself is the natural place to capture the entities (animals, samples, compounds).
• You want the row IDs (e.g. ANM-001) to land in the workspace's animals table immediately, ready to be referenced from a result batch later.
• You want the audit trail to show the document as the source of registration.

Don't use it when:

• The data is one-off scratch work — use a Data table instead.
• The data already exists in the environment and you just want to display it — use a Lookup table.

How it differs from a data table

A data table is document-local: rows live only inside the document. A registration table is a write-through view: every committed row creates an object in the underlying data environment table. The columns shown are exactly the columns of the target table, including reference and enum fields.

Authoring one

1. Insert the block

   Type / in an empty line, pick Registration table from the Data category.

2. Pick the target environment and table

   A small picker appears. Select the environment (e.g. In-vivo PK) and the table (e.g. Animals). The block instantiates with the table's column definitions.

3. Choose which columns to surface

   Optional. By default all columns appear. You can hide columns you don't want your team to fill in this document — they'll stay nullable in the underlying table.

4. Fill in rows

   Type values cell by cell. Display IDs (e.g. ANM-001) auto-generate when you commit a row, following the table's naming scheme. Enum and reference columns get drop-downs.

5. Commit

   Each row is registered when its required fields are valid. A green checkmark appears on the row; a red flag means a validation error (typically out-of-range values or required fields blank).

A realistic example

In a study protocol document for DLA-7, a registration table targets the Animals table. The user fills in 24 rows during pre-study briefing:

Dalea generates ANM-001 through ANM-024, validates each weight against the 15–35 g range, and checks that every animal references an existing study group. The 24 animals are now queryable from any chart, lookup table, or saved query in the workspace.

Locked registration tables

A registration table inside a locked template typically pins:

• The target table — so users can't redirect registrations elsewhere.
• The visible columns — so the data shape is consistent across runs.
• The validation rules — inherited from the target table, never bypassed.

But leaves row entry editable, so each instantiation of the template captures fresh data. This pattern is the bread and butter of regulatory study templates: the structure of registration is fixed, the contents are filled in during the experiment.

Tips

What's next