Registers

A document says what you do. A register is where you write down that you did it — the exception log, the corrective actions list, the training record, the access review. Your documents make claims; registers are what those claims rest on.

Where registers live

In the Governance list, alongside your documents. A register is a row like any other: it carries a code, a name, a status and a version, and its Type reads List — the same column that says Policy or Procedure on the rows around it, and the same word as its LIST-… code prefix. Opening one gives you a table of records instead of an editor.

Because Type is a column and not a badge, you can sort by it and filter to registers alone, and a register sorts by how recently it changed exactly as a document does.

There is no separate section for them, and that is deliberate: what your team governs is one body of record. Splitting it in two would make "what do we have?" a question with two answers.

Create one with New on the Governance page and choose the List card in the create popup. You give it a name, and that is the whole form. You do not design its columns up front — the register is created with a single column and you add the rest in the table itself, where you can see what you are shaping.

Owner reads Unassigned until somebody takes it. That is not a blank: a register nobody owns is something to fix, and the list says so in as many words rather than drawing a dash and leaving you to notice.

A register can also arrive with its columns already set: one you import from a file, and one the assistant proposes and you approve, both come in shaped. See Registers the assistant can propose.

Tables inside a register

A register holds one or more tables, shown as tabs across the top of the table area. A new register starts with one, named after the register itself, and most stay that way.

Reach for a second table when you are tracking two different shapes of thing that belong to the same body of record — the actions themselves and the checks that closed them, say. They are one register because one register is what a document cites; they are two tables because a row in each answers a different question, and forcing both into one table means half the columns are empty in half the rows.

• Add a table with the + at the end of the tab strip. One decision: a name. It arrives with a single column and you shape it from there, exactly as the register's first table did — there is no template to pick from, because the point is that you build what you actually track.
• Rename or remove a table from the caret on its own tab. A register always keeps at least one table, so the last one cannot be removed.
• Removing a table keeps its records. Like everything else here it is retired rather than destroyed, and you can bring it back from the bin.

Each tab carries its own record count, and an amber dot when that table holds suggestions waiting on somebody.

What the caret on a tab offers

Every tab carries the same menu, and it is the same on every table — a tool that exists on one table and not on another is a tool nobody remembers they have.

• Rename the table.
• Import into this table — a .csv, .tsv or .xlsx file. A workbook with several sheets is read whole and you choose which sheet to bring in, so data sitting behind a cover page is not quietly missed. (.xls, the format Excel used before 2007, is not read — re-save it as .xlsx first.) You match the file's columns to the table's, and rows that match an existing record on the column you nominate update it rather than arriving a second time. What the import did is stated afterwards, in full: how many rows it updated, how many it added, which it skipped because their key matched two records, which columns it had to create, and which lists of choices it grew. A file that quietly taught a column six new options is not something you should have to notice yourself.
• Import as a new table does the same thing into a table the file itself shapes.
• Record templates — shapes a new row can be born in, so a recurring piece of work does not have to be retyped. The shapes you author are saved with the register.
• Table history — everything that arrived in this table and everything that left it, newest first, with who did it and when.
• Automations — standing instructions on this table: when this happens, do that. They are saved with the register and run on our servers, so a colleague's edit and a scheduled sweep both work whether or not you have the page open. A scheduled one runs on the workspace's own clock (Settings → General → Time zone). See Automations.
• Find duplicates — rows that look like the same thing. See below.
• Bin — what this register is holding for you.

Finding and merging duplicates

Find duplicates reads the whole table, not the view you are in — a filtered view can hide one half of a pair, and a search that only looked at what was on screen would confidently report that there are none.

Choose the column to match on, and whether to match exactly or ignore case, spacing and accents. Each group it finds shows the rows side by side; you pick which row survives and, column by column, which value it keeps. Merge folds the rest into it.

Merging never launders a proposal into a fact: the surviving row keeps its own state, so merging two suggestions leaves a suggestion. The rows that go are retired the ordinary way and are in the bin if you want them back.

Taking something back

Undo works the way it does in any spreadsheet: Ctrl+Z (⌘Z on a Mac) takes back your last action, Ctrl+Shift+Z or Ctrl+Y brings it forward again. The history is the register's rather than one tab's — press Ctrl+Z after editing on one tab and it takes back whatever you last did, wherever you did it. There is no button for it, and there does not need to be.

