Protocol-step forms

Forms collect structured values while a protocol step is executed.

Structured forms appear with the protocol step so operators can capture consistent execution data.

Form choices

No form

Use when completion, notes, and optional attachments are sufficient.

System form

Use a built-in structure for supported standard observations or environmental data.

Custom form

Define organization-specific fields, data types, units, options, ranges, patterns, and required status.

Completion behavior

Required form values must be valid before the step can complete. The submission becomes part of the execution record and remains linked to the batch or sample, protocol version, step, user, and time.

Design guidance

• Use one clear concept per field.
• Include units in structured metadata, not only labels.
• Prefer controlled options when free text would make reporting unreliable.
• Avoid defaults that could be mistaken for measured values.
• Include an exception or comment field only when it has a defined use.

Corrections

When an entered value is wrong, follow the supported correction, amendment, repeat-step, or event procedure. Do not silently overwrite a value that was already used for review or release.

Reporting

Stable structured fields support filtering, trends, custom SQL, and exports. Changing a field’s meaning between protocol versions can make longitudinal comparison misleading; document such changes.

Validation

Test forms with normal, boundary, missing, and invalid values before approving the protocol version.