Registers

Keep the running logs your documents point at — exception logs, corrective actions, training records — as tables of records whose status says honestly whether they prove anything.

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.

Files attached to a register

A register can hold files — attachments on its rows, and the spreadsheet a register was imported from. These count towards your workspace's storage limit like anything else you keep, and an upload that would take you past it is refused before the file is stored rather than after. Deleting attachments gives the space back. See Seats and licences.

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. Its name obeys the same 120-character limit a document's does; every kind of record in that list answers to one number. Opening one gives you a table of records instead of an editor.

Status is the coloured dot in front of the name, not a column of repeated words: green while a record is active, grey once it is archived, red for a register we could not read. Hover the dot and it says which in words, and a screen reader reads it out — the colour is a shortcut, never the only way to know. The word is announced as its own part, separate from the code and the name that follow it, so a row is read as three facts rather than one run-on. To work by status rather than glance at it, use Filter → Status, which is also the only way to bring archived records back into view.

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.

Rows in that list are ordinary links. Clicking one opens it as you would expect, but you can also middle-click (the scroll wheel) or Ctrl-click (⌘-click on a Mac) to open a record in a new tab and keep your place in the list — the same gestures you use on any menu or search result. Hovering a record's name shows where it goes, and the list can be walked with the keyboard.

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. (The list holds documents and registers, and every column means the same thing on every row — the same code shape carrying the owning team, an owner, a version, and a name in the same column under the same 120-character limit.)

Create one with New on the Governance page and choose List from the Type dropdown in the create popup — it sits after Policy, Procedure, Instruction, Manual and Control, closing the list. You give it a name, and that is the whole form. (Inside a team, the register is created in that team and the popup does not ask; on All teams a team field appears, listing only teams you belong to, because a register is worked by a team and that is not a detail to leave to chance. See Creating documents.) 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.

A register is where forms and records belong. The create popup used to also offer a Form type and a Record type as documents; it no longer does, because that is this page's job. A form is a blank you fill in each time something happens — state it as a register's intake, so every submission arrives as a row. A record is the filled-in result — that is the row itself, countable, filterable and reportable in a way a document full of prose never was. Documents you already have of either type keep working exactly as before; only the door to making new ones has closed.

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 sets up for you, both come in shaped. The quickest way is to drag a spreadsheet onto the Governance page — an .xlsx or .csv becomes a register directly, with its columns typed from the values in them and its rows already in. You do not have to create an empty register first. See Creating documents. See Registers the assistant can propose.

Processes run from documents, not from registers: a document's process that listens for rows in a register shows its runs in the team's Activity, under the document's name.

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.
Dates in a spreadsheet come in as dates, wherever the file or the person opening it happens to be. A date cell is read as the day it names rather than as the machine's own way of writing that moment, so a column of dates types as a date column and a file imported in İstanbul and in London produces the same values. This is worth knowing because it once was not true on the other route into the app — a spreadsheet attached to a document or a control went through a different reader that wrote dates in the server's local wording, so the same file gave two answers depending on the door it came through. Both doors now read cells the same way. Files imported before this keep the values they were stored with; re-import if you want them re-read.
Bin — what this register is holding for you.

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 and an import 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 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. A review, when you ask for one, decides a version — never the live table.

In the history panel each version leads with its own label — v3 · Current, with the note beside it. The number lives on the version's row, never repeated in a sentence — and the panel itself is the same one every record kind opens: a document and a risk show this exact list, with the same header, filter and Restore.

Where versions come from

You do not issue one by hand — there is no button, and there is nothing to remember. A version is minted at the two moments when somebody actually stands behind the register:

When a review is approved. Submitting for review pins the register exactly as it stands and the approval publishes that pin, so the version an approver signed is the one readers get.
When somebody restores. Going back to an earlier version or an automatic copy records the result as a new version, in the name of whoever pressed it.

Everything in between is covered by the copies the register saves for itself, so nothing is ever lost for want of pressing something.

There is no number to pick. Versions are numbered the way documents are — the first is v1, and each one after it simply counts on: v2, v3, v4. 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".
Only a person can be behind one. Nothing issues a numbered version on a schedule, and the assistant cannot. A number nobody stands behind is the thing versions exist to replace — which is exactly why the register's automatic copies carry no number at all.