One action is one press. A paste that filled forty cells, an import, and a merge each undo in one, and a row you have just created and named goes back as one row rather than as a nameless one.

Two things are deliberately outside it:

• Confirming a record cannot be undone. Vouching for a row is a signature, and a product that could quietly take one back on ⌘Z would have an audit trail nobody could rely on. Dismiss the row instead, which is recorded as its own act.
• Emptying the bin cannot be undone. That is what emptying means.

Undo is a working convenience and lasts as long as you have the register open. It is not the record of what happened — the table's own history is, and that only ever grows.

Versions: pinning what the register said

A register is a living list — you and your colleagues type in it all day. So when a document cites it, or an audit asks what it held in June, there has to be a way to say this is the list I mean. That is a version, and you create one by hand.

Issuing a version does not lock anything. There is no draft, no review step and no frozen copy. People go on working in the table exactly as before. Think of it as putting a named bookmark on a stream that keeps running, not as publishing.

Issuing one

From the … menu at the top of the page, choose Issue version. You get one dialog with one button.

• There is no number to pick. Versions are numbered the way documents are — the first is v1.0, and each one after it is v1.1, v1.2, v1.3. That is deliberate: a register and a document sit in the same list under the same Version column, and one vocabulary across both is worth more than the ability to declare a change "major".
• The note is optional. One line about what changed in this version, up to 500 characters. A version with no note is perfectly normal.
• Rows nobody has confirmed are included, and the dialog says so. If the register is holding suggestions, you are told how many before you issue. They are not excluded and you are not made to deal with them first: the version records what the register held, and quietly leaving proposals out would under-report it. What they never do is count as proof — the status still ignores them.
• Only a person can issue a version. Nothing issues one on a schedule, and the assistant cannot. A number nobody stands behind is the thing versions exist to replace.

If two people press the button at the same moment, one of them is told plainly that somebody got there first. Nothing is lost and nothing is issued twice — read the history and issue again from where the register now stands.

One version covers the whole register

A version pins every table in the register at once, never a single tab. A citation rests on the register, so Access exceptions v1.1 has to resolve to one state of one body of record — if each tab carried its own number, following a reference would be ambiguous the moment two tables referred to each other. History and comparison can still be narrowed to one table, which gives you the per-table answer without inventing a per-table number.

Where the register's own facts are

A register has no right-hand panel. A document does, because a document is read; a register is worked, and the work is the table — so the table gets the width instead.

Its facts are on the title line and in the … menu:

• Who owns it — named on the line under the register's title, beside its status.
• How many records — part of the status itself, which counts every table in the register rather than the tab you happen to be on.
• Cited by — the documents whose text points at this register, on the title line, ending in · evidence. That tail is not decoration: citing a register in a document's text and filing it as evidence backing that document are one act recorded once, and the line says so where you would otherwise be tempted to attach it a second time by hand. It names only the documents you can open: a register can be shared with people who are not on the team that owns a document citing it, and naming that document would tell them the title of something they have no access to. So the line can be shorter than the true number of citations, and a reader on another team may see a different list from yours. Nothing appears if nothing was found, which is not a promise that nothing exists.
• History — … → Open full history for every version issued, and … → Issue version to add one.

How many tables it holds is the tab strip, which you are already looking at.

Reading the history, and comparing two versions

Open full history lists every version, newest first, with its note and the name of the person who issued it. Above them sits Live — the working copy — which is deliberately not numbered, because it is not a version.

Tick two and press Compare. The comparison always reads older → newer, whichever order you ticked them, and it is laid out the way a table diff has to be:

• Structure first. Columns and tables that were added, removed, renamed or retyped are read before any rows. If a column was renamed and another stopped being free text, every row below reads differently — putting the rows first would make the whole thing noise.
• Then rows, with only the cells that actually moved shown as old → new. Rows are matched by identity, never by position, so sorting or dragging a row is not a change.
• Marks, not just colour. + added, − removed, → changed, ≠ retyped. The comparison is fully readable with no colour at all.
• Filter by table at the top. Every table is listed, including the ones where nothing happened — silence is stated rather than implied.

What the Version column says in the Governance list

