Skip to main content
The pipeline is the path from data entry to a live record. The builder loads your taxonomy’s published structure, you fill in rows, computed fields and short-URL slugs fill themselves in, you submit, the submission is reviewed if your taxonomy requires it, and approval turns each row into a record and activates its short URL.
A submission does not become a record the moment you type into it. It travels a short path: you enter data, the product fills in everything that is derived, it checks the data, someone approves it, and only then do permanent records appear. This page walks that path end to end in the order you experience it.

​
The builder loads published structure

When you open the builder, it loads the fields, their order, and their settings from your governance model’s published revision, not from whatever an admin happens to be editing right now. That is deliberate: the form you fill in can never disagree with the rules the product will check your data against. One consequence to know: a governance model with no published revision cannot accept submissions at all. If you cannot start a submission, the model likely has not been published yet. See Publish a revision.

​
You fill in rows

You enter your data as one or more rows against the taxonomy. You can fill in a single record at a time or many rows at once, depending on the fill mode. Each row has one cell per field. You only fill in the user-entered fields; the rest fill themselves in (next section).

​
Computed fields and short-URL slugs fill in

As you type, the product fills in every computed field for you: concatenations, tagged URLs, auto numbers, random values, constants, the Terminus ID, the QR code, and the short URL. These fields are read-only. They recompute as their source fields change, so you see the finished output build up live. Computed fields can depend on other computed fields, which is how a deep chain works. In the Campaign URL Builder example: utm_campaign is built from campaign_name, goal, and launch_date; tagged_url adds UTM parameters to destination_url; short_url points at tagged_url; and qr_code is rendered from short_url. Fill in the fields at the top of the chain and everything downstream fills in on the next save. For a Short URL field, you also pick the slug. Depending on how the field is set up, the slug is generated for you, generated but editable, or typed in by hand, shown as a domain/slug input with a button to generate a fresh one. The slug you choose is stored with the row, but the short URL is not live yet. It is created and activated only when the submission is approved.

​
You submit

When your rows are ready, you save the submission. Saving works at every step:
  • Save as draft keeps your work without advancing it. A draft saves even if some rows still have errors, so you never lose progress.
  • Submit for review moves a draft into review. This option appears only when your taxonomy requires review in this workspace.
Validation runs on every save. Errors are attached to specific cells, not to the submission as a whole, so the screen highlights exactly which fields need attention. You can keep saving a draft with errors, but you cannot advance a submission until its rows are valid.

​
Review, if your taxonomy requires it

Whether there is a review step depends on the taxonomy and workspace:
  • Review required. A submitter sends the draft for review, and a reviewer (a workspace admin) then approves it or rejects it back for changes. There is no shortcut straight to approval in this mode.
  • No review. There is no review step. Whoever can edit the submission finalizes it directly.
If a submission is rejected, edit its rows and resubmit. Editing the rows of a submission that is not yet approved returns it to draft, so it goes through review again. See Review and approve submissions.

​
Approval creates records and activates short URLs

Approval is the finish line. When a submission is approved (by either path), each row becomes a record: the final, validated, permanent entry.
  • Approval requires every row to be valid. If any row still has errors, approval is blocked and the submission stays where it is until you fix them.
  • Each new record gets its stable Terminus ID (a trm0… identifier that never changes).
  • Any short URL on the row is activated and linked to the new record, so the link starts redirecting.
  • If a submitter proposed new dropdown options along the way (on picklists that allow it), those options are added at this point.
Approval is final. An approved submission is read-only and cannot be un-approved. To change a record later, you create a new submission seeded from it and approve that.

​
What to remember

The practical takeaway, especially when troubleshooting: the computed output is only as good as the input at the top of the chain. If campaign_name is blank in the Campaign URL Builder example, then utm_campaign, tagged_url, short_url, and qr_code are all blank too. You will see a single “required” error on campaign_name, not four downstream errors, and filling it in unblocks the whole chain on the next save. If you are designing a governance model, keep computed chains short where you can. A few levels is fine; ten levels is a sign to flatten or split, because every extra level is more surface for one missing source to cascade into blank fields downstream.