If two people land on the same moment, one of them is told plainly that somebody got there first. Nothing is lost and nothing is issued twice.

Asking for approval

A register can also carry a review. Opening one is a server verb, the same as every other record — called by integrations or administrative tooling today, and by the automation layer when it is connected; there is no Request approval button on the register. A submission issues a version — the same named bookmark as above — pinned for a team admin to stand behind. The admin decides on their My Approvals page; while the request is pending the register's own strip carries a status line saying who asked. The table stays open the whole time — rows, columns and shared forms keep working — because the decision is recorded against the version pinned at submit, never against the live table (see Issuing a version). The register's Activity states the outcome once decided.

What gets decided is the version, never the moving table. The reviewer approves or sends back exactly what the register held when you asked; everybody keeps typing in the live grid the whole time, and nothing they type changes what is being decided.
A banner above the table shows the open request — who asked and which version — until somebody decides or the requester withdraws it. One request at a time per register.
You can route the request to a person. The banner's Assign control asks a named teammate to look; they get a notification, and the request appears on their My Approvals list. Assigning never changes who may decide — that stays with team admins — it only says whose attention you want.
You see what you are deciding on. The request card carries View changes — the pinned edition against its predecessor, the same diff the version history shows. A first edition says so instead of pretending everything is an addition.
The ask and the answer both travel. Requesting a review tells the team's admins; the decision comes back to whoever asked, with the note if one was left — see Notifications.
You cannot approve your own request. The decision buttons only appear for a team admin who is not the person who asked — the same separation your documents' reviews enforce.
The decision is a permanent record. Approvals and send-backs cannot be edited afterwards; they appear in the register's activity, with the note the decider left.

The same request-and-approve flow is available on risks — one model, decided the same way everywhere.

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

Register editions are kept by the platform's one version store — the same engine behind a document's and a risk's versions — so the guarantees are the same database rules everywhere: an issued edition can never be altered, and only a person, never an automation, can sign one. An edition still records exactly who issued it, by name.

Where the register's own facts are

A register keeps its standing facts in Properties, a panel docked on the right edge and opened from the panel buttons in the register's top bar — the same place a document and a risk keep theirs. The panel only takes the space while it is open, so a register nobody is inspecting still shows its table at full width. (Until August 2026 those buttons stood in a 44-pixel column of their own down that edge; the buttons moved up into the bar and the column went, which is width the table now keeps. The panel itself opens exactly where it always did. This is also not the old always-open aside that was removed in July 2026: that one stood there whether you wanted it or not.)

The panel opens on the same five facts every record kind opens on — Code, Owner, Created, Type, Status, in that order, in the same rows. A fact this kind has nothing to say for reads as a dash rather than vanishing, so the panel you learn on a document is the panel you can read on a register.

Code — the LIST-… string everything else points at. It is not beside the name on the title line: the trail answers which register am I in, and identity facts live in the panel.
Owner — here and only here, the same as a document. It sat on the title line as well for a day; that made a register the one kind of record saying its owner twice on one screen, so it went.
Created — when the register was made.
Type — Register. A register has exactly one type, so the row can never read anything else. It is here because a reader comparing two records should find the same five facts in the same places, and a row that quietly disappears on one kind breaks that.
Status — whether the register is Live, Empty — unproven or Unreachable: the same verdict the title line carries, in the same words.

Cited by is no longer in this panel. It listed the documents whose text points at the register, and it was the one section here with no counterpart on any other kind of record. It is not lost: a citation has two ends, and the document end — Backed by / Cites on the document's own Details — is the end you act from, because that is where you are when you need to know what a sentence rests on.

The two are easy to mistake for each other, so plainly: Cites, in a document's Properties, is what that document points at, and you add to it there — press Add, or type / and use Mention. That is a live part of the app and always has been. Cited by was the mirror of it on the register — which documents point here — and it is that mirror, not the citing, that went. Citing a register from a policy works exactly as before.

How many records the register holds is on the table strip, which carries a count per tab, and on the totals row at the bottom of the grid for the table you are in. The title line does not repeat either.