The Version column shows the last version somebody issued. A register nobody has issued a version for reads v1.0 — the same birth label an unpublished document carries, which is the point: one body of record, one vocabulary. The first version you issue is v1.0, so the label and the first issued version line up; issuing after that steps it to v1.1, v1.2 and so on.

The top of a register's page

A register's page is the table. It takes the whole area beside the app menu — the table grows to fill the window and scrolls inside its own frame, so the page itself never scrolls and the totals row stays where you can see it.

Above the table sits one line — Governance / the register's name — and below that a single band carrying everything the register says about itself:

• its code and its name, side by side. Click the name to rename the register in place; Enter saves, Escape throws the change away.
• its status, worked out fresh from what is in it — see below.
• an amber N suggested chip, when rows are waiting on somebody.
• Undo and Redo, which cover the whole register rather than one tab — see Taking something back.
• Ask Alchex, as an Æ button. On every other page the assistant rests as a floating capsule in the corner of the window; here it sits on this line instead, because the corner of the window is the corner of the table — the totals row and the scrollbars — and nothing should be floating over it. It opens the same conversation, and ⌘J (Ctrl+J) still works from anywhere.
• a … menu on the right for what belongs to the whole register — issuing a version, opening the full history, and archiving it.

Who cites this register sits on the same line, after its status — the answer to "may I change this?", where you are already looking.

It catches up on its own

A register is worked by a team, so the page re-reads it in the background every few seconds. A row a colleague adds, a cell they change, a table they rename — it arrives in the table in front of you without a reload and without your pressing anything.

It never interrupts you to do it. What you are typing is yours until you leave the cell, and a background read that arrives in the middle of an edit is discarded rather than allowed to overwrite you. When nothing has changed, nothing happens at all.

There is no Add record button up here, and that is deliberate. Rows are added in the table itself, where you can see where they land — a button above the table could only ever put the row at the bottom, and rows added from up there had a habit of staying blank.

What the status means

A register's state is worked out fresh each time from what is actually in it — never a value somebody set and forgot — and each surface says the part of it that surface is for.

In the Governance list it uses the same words as every other row: Draft while the register holds no confirmed records (nothing anyone has vouched for yet — the same amber as an unpublished document), Current once it does, Archived when retired. One list, one status ladder; a filter for "Draft" finds every kind of unfinished record at once. The one exception is Unreachable, in red, for a register that lives in another system we could not read — "we could not read it" is not a lifecycle state and never dresses up as one.

On its own page a live register carries one quiet line — Live · N records — and an empty one carries no status line at all. The table underneath already says it holds nothing, and a page you opened to fill in does not need to lecture you first.

The state covers the whole register, not the tab you happen to be looking at. A document cites the register, so the claim it makes rests on everything inside it; a status that changed as you clicked between tabs would be answering a different question from the one the citation asked. The numbers on the tabs are there to help you navigate, not to prove anything.

An empty register is a problem, not a blank slate — and the place that says so is the claim itself. The [[…]] chip in a document citing an empty register carries a red dot, and hovering it reads "This register holds no confirmed records — the claim citing it is unproven." That is where the warning belongs: a reader deciding whether to believe a sentence sees it without opening anything, which is the question they actually have.

Suggested and confirmed

Every record in a register is in one of two states.

• Suggested — a proposal. It shows with an amber wash, an amber dot in the row's left margin, and a Confirm / Dismiss pair that appears when you hover the row.
• Confirmed — somebody looked at it and vouched for it. Their name and the moment are kept with the record.

The dot sits in the margin rather than beside the record's name, and hovering it tells you who proposed the row. That margin is the one part of a row that carries no data, so marking a proposal there costs the record's own name no width — and the Confirm / Dismiss buttons are given room of their own instead of covering the name you are being asked to vouch for.

Which one a record starts in depends on who wrote it. What you type is confirmed straight away — you added it, so you have vouched for it, and you are not asked to say so twice. The same goes for rows you bring in through an approved import: you chose the file and approved the columns.

What a machine writes arrives as a suggestion. Rows proposed by the assistant, pulled in by a connector, or submitted through a form wait for somebody with standing on the register to confirm them. That is what lets "12 confirmed records" mean something an auditor can rely on: every one of them was looked at by a person.

