Skip to main content
A submission is the unit of data entry in Terminus. You fill in one or more rows against a single taxonomy in a workspace, then move the submission through a fixed lifecycle. On approval, its rows become permanent records. Approval is final.

​
What it is

A submission is a batch of one or more rows of campaign metadata targeting one taxonomy inside one workspace. Each row holds the data for a single prospective record, with one cell per field in the taxonomy. You build a submission in the builder, where you can enter a single record in a stacked form or many records at once in a spreadsheet grid. That builder experience is its own concept: see Fill modes. A submission stages proposed data. Nothing it contains is governed or permanent until it is approved. Think of it as a draft change set that has to clear review (when review is required) before it lands.

​
What a submission targets

  • One taxonomy. A submission cannot mix taxonomies. To create records in two taxonomies, use two submissions.
  • One workspace. The submission lives in the workspace you create it in, and access follows your role in that workspace. See Workspaces.
  • One published structure. The form follows the taxonomy’s published structure (its fields, their order, and its dropdown rules), so what you fill in always matches what will be validated on save. If the governance model has no published version, you cannot create or save a submission against it.

​
The lifecycle

A submission has one of five statuses: 
draft  →  in_review  →  approved
draft  →  approved                 (when review is not required)
in_review  →  rejected
(any non-approved)  →  cancelled
  • Draft (the starting status): you are still editing. Every save cleans up your input, fills in computed fields, and checks the rules, but a draft saves even when rows have errors. Errors just mark the affected rows invalid.
  • In review (shown in the app as Awaiting review): you have submitted the rows for a reviewer to approve or reject. This status only exists when the taxonomy requires review in this workspace. The submission becomes read-only for you while it waits.
  • Approved: the rows have become records. This status is terminal and the submission is locked.
  • Rejected: a reviewer sent it back. You revise it (editing a row returns it to draft) or cancel it. A rejected submission has not produced records.
  • Cancelled: withdrawn before approval. Terminal, and it produces no records.
Review is required only when the taxonomy is configured to require it in this workspace. When review is off, there is no in-review step: a fully valid draft is approved directly. The full review flow, who can approve, comments, and the emails that go out, is covered in Review and approve submissions.

​
What approval produces

When a submission moves into approved, each of its rows creates or updates a record:
  • A row that is creating new data produces a new record.
  • A row that targets an existing record (the update flow) updates that record in place.
The record copies the row’s data and inherits the taxonomy’s published structure at the moment of approval. From then on, the record lives independently of the submission. See Records. Approval requires every row to be valid. If any row has an error or has not been re-checked since its last edit, approval is blocked and the submission stays where it was. Approval is the only step that turns staged rows into governed data, and it cannot be undone.

​
Validation

Each row is checked at three moments:
  • On every save, so you see field-level errors inline as you work. Draft saves succeed even with errors.
  • On submit for review, which requires every row to be valid.
  • On approval, which re-checks every row, so nothing slips through if something changed between submit and approve (for example, a dropdown option was removed).
Each field type enforces its own rules: required values, length and format constraints, uniqueness, and, for dropdowns, that the chosen value is a valid option (or a pending proposal on a picklist that allows additions). The check that happens behind the scenes on every save is described in The submission pipeline.

​
Naming

Every submission has a name. A new submission gets a meaningful default built from the workspace name and the date, like Paid Search, Jun 21, with a numbered suffix for same-day duplicates. You can rename a submission inline at any time.

​
Gotchas

  • Approval is final. Once a submission is approved, you cannot change its status or edit its rows. To correct approved data, create a new submission that targets the existing record (the update flow). Deleting an approved submission does not delete the records it already produced.
  • Editing after submit returns it to draft. Changing any row on a submission that is already in review or rejected sends the submission back to draft, and the changed rows must be re-checked (and, if review is on, re-submitted). This keeps mid-review edits from reaching a reviewer unseen.
  • Drafts save even when invalid. Saving never requires valid rows; only advancing the status does. A draft save can succeed and still report that some rows have errors.
  • Review is per taxonomy, per workspace. The same taxonomy can require review in one workspace and not in another. When review is off, there is no “submit then approve” step. A valid draft is approved directly. Turning review on is a paid-plan feature.
  • A row keeps its identity across the lifecycle. Each row gets a permanent identifier when it is first created. That identifier follows the row through draft, review, and into the record it becomes. It never changes.