History — one panel, opened from the top bar, holding everything that has happened to the register and every version somebody issued. … → Issue version adds one.

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

Reading the history, and comparing two versions

History opens on the register's right edge — the same edge a document and a risk open their panels from — and lists everything that has happened to the register, newest first. One feed, two kinds of entry:

Every version somebody issued, with its note and their name. A version can be ticked and compared against another.
Every recorded change, each with who did it and when: renames (what it was called before and what it became), description and owner changes, archive and restore, tables and columns and views added, renamed, retyped, moved or deleted, records added, edited, confirmed, deleted, imported and reordered, and the bin restored or emptied. A change cannot be ticked, because there is nothing to diff — the sentence is the whole fact.

The two sit in one list because "what has happened to this register" is one question. Above them all sits Live — the working copy — which is deliberately not numbered, because it is not a version.

There is one place to read this, and only one. Until recently there were three: this panel without the versions in it, a separate Open full history dialog with them, and a shorter per-table list behind the tab caret that knew only which rows had arrived and which had left. They disagreed about the same register — the same question asked in three places, answered in three different amounts of detail. They are now the one list described here, opened from the register's top bar.

Each change is a sentence from the same vocabulary every other record's history uses, so one kind of act reads the same wherever in the workspace you meet it. In particular, a register that has been deleted for good says so plainly rather than reading as an edit: that line is the last thing the register leaves behind, and it should not be easy to scroll past.

Two of those entries answer questions nothing else can:

An edited record shows the change itself — which column, what the cell said before, and what it says now. The grid only ever holds the current value, so this line is the only place an overwritten value still exists.
A deleted record stays in the history even after the bin is emptied. The bin is where the row can be recovered from; the history is where the fact of the deletion lives, with the record's name on it, and emptying the bin does not touch it.

The renames are here for a specific reason: the register's name saves itself as you type it and there is no cancel, so this list is the only place the previous name still exists.

The list keeps up with you. Leave History open while you work and each act appears in it as you make it — edit a cell and the line naming that column, its old value and its new one is there when you look up. You do not have to close the panel and open it again to see what you just did.

Tick Compare on two versions and press Compare in the bar that appears. The comparison opens as its own wide window — it needs the room, and it lists nothing, because the list is the panel you opened it from. It 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.

The register saves itself

You do not have to remember to keep a copy. As you work, Alchex keeps its own copies of the register — quietly, in the background, without anybody pressing anything. They appear in the history as lines like "12 changes, saved automatically", and each one can be restored exactly like a version you issued.

This matters because versions used to measure who remembered. A register edited every day for a month could hold three of them, and anything between them was gone. Now every stretch of work leaves something to go back to.

Two things are deliberately different about an automatic copy:

It has no version number, because a number is a claim and nobody made one. A version like v7 means a named person said this is the state I mean; an automatic copy just means the register looked like this then.
Going back to one is recorded in your name. The copy was nobody's statement, so returning to it is yours — it issues a new version, signed by you, exactly as any other restore does.

Copies are taken at most once every few minutes, so a busy afternoon leaves a readable trail rather than one line per keystroke.

One history, with a filter

Everything the register has been through lives in one place: the changes, the automatic copies, and the versions people issued, in one stream, newest first. The toggle at the top switches between All activity and Approved & named only — the same list, read two ways, so an audit reading is a filter rather than a different screen.

Restoring a version

Any version except the current one carries Restore, next to the word Superseded in the History panel. It puts the register back the way that version had it — rows, tables and columns together, including a column somebody deleted since and the values that were in it.

Two things about it are worth knowing before you press it, because neither is guessable:

Nothing is destroyed. Rows added after the version you are restoring do not disappear — they move to the register's bin, with everything in them, and Restore there brings any of them back. A restore you did not mean is undone by restoring the other version, and nothing has been lost in between.
A restore is recorded, not a rewind. It does not delete the versions that came after it. It issues a new version holding the restored contents, so the history reads v7, v8, then v9 (restored from v3) — an auditor can see that you went back, when, and who decided to.

Rows keep their identity through a restore. A row that existed in the version you restored is the same row afterwards — not a copy of it — so anything attached to the register stays attached, and the history of that row still reads as one continuous story.