A row the assistant proposed keeps the words it was read from — open the record in full and the source is there beside the values. Confirming it is therefore a check against a quotation, not a guess about where the row came from.

Two consequences follow, and they hold everywhere:

• Suggestions are never counted. The status and the totals row at the bottom of the table both count confirmed records only. A register full of unreviewed proposals still reads Empty — unproven.
• Amber always means "nobody has vouched for this yet". It is used for that and nothing else — never for a status.

When a register holds suggestions, an amber N suggested chip appears beside its status, so a review queue is never something you have to go looking for.

Registers the assistant can propose

Ask Alchex can work with your registers, and does three separate things with them.

It reads one to answer a question. Ask what a log holds — how many people still owe the awareness training, which exceptions are still open — and the answer comes from the register itself. It counts the way this page does: confirmed records only, so it will tell you a register is empty rather than counting proposals nobody has vouched for.

It reads one table at a time, and tells you which. On a register with several tables it opens the first — the same table its proposed rows land in — and will say so rather than blurring the tabs together; ask about another by name and it opens that one instead. The status it quotes is still the whole register's, because a document cites the register rather than a tab.

It proposes a new register. Ask for one, or write a document that cites a log you do not keep, and the assistant offers to create it. The proposal arrives as an approval card — Create a register — listing the name, the columns, the review cadence if you named one, and any rows it wants to seed. Nothing exists until you choose Approve & create register. Before proposing a second register it looks for one that already does the job, so you are offered one training log rather than two half-filled ones.

It proposes rows for a register you already have. Tell it something that belongs in a log — that somebody finished their training last Tuesday, that a temporary exception was granted — or point it at a document that contains entries the register is missing, and it stages an Add rows to a register card. Approve it and the rows land.

Two rules hold on both proposals, and they are the point of the feature.

• Every proposed row has to quote its source. The assistant may only propose a row it actually read somewhere — in a document, in a file you attached, in something you told it — and the row carries those words. A row it cannot quote is a row it is not allowed to propose. A register that fills up with confident-sounding entries nobody ever wrote is worse than an empty one.
• Approved rows arrive suggested, not confirmed. Approving the card means "yes, write these down", not "yes, these are proven". The rows sit in the register with their quotes attached until somebody confirms them, and until then they count for nothing: the status still reads Empty — unproven if there is nothing else in there.

The card tells you afterwards what landed — Created the register "Training Log" with 4 suggested rows — and names anything it had to leave out, such as a value that referred to a column the register does not have. Open register takes you straight to the table to work through the suggestions.

You can also import a table when the assistant asks you where records are kept: choose a CSV file, its first row becomes the columns, and the rows come in confirmed — you chose the file and you saw what was in it. Imports from that card take up to 50 rows; bring a larger table in from the register itself. See Templates and the marketplace.

Remarks on a row

Expand a record and you can leave a remark on it — what a row means, why it was confirmed, what still needs chasing. Type @ to name a colleague; the picker offers everyone in the workspace.

A mention is stored as a link to the person, not as the text of their name, so it keeps pointing at the right colleague after somebody changes how their name is written. If a mentioned person later leaves the workspace, the remark still reads with the name they had — it does not decay into an identifier.

If a document cites this register, the assistant will have left a note in that document's margin saying the register is still holding rows nobody has confirmed. Confirming the last one closes that note by itself, with a line explaining why — see Comments.

Working in the table

The table behaves the way a spreadsheet does. Click a cell to select it and type to replace it; Enter or F2 to edit in place; arrow keys and Tab to move. Select a range and copy it, and it pastes into your spreadsheet program intact. Space opens a record in full, with every column and where the record came from.

• Add a row with the + at the bottom of the table, the + on a row of its own, or the right-click menu — each of which puts the new row exactly where you asked for it. An empty register offers the same thing in the middle of the table, so the first row is never something you have to go looking for.
• Drag a row by its handle to move it, and drag a selection to move the block together. Where a row sits is data here — it decides what somebody reads first — so the order you leave is the order everyone else finds.
• The first column is frozen and is the record's name — it stays put while the rest scrolls sideways.
• Add a column with the + at the right end of the header row. Click a column's own header to rename it, change its type, or delete it. Changing a type converts what can be converted and drops what cannot; deleting a column deletes what was in it.
• A column that holds people picks from everyone in your workspace — the same roster the @ menu in a remark offers. It is a directory rather than free text, so a name in one of these columns is a colleague the workspace actually holds.
• The bottom row totals whichever columns you have asked a question of — a count, a sum, an average — over the confirmed records.

