Design an event form

A multi-stage trip runs on events: survey records of a type your workflow stage binds to. The stage supplies the runtime (Start, lanes, numbering, the boards); the survey type supplies everything else, which means the phases, the fields, the gating, and the alerts are yours to design like any other form. This guide builds one from scratch. It uses a gear deployment as the running example (deploy equipment at a station, return later to read an instrument, retrieve it, assess the work), but the same recipe fits any field work that completes in phases: a trap line, a net panel, a sensor drop.

The fast path: your organization already has a starter survey type named Station deployment event with all of this built. Open it in the survey designer and adapt its labels, options, and rules to your gear and protocol instead of starting blank. The rest of this page explains what each piece is for, so you know what you are adapting.

The identity fields a stage needs

Create the survey type and give it four fields with no section, all marked required. These are the only fields a freshly started event carries, so keep them to what identifies the work:

Field	Type	Purpose
trip	Trip	Links the event to the trip being collected on. Prefilled by Start.
station	Station	Which planned station the work happens at. Prefilled by Start.
event_number	Integer	Sequential within the trip, never reused. Prefilled by Start.
status	Select	The event’s lane. Prefilled by Start; moved by the lane buttons.

The status select’s option values must exactly match the lane values your stage’s lifecycle uses; the Workflow settings page shows them on the stage and its live check flags any mismatch before you can save. With the standard lanes those values are planned, in_progress, completed, and abandoned. The labels are yours in every language; only the stored values must line up.

Phases are sections

Add a section per phase of the work, in the order it happens in the field. The starter uses four: Deployment (the gear goes in), Instrument reading (an environmental reading taken later, often just before retrieval), Retrieval (the gear comes back and the catch is worked), and Assessment (was the work done to protocol, and is the data usable). Assign each remaining field to its phase’s section.

Gate later phases on the status field, never bare required

This is the one rule that makes the whole flow work. A started event saves with only its identity fields, so a later-phase field marked plainly required would block every Start. Instead give each phase’s fields a required when rule tied to the status field:

• Deployment fields: required when status is completed (or, with a richer lifecycle, from the first lane after the deployment is over).
• Retrieval and assessment fields: required when status is completed.
• Never include your abandoned lane in any required-when list: abandoning an event must never demand data.

The result: partial saves always work, and completing the event is what demands the full record. The Workflow settings page dry-runs a Start against your form and warns about any field that would block it.

Checks, and the loud alert

Add validation checks for your protocol’s bounds as warnings, so an unusual value asks for a second look without blocking a real observation:

• A typical-window pair on a duration (for example, warn when a soak or exposure time falls outside your protocol’s window).
• A minimum on a piece of protective equipment’s measured performance.
• A conditions ceiling, such as a sea state or weather bound, marked with an alert level so it escalates to a full-width banner and an audible tone on every device. Use the alert sparingly: it is for the one or two conditions a crew must never sail past.

The pieces worth copying from the starter

• A derived duration: a number field computed from two datetimes (deployment start to retrieval start), so the crew never does clock arithmetic and your window checks fire on the computed value.
• Marker uniqueness: a text field for the physical marker or float identifier, marked unique within the trip and released when an event is abandoned, so two active deployments can never fly the same marker.
• A working unit on entry: a depth field whose canonical storage is metric but whose entry box opens in the unit your crew works in; the stored value never depends on who typed it.
• An instrument position with a distance rule: a point field that warns when the reading was taken too far from the event’s start position.
• A specimen repeat group: one entry per animal worked during retrieval, with per-entry rules (a conditional maturity field, a sample-or-tag exclusivity check). See repeat groups.
• The assessment pair: whether the protocol was followed, and separately whether the data is representative, each with a reason list when the answer is no, plus a notes field required when the protocol passed but the data did not. Keeping these distinct is what makes the trip summary report’s abandonment and quality numbers meaningful.

Bind the stage and test

On Trips, then Workflow settings, add a stage, pick your survey type, and map the three convention fields (status, event number, station). Turn on per-trip numbering. When the live check reads clean, save, sync a device, and walk one event end to end: Start at a station, fill the first phase, advance the lanes, complete it, and watch it land on the trip page’s live board. The multi-stage trips guide covers that flow in detail.

Good to know

• Events are ordinary records: everything on this page is plain survey configuration, and review, conflict resolution, version history, and exports apply unchanged.
• Event numbers derive from the data on the device, so numbering works fully offline; two devices numbering concurrently can collide, and the boards flag the duplicate for review instead of silently renumbering.
• Editing the form mid-season is safe for additions gated with required-when; stored values for a field you later remove ride through edits untouched rather than being dropped.