Restoring needs the same permission as issuing a version, and an archived register offers no Restore at all — bring it back first. If the register already looks exactly like the version you picked, the restore is refused rather than recording a version identical to the one before it.

Where the history opens from

One door: the History button in the register's top bar, beside Properties and Comments — the same place a document and a risk open their own panels. It docks on the right edge and stays open while you work, so you can read the story and the rows at once.

There was briefly a second entrance to it on each tab's tool menu, left over from the older per-table list that used to live there. It is gone: a second way into a panel that already has a labelled button is furniture, not a way in.

Nothing in it is edited; it is a record of what already happened.

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 — 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, so the label and the first issued version line up; issuing after that steps it to v2, v3 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, and it is the same line a document and a risk carry — the same component, not a copy of the design. Until August 2026 the register's title line was drawn by the table software itself, which is why it never quite matched: same intent, different author, different type and spacing. It reads Governance / the register's name, and it holds everything the register says about itself:

its name, as the last step of that trail. Its code is not beside it — that is a Properties row now, so the line answers which register am I in and nothing else. The name is not a label with a rename button behind it — it is the field. Click it and start typing, exactly as you would rename a document from its own title. It saves itself a moment after you stop typing. There is nothing to submit, and for that reason nothing to cancel either — but nothing is lost either: every rename is written into the register's history, with what it was called before, who changed it and when. So a name typed by mistake is recoverable even after you have forgotten it. Nothing else moves when you rename: its code is what everything points at, so the documents citing it, the links you have shared and the searches that used to find it all keep working under the new name.
its status, worked out fresh from what is in it — the verdict as a word (Live, or Empty — unproven in red, or Unreachable), see below. It does not count the records: they are on the screen in front of you, and each tab already carries its own count.
an amber N suggested chip, when rows are waiting on somebody.
a small group of panel buttons, one per panel — Properties (the register's code, its owner, and every document that cites it) and Activity — separated by a thin rule from the … menu beside them. (A ✦ button stood there until September 2026 and opened the conversation about this register; it is gone, and the assistant is reached from the sidebar's Chat entry, where the ⌖ picker in the composer pins whichever record you mean.) The panel itself opens docked on the register's right edge, and one shows at a time: open another and it takes the space, exactly as on a document. A register nobody is inspecting shows its grid at full width.
a … menu on the right for what belongs to the whole register — issuing a version, Download for taking it away, and archiving it (or, on an archived register, restoring it). Download is the same entry opening the same window on every record kind — see Exporting. History is not in this menu: the panel button beside it owns it, and one door per surface is the rule on every record kind.

Who cites this register is in Properties, one press away in that bar — the answer to "may I change this?", listed in full rather than as the first name and a count.

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.

A re-read that only half succeeds keeps what it already had. The remarks on a row, the bin and the share links are read alongside the table, and if one of those reads fails — a moment of bad network is enough — the panel goes on showing what it was showing rather than emptying. An empty list is an answer about your register; a request that did not arrive is not, and the two must never look the same.

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 two states as every other row, shown as the dot in front of the record's name: Active (green) from the moment it exists, Archived (grey) when retired. One list, one two-state ladder — whether a register's records are confirmed is the citing chip's question, and whether a document has published is its page's; neither dresses up as a list status. The one exception is Unreachable, in red, for a register that lives in another system we could not read — an error, not a lifecycle state.

On its own page a live register carries one quiet word — Live — 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.

Retiring, moving and deleting a register

From the Governance list a register takes the same three actions every other record does — Move to team, Archive and Delete — on its row menu and in the selection bar. See Activity and archive.

When a bulk action skips a row, the bar quotes the reason rather than guessing it (2026-08-12). Select several records, run Delete or Move, and any row the server does not act on is reported as skipped with Alchex's own sentence for why — said once if it covers the whole selection, or listed if several apply. The selection clears when the batch finishes; Select the N skipped ticks the refused rows again if you want them. It used to print a fixed list of causes it had assumed, which was wrong for kinds those causes do not apply to.

Archive is still the ordinary retirement, and it stays reversible: the register leaves the working list keeping every record, column, view and version, and Restore brings it back.