Attaching files to a record

Add an Attachment column and a row can carry files — the photograph of the damaged pallet, the signed acceptance, the screenshot somebody sent you. Drop them on the cell, or open the record in full and add them there. The files are kept in your workspace: come back next week, on another machine, and they are still there and still open.

Each file shows as a chip carrying its name, its size and its type; images show a thumbnail instead. Clicking one downloads it under the name it arrived with.

• Up to 25 MB per file, which is the same ceiling as evidence elsewhere in the app. A file over it is refused and named — you are told which of the files you dropped did not land, rather than left to count the chips.
• Drop several at once. One file being refused does not lose the rest of the batch.
• Web pages and drawings that can carry scripts are not accepted (.html, .svg). Save a picture of one instead.
• Files count towards your workspace's storage. An upload that would take you over what your plan holds is refused before it is stored, rather than after.

Removing a file from a cell does not destroy it. It is taken out of the row, and Undo puts it back — working, not as a broken link. That is the difference between removing an attachment and emptying the bin: only the second one is final.

Pointing somebody at one row

Open a record and Copy link puts an address on your clipboard that opens that row, in that table, on that register. Paste it into a message, a ticket or a document and whoever follows it lands on the record itself rather than on the register with instructions to scroll.

The address is built from identities rather than positions, so it keeps working after somebody sorts, filters or re-orders the table. Someone who follows it needs the same access they would need to open the register the ordinary way; a link is not a way in.

Columns that point at another table

When a register holds more than one table, a column in one can point at rows in another. This is what stops you retyping the same thing in two places: the action's row names the check that closed it, rather than repeating the check.

Add the column the usual way and pick one of four types:

The last three all read through a link column, so add the link first — the other three are not offered until there is one.

Three things worth knowing:

• Nothing is copied. A lookup, a count and a rollup are worked out each time you read them, so they cannot go stale. Rename a row in the other table and every chip pointing at it reads the new name immediately.
• The download agrees with the screen. A Download CSV of a view holding these columns writes the linked rows' names, not their internal ids — the file says what the table says.
• A link points one way. The table you point at does not grow a column back pointing at this one; if you want to read the relationship from both ends, add a column on each side.

Pointing at a row that is later removed shows nothing rather than an error, so a table stays readable while you are rearranging it.

Views: how you are looking at the table

The bar above the table shapes what you see without changing what is there. On the left is the view you are in; on the right are the controls that shape it.

• Filter narrows to the rows that match. Sort orders them. Group collects them under headings.
• Colour tints rows by a column or by rules of your own.
• Fields hides columns you are not using and reorders the rest.
• Σ asks a question of a column — a count, a sum, an average — and the answer appears in the bottom row.

Everything you set here is saved. Come back tomorrow, on another machine, and the table is shaped the way you left it — and so is it for everyone else on the team, because a view is a decision about how this table should be read rather than a private preference. Column widths and collapsed groups are kept the same way.

Keep more than one shape of the same table by making another view from the view menu: "Everything", "Still open", "Mine this month". Switching between them changes nothing about the records.

A view does not have to be a table. The same menu offers two other shapes of the same rows:

• A board stacks the rows by one column's own values — the states of a corrective action, say — and you move a card between stacks to change that value. The one axis you cannot drag across is suggested/confirmed: vouching for a row is something a person does deliberately, not a side effect of dragging a card.
• A form asks an ordered subset of the columns and turns each submission into a record. Rows that arrive through a form are suggested, like everything else a machine or an outsider writes, and wait for somebody to confirm them. A submission also sets off the table's automations — a rule watching when a form is submitted (or when a record is created) runs on it the moment it lands, so an intake form can notify somebody or stamp the row without anyone watching the register.

The one thing that is not saved is the amber N to review toggle beside the view's name. That narrows the table to rows nobody has vouched for yet, and turning it off puts the table straight back — it is a ten-second question, not a decision worth keeping.

Find sits on the same bar, because finding is a question you ask of the view you are looking at: it searches the rows the current view is showing, and jumps you between matches without changing what is on screen.

The bin

