Skip to main content
When you click Build URL (or New record), you start a submission. The builder loads your taxonomy’s published structure, you fill in rows, computed fields and short-URL slugs fill themselves in, you create the records (or submit them for review if your workspace 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 latest 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. If an admin publishes a new revision while your submission is still a draft or in review, the builder uses the new revision the next time you open or save it. Once approved, a submission and its records stay tied to the revision they were approved under. 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, autofill values, 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. The builder offers two buttons:
  • Save as draft keeps your work without advancing it. A draft saves even if some rows still have errors, so you never lose progress.
  • The main button finishes the submission. Its label depends on the workspace and on what you are doing:
    • Create URL (or Create record for a taxonomy with no tagged URL, short URL, or QR code field; plural when there are several rows) creates the records straight away. This is what you see when the workspace does not require review for this taxonomy, which is the default.
    • Update URL (or Update record) appears instead when the submission edits existing records, for example after you select records on the Records page and click Edit.
    • Submit for review appears when the workspace requires review for this taxonomy. It moves the draft into review.
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. Two plan checks also run when a submission advances (never on a draft save): the number of rows one submission may turn into records (set by your plan), and whether the account’s plan includes automated picklists if the taxonomy uses one. If either check fails, your draft is kept and the builder shows a notice explaining what to change or who can upgrade. See Plans and limits.

​
Review, if your taxonomy requires it

Whether there is a review step depends on the taxonomy and workspace:
Requiring review needs the Business plan or higher. See Plans and limits.
  • 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 with Create URL (or Create record).
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. A submission that edits or deletes existing records updates or removes those records instead.
  • 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.
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. See Work with records.

​
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.