You can archive and restore from the register's own page too, not only from the list. Archiving is in the … menu and asks you to confirm first; if it does not go through — most often because you do not have author rights on the register's team — the dialog says so and stays open, and nothing moves. An archived register's page carries a line across the top saying so, with Restore on the right of it, so a register you reached by following a link or a citation always shows you the way back rather than leaving you somewhere you cannot act. Restoring keeps you on the page you were reading. Delete is permanent, and nothing about being cited stands in its way — a reference is not a lock, the same rule that already governed archiving. What Delete is for is the register nobody needs any more: the abandoned import, the duplicate, the test one, which previously could only be archived and then sat in the Archived filter forever.

Being cited is still the reason to pick Archive over Delete, and it is a difference the reader feels rather than you: an archived register keeps its name in every chip citing it, so those chips go red and can be repointed, and restoring it clears them. A deleted register cannot be named any more, so its chips read as a restricted record — inactive, and with nothing left to rebind from. Deleting takes owner rights on the register's team; archiving takes author rights.

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 — but the list is not where you are told so. In the Governance list an empty register reads Active like any other live record; "does this actually prove anything?" is answered where the claim is made. Backed by on a document resting on it says so, and the chip in the document carries the aliveness dot (a citation of an empty register is still a citation of a live register); whether the claim is currently proven is answered where the records live, one click away.

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 verdict behind the register's Live / Empty — unproven word, and the totals row at the bottom of the table, both count confirmed records only — so a register full of unreviewed proposals counts as holding nothing. (The Governance list does not carry that distinction: its dot reads Active, because whether a claim is proven is asked at the citation, not in a list of records.)
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.

You can pin a register to a conversation. The ⌖ Focus the conversation picker in the assistant has a Registers tab beside Governance, Risks, Controls and Audits: pick a register there and the whole conversation is about it until you unpin it, instead of you naming it again in every question. Registers you can reach are the registers you are offered, and a register you archive while it is pinned keeps its chip rather than vanishing mid-conversation. See AI review and assistance.

It creates a new register for you. Ask for one, or write a document that cites a log you do not keep, and the assistant sets it up. Whether that happens straight away or waits for your go-ahead is your team's setting — see AI review and assistance — and either way the assistant says which of the two it is rather than calling a waiting register created. Once it lands, what you read is the receipt: the name, the columns, how many rows it seeded, with an Open register link straight to the table. The columns it chooses carry plain types — text, long text, number, date, a select list, a person, a checkbox — and can each carry a one-line description of what belongs in them; display formats (a currency symbol, a percent sign) are yours to pick in the field editor afterwards. A register you did not want is retired like any other — say so, or archive it from its own page. Before creating a second register it looks for one that already does the job, so you get one training log rather than two half-filled ones.

It adds rows to 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 the rows land the same way — at once, or on your go-ahead, according to the same setting — with the same receipt when they do.

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

Every row has to quote its source. The assistant may only write 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 write. A register that fills up with confident-sounding entries nobody ever wrote is worse than an empty one.
Its rows arrive suggested, not confirmed. The rows sit in the register with their quotes attached until somebody confirms them, and until then they count for nothing: if there is nothing else in there, the register is still holding no confirmed records, and every document citing it still says so.

The receipt is honest about 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.

When the assistant asks where records are kept, it reads your registers first and lists them in the question — answer by naming one (or asking it to create one), and the document ends up citing a real register rather than a phrase. A larger table comes in through the register's own import or by dragging the file onto Governance. See Templates and the marketplace.

The register's conversation

Press Comments in the register's top bar to talk about it — a suspect record, why something was confirmed, what still needs chasing. The conversation belongs to the register, not to a row: one list for the whole record, exactly like a document's, so nothing said about the register can hide behind one of a thousand rows. When a remark is about a specific record, say which — "the ACME row is stale" reads perfectly, and stays readable after the row moves or goes.

Type @ to name a colleague; the picker writes their name into the text and the line under the box says who will be notified. Answering somebody is writing the next message; nothing needs resolving or managing. Anyone who can see the register can comment on it; only the person who wrote a remark can edit or withdraw it (the ⋯ menu on your own words). See Comments.

Remarks left on individual rows under the old model were not lost — they moved onto the register, and read in its conversation in time order.