Nothing in a register is destroyed, and the bin on the tab strip is where the things you have removed are kept — dismissed suggestions, retired records, and removed tables. Each entry says what it was, who removed it and when, and Restore puts it back.

The bin lists what is missing. Something you have already restored simply stops appearing, so nothing can come back twice.

Things stay in the bin until somebody empties it. There is no expiry date and nothing sweeps it on a timer, which is why each entry reads Kept indefinitely rather than naming a day it will disappear. A register you removed a row from last year still has that row.

Empty forgets everything in it, for good. It is the one action in a register that destroys something, so it is the one action Undo cannot take back — and it is the only thing that ever closes the window.

Sharing a view with someone outside your workspace

An auditor is the one reader who is not a member of anything. They need to see one lens on one table, for a fortnight, without an account and without the ability to touch a single value. That is what a share link is.

• Create one from a view. The link opens that view, read-only. Give it a label so you can tell your links apart later — the label is for you and is never shown to whoever holds the link.
• Give it an expiry, or don't. A link can stop working after 7, 30 or 90 days, or carry on until you withdraw it.
• It is a window, not a copy. The link shows the view as it stands now — narrow the view's filter this afternoon and the person holding the link sees less this afternoon. Rows the view hides never leave your workspace at all.
• Revoke it at any time. The link stops working immediately, and the record of it stays: who made it, when, and when it ended. That is the question an audit asks, and a deleted row would answer none of it.
• A withdrawn or expired link lands on a plain page saying the link no longer works. It never asks the holder to sign in and never says whether the link ever existed.

The person holding a link sees the rows the view keeps and nothing else — no other table, no other register, no navigation into your workspace.

Collecting answers from outside your workspace

A share link lets somebody read one view. A form link is the other direction: it lets somebody answer one form, and never shows them a single row.

Make a form view first (the view menu, "New form"), decide which columns it asks for and in what order, then open Share form… from the view's ⋯ menu.

The builder saves as you go. Its title, description, button wording and thank-you message have no Save button — each is written when you click out of the box, press Enter, or close the panel, the same way the question rows beside them already worked. The preview on the left updates as you type, so what you see is what has been kept. The same is true of a record template's name and description.

• "Public link — anyone with the link can submit" is off. Nothing is public until you turn it on. While it is off, the form works exactly as it always has: only people who can already write to the table can fill it in.
• Turning it on gives you an address to copy. Put it in an email, a signature, an intranet page or a poster. Whoever opens it sees your workspace's name, the form's title and description, and the questions — and nothing else. There is no sign-in, no navigation, and no way to reach anything else in your workspace from it.
• Turning it off closes the form immediately. The record of it stays — that it was open, who opened it, and when it closed — for the same reason a withdrawn share link's record stays.
• Turning it back on gives you a new address. Re-opening a form is a new decision, not the resumption of an old one, so a link somebody screenshotted last month does not come back to life.

What arrives, and where it waits

Every response lands as a suggested record, exactly like anything else written by someone who is not vouching for it. Nobody outside your workspace can add a confirmed record, and there is no setting that changes that.

Responses are counted by the amber N to review chip above the table, and — this is the part worth knowing — that chip counts the whole table, not the view you happen to be in. A response that your current filter would hide is still counted, and the chip says how many of them the filter would not show. Nobody vouches for a row they cannot see, so a response cannot go quiet behind a filter.

Whoever the register is assigned to gets a notification when a response arrives, carrying the response's reference. If the register has no owner, it goes to whoever opened the public link.

The person filling it in gets a reference

After a successful submission the confirmation screen shows Your reference and a short code. It is worth quoting in a follow-up email — it is what lets you find their response among the others. It is not a password and opens nothing. The reference names the row that was actually written to the register, so the code a submitter quotes and the record a reviewer opens are the same thing.

Answering a question from the link itself

You can put answers in the link, which is how one form serves several audiences without you making several forms:

https://alchex.com/f/<link>?prefill_Region=EMEA&hide_Region=1

• prefill_<Column>=<value> fills that question in for whoever opens the link. They can still change it.
• hide_<Column>=1 also hides it, so nobody is asked. The value is still recorded.
• The column is named exactly as it appears in your table (capitals and spaces do not matter). A name your table does not have is ignored rather than guessed at.