If a document cites this register, the assistant will have left a note in that document's Comments panel saying the register is still holding records 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 attachments 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:

Type	What it holds
Link to another record	The rows themselves, as named chips. Pick from a list of what is actually in the other table.
Lookup	A column of the linked rows, brought across to read here.
Count	How many rows this cell links to.
Rollup	One answer about the linked rows — a total, an earliest date, a highest number.

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. This view (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 names the view you are in on the left, and carries three buttons on the right — find, Settings and Add data. Everything that shapes the view lives in Settings:

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.

When a filter is hiding rows, the bar says so — "N rows filtered out", next to the buttons — and pressing it opens the rule that did the hiding, so rows never go missing silently.

The menu on the view's name holds the view's own housekeeping: duplicate it, share it, set its row height, or delete it (deleting warns you first when the view has live share links, because revoking those outlives undo).

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 table always keeps at least one view, so the last one cannot be deleted — the same rule as the last table on the tab strip, and for the same reason: there would be nothing left to look at the rows through.

A view does not have to be a table:

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 new view is born a grid. Boards are parked: every board you already have keeps drawing, switching and filtering exactly as before, but there is currently no control for making a new one or for turning a grid into one.

A form is not a view any more: it is not a way of reading the rows, it is a way rows arrive. What the form asks lives in Settings, and the public link to it is described under Collecting answers. Rows that arrive through a form are suggested, like everything else a machine or an outsider writes, and wait for somebody to confirm them.

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.

Settings — every decision about the table

The Settings button at the right end of the view bar opens the register's one decision surface. It holds six entries, and the first is the one most people come for:

Intake form — what this register collects, and who may answer it, on one page. The questions come first: each one is drawn exactly as the person filling it in will meet it, and its controls — required, a help line, drag to reorder, take it off the form — appear when you point at the question or tab to it. Under the questions sit the button's wording and what is said after submitting, and under those — over a hairline, with no heading of its own — is Public link and the switch that opens it. See Collecting answers.
Filter, Sort, Group, Colour and Fields — the rules that shape one view. Each starts with an Applies to picker naming the view the rule shapes, so you can manage every view's rules from one place without visiting each lens.

A question with nothing to pick says so. A single-select column whose list of choices is still empty cannot ask anything, and its row says which column it is rather than implying the whole form is broken.

There is no General section, and no Views list. Both were doors onto something that already had one: the table's name is renamed from its own tab (Tools → Rename), and views are listed, added and deleted from the caret beside the view's name on the bar. Nothing was lost, only de-duplicated.

The intake list drives every way in — the form somebody outside your workspace fills in, and what a colleague is asked for here — so changing it once changes them all. There is no separate form to keep in step with a separate column list.

A register set up before Settings existed keeps whatever its old form already asked — nothing stops working. The first edit made in Settings promotes that list to the table itself, and from then on there is exactly one definition. The same is true of a form link shared before the change: it keeps opening the register's intake, and revoking it works as it always did.

Beside Settings, Add data gathers the ways a row can arrive from outside the table under one menu — a file imported into this table, and more doors as they exist. Typing a row in place is not on the menu, because the table already has that door: the + New record row at the bottom of the grid. However a row arrives, the register holds it to the same intake.

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.

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 — open the menu on the view's name and choose Share 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.

There is nothing separate to build first. What the form asks is the register's intake — the definition Settings holds — and the public link lives in the same place, at the foot of the questions it opens: open Settings → Intake form, shape the questions, and the switch beside Public link at the foot of the page is what makes it public. The link belongs to the table, not to any view, so rearranging, renaming or deleting views never breaks it; it works for as long as you leave it on.

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 switch is off. Nothing is public until you turn it on. While it is off, the block says so in one line: 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.
While it is open, the block tells you how it is doing. One line under the address: when the link was opened, how many answers have arrived through this form, and that answering needs no sign-in. The ↗ beside Copy opens the form the way an outsider sees it.
Turning it off asks first, because closing is permanent. The confirmation names what you are about to lose — the address stops working for everyone who already has it — and what you keep: answers already collected stay on the register. Cancelling changes nothing.
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. This is the reason closing asks first, and the reason there is no undo: the old address is gone the moment you confirm.
The record of a closed link stays — that it was open, who opened it, and when it closed — for the same reason a withdrawn share link's record stays.

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 — the same form to two teams, each with its own name already filled in.

Build it rather than type it. Under the address, Prefill from the link opens a small builder: pick one of the questions this form asks, type the value, and decide whether to hide the question so nobody changes it. The finished address appears underneath, and Copy this link takes it. It only appears while the link is open — parameters for an address that does not exist are no use to anybody.

The address it builds looks like this:

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 — which is why the builder offers the questions instead of asking you to spell one. A mistyped column is silent: the form opens looking perfectly normal, with the answer simply missing.
Values with spaces or punctuation are escaped for you. Hand-editing is where that goes wrong.

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 and your remarks — is saved to your workspace and shared with your team.

One thing is worth stating plainly rather than leaving you to find out:

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. Citations sitting in archived documents are left out of the line and out of its count, because a retired document is not somewhere anyone can be sent.

Reviewing, exporting and retiring

There are two ways to get a register out, and they answer two different questions.

Everything a register can give you is in one place: Download, in the … menu at the top of the page. There is no second export button in the grid any more — the table's Tools menu used to carry its own Download CSV, and that file is now the first choice in the Download window instead.

It is the same window every record kind opens, and it holds two choices — what you are looking at, or the lot:

This view (CSV) — exactly what the grid is showing: the same columns, in the same order, with the rows the view's filters kept. Use it when the answer you want is what I am looking at right now. It is offered on a grid view and not on a form, which has no rows to write.
Workbook (Excel) — an .xlsx holding one sheet per table in the register, plus an Activity sheet: everything that has happened to it, newest first, with who did it and when. This is the whole register in one file, so it is what to send when somebody asks for the register rather than for one view of it. There is no separate whole-table CSV and no zip: each table is already a sheet in here.

Both files are named after the register, so a folder of them stays readable. Anyone who can read a register can export it: taking a copy of what is already on your screen is not a change to it.

What is not in either file, on purpose: rows in the bin. A deleted row is something you can recover, not part of what the register says — and a workbook containing rows your team deleted would be making a claim the register does not make. If you need one back, restore it from the bin first and export again.

The values are written the way you read them on screen: a choice column exports its choice's name, a person column exports their name, and a number keeps the precision its column is set to. A blank cell is blank rather than a dash.

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.

Read-only means read-only, not gone. An archived register's page still opens and still answers: its records, its columns and views, its versions, its Activity and its bin all read exactly as they did before it was retired. What it refuses is change — adding or editing records, adding tables or columns, reshaping views, issuing a version. That split is the whole point of choosing Archive over Delete, and it is what makes a citation still worth following: a chip pointing at a retired register takes you to the answer it was citing, with Restore on the line across the top when you want it working again.

A register a document cites can be retired, and nothing refuses. Documents point at registers — that is what a register chip in a document's text is — and retiring one used to be refused while any citation stood, with the citing documents listed first and a workspace admin able to override. All of that is gone. The removal simply goes through, and the citation says so where it is written: every chip pointing at the retired register picks up a red dot, keeps the register's name so a reader can see what was withdrawn, and carries Rebind for pointing the sentence at a live register. Restoring the register clears every one of those dots. See References.

That is the trade, stated plainly: the old refusal protected the document by sending you to hunt for chips first — often inside documents you had already retired. The red dot protects the reader instead, by never letting a claim look proven when the thing proving it has been withdrawn.

The Governance list retires a register under the same word: right-click the row and the action reads Archive, wearing a box rather than a bin and in ordinary text rather than red — it is reversible, and only the permanent action is red. It used to say Delete, which was never what it did. A register can also be deleted outright, from that same menu and behind its own red confirmation — see Retiring, moving and deleting a register above. The page's … menu offers only Archive, because retiring is the act you want from inside a register you are working in; permanent removal belongs where you are tidying the list.

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.

Role	Can
Reader	Read the register, its tables and its records. Nothing else.
Author	Everything a Reader can, plus create and rename registers, add and remove tables, add and edit records, confirm and dismiss, change columns, shape views, and restore from the bin.
Owner	Everything an Author can.

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