Questions that point at another table

A form can ask somebody to pick from another table — the systems in your systems list, say. On a public form, that means whoever holds the link can see the names of the rows in that table, because they have to be able to choose one. Nothing else about those rows travels: not their other columns, not their values, not the table's own name.

That is a real disclosure and it is worth a moment's thought. If a table's row names should not be seen outside your workspace, do not put a question pointing at it on a public form — an ordinary text question and a person matching answers up afterwards costs you a few minutes and gives away nothing.

What a public form never has

• No file uploads. A form open to the public cannot accept attachments.
• No people picker. A question asking for a person shows nothing to choose from, because your colleagues' names are not something a link hands out.
• No rows, ever. There is no view, no total, no count and no way to ask what is already in the table.

If a link no longer works

A closed, expired or unknown form link lands on a plain page saying so. It never asks the holder to sign in, and never says whether the link ever existed.

What is saved, and what runs only while you are here

Everything on this page — records, columns, tables, views, row order, versions, the bin, the files attached to a row, your record templates, your remarks and your automations — is saved to your workspace and shared with your team.

Two things are worth stating plainly rather than leaving you to find out:

• Automations are saved, and they run whether or not you are here. The instructions you write down are kept and are there when you come back. They run on our servers, so a colleague's edit fires yours, and a scheduled sweep runs at its time with nobody looking. Every run is recorded and readable afterwards. A new automation is off until you have tested it — see Automations.
• If an automation cannot be saved, the page says so. The instruction goes back to the way it was and a line appears at the top of the register explaining why. It is never left sitting in the panel looking saved when it is not.
• Suggestions the assistant drafts into a cell are for the sitting you are in. Accept one and it becomes an ordinary value, saved like any other. Leave it, and it is gone when you reload — an unanswered machine guess is not something worth keeping a week.

Citing a register from a document

A register is worth keeping because documents point at it. In a document's text, type [[ and pick the register — the same menu that finds your documents. See References.

Writing that reference does two things from one act, and this is the whole reason registers and documents live in the same list:

• The chip appears in your sentence, carrying a coloured dot for the register's status — so a reader of the document can see whether the claim is currently proven without opening anything.
• The register is filed as evidence backing that document. You do not attach it a second time by hand.

The register's own page shows the other end of it, on the line under its title: every document that points at this register, each one a link to the claim that rests on it.

That line is the reason an empty register matters. An empty register nobody cites is untidy. An empty register three documents cite is a finding — and now you can see which it is from the register itself.

If nothing cites a register, no line appears. That is deliberate: it means nothing was found, which is not the same as a promise that nothing exists.

Reviewing, exporting and retiring

Download the table from the view's own menu — the one named after the view you are in, on the left of the bar above the table. Download CSV writes exactly what that view is showing: the same columns, in the same order, with the rows it kept. It sits with the view rather than at the top of the page because the view is what decides what ends up in the file.

Archive is in the … menu at the top of the page, because retiring is a decision about the whole register rather than about the view you happen to be in. It disappears from the Governance list and becomes read-only. Nothing is deleted: every record it held stays answerable, because a register somebody once cited must still have an answer afterwards.

A register something still cites cannot be retired. Documents point at registers — that is what a register chip in a document's text is — and retiring one out from under a document would leave that chip pointing at nothing, in a record an auditor reads next quarter with nobody watching. So before it goes, you are shown what depends on it: the documents that cite it, named and openable, and a plain line saying whether anything outside your teams cites it too. Remove those citations first and the register retires normally.

Two things follow from that, and both are deliberate:

• You are never told the name of a document you could not open anyway. If a register you own is cited by a document on a team you are not on, you are told that it is — not what it is called. A workspace admin can see the whole picture.
• A workspace admin can retire it anyway. When there is genuinely no other way, an admin can confirm the removal despite the citations. It is written to the workspace's audit log — who did it, which record, how many citations it broke, and any reason they typed. It is a decision on the record, not a way around one.

Dismissing a suggestion works the same way. It leaves the table, but it is not destroyed — "what happened to that row?" keeps an answer.

Who can do what

The same two layers as documents: your workspace role, and your role in the team that owns the register.

Workspace owners and admins are treated as team owners for registers in any team, exactly as they are for documents. Full detail in Permissions.