Registers

A Register is a list your organisation owns and Kiln keeps: your approved subcontractors, your vehicles, your sites. It is typed, it is governed, and the rest of the platform can refer to it. A flow can look a supplier up mid-run, a case can point at one of its rows, a document can render from it.

It exists because of a decision made elsewhere in the platform. A case’s log and a flow’s run history are append-only: they record what was decided and cannot be rewritten, which is what makes them worth anything. That same property makes them the wrong place to keep somebody’s mobile number, because an append-only record cannot honour a request to delete what you hold about a person. So those logs hold references, and a Register is the governed place the thing being referred to actually lives, and the one place in Kiln where deletion means deletion.

[Picture: Work › Subcontractors, the whole screen. Not yet taken.]

Declared once, worked every day

A Register is two jobs, and Kiln makes them two screens because they are usually two people.

Build › Registers is where a Register is declared: what its columns are, what sort of value each holds, which are sensitive, which may travel, which dates are worth watching. Authored once and then rarely touched.

Work › the Register itself is the rows. Add this morning’s twelve suppliers, correct the ABN somebody mistyped.

Whoever decides that the subcontractors list has an ABN column is usually not whoever adds this morning’s twelve subcontractors, and in an organisation of any size they are different people with different training. So they are different permissions, and a person who does both holds both, which is then a recorded decision about that person rather than a shape imposed on everyone.

The practical effect is the one that matters on a procurement team: the people who keep the list current do not need a developer, and do not need the person who designed it. They also cannot redesign it by accident.

What one row is

A column holds one sort of value, declared when the column is added: text, a number, money, a date, yes-or-no, an email address, a phone number, a link, or one value from a list the column itself defines.

The closed set is the point. A column that can hold anything is a column nothing can validate, total or search. A status column that offers “active”, “suspended” and “deregistered” is checkable; the same column as free text is three spellings of “suspended” within a month.

Each Register also declares what one of its rows is called: a subcontractor, a vehicle, a site. Kiln then uses your word wherever it would otherwise say “row”, down to the button that adds one and the dialog that edits one.

Columns can be marked Expected, and Expected is not a save gate. A row missing an expected value is still saved, and reads as missing. That is deliberate: a list you are part-way through building is more useful than a refusal, and a gap you can see is more useful than a row you were not allowed to create.

[Picture: the grid header row, showing each column’s kind and its markings. Not yet taken.]

Sensitive columns

This is the part to read before deciding who gets access.

A column can be declared sensitive, individually. “The subcontractors list is fine, but the site contact’s mobile is not” is the normal case, not the exception, so the decision is made per column rather than per list.

Someone without authority over a Register’s sensitive columns gets rows with those values absent, not blanked. There is no placeholder, no row of dots, no ”•••”. Every reader downstream behaves exactly as it does for a value nobody has filled in yet, which is a state the product already handles everywhere. A blanked value is still a value: something renders the placeholder, somebody screenshots it into a report, and the fact that a mobile number exists at all has leaked.

The column itself stays visible. Its header is still there, still marked sensitive. What is withheld is the contents, not the existence of the question. so a reader can see that the list holds contact details they may not read, rather than being shown a list that quietly pretends to be complete.

One limit to state plainly: authority over sensitive columns is granted across your tenant, not per Register. Someone who may read the sensitive columns of one Register may read them in all of them. Granting it for one list and not another is something Kiln’s authorisation engine already understands. It is the screen that does not offer it yet. Until it does, treat the grant as a tenant-wide decision, because that is what it is.

Who did what, and who looked

A Register keeps a change log beside it. Created, Updated, Destroyed, and Read, which is the one that makes a Register different from the spreadsheet it replaces. A change entry names the column as it read at the time, so history stays legible after somebody renames a column.

Reading the log is its own permission, held separately from reading the Register. A person who may look up a subcontractor’s ABN has no automatic business knowing which of their colleagues looked it up last Tuesday. Reading the log is itself not recorded, deliberately: an auditor’s own reads landing in the log they are reading makes the record harder to read the more closely anybody examines it.

The log respects the sensitive columns, and one limit belongs on this page rather than in an answer to a questionnaire.

Sensitive columns are omitted from the log too. A Read entry carries no values, only who looked and when. A Created or Updated entry carries the before and after of every column that changed, and the columns declared sensitive are left out of it for anyone who is not also permitted to read those columns off the row. Left out, not blanked: a placeholder would still say that the value changed and when. So the change log tells an auditor who acted, when, and on which row, without handing them what the log permission alone refuses them elsewhere. Someone who does hold the sensitive columns sees the history entire.

Entries recorded before this was built name their column but cannot be tied back to it, so they are shown only where a column the reader may see still carries that name. An entry about a column since renamed or removed is withheld rather than guessed at, which costs some old history and is the right way for the error to fall.

Reads by a flow are not recorded. Of the four things a flow can do to a Register, the two writes are logged and stamped with the run that made them; the two reads are not logged at all. So “who looked at this” is answerable for people and for connected systems, and not for automation. On a busy Register, automation is the highest-volume reader.

That one is a gap we intend to close rather than a position we are defending.

Destroying a row

Destroying a row destroys its change history with it. That is the point rather than an oversight: keeping “someone changed this person’s home address” after deleting the person is the same disclosure in a different table.

What survives is the fact of it: a record that a row existed and was destroyed, by whom and when, holding none of what it said.

It does mean the change log is not a complete record of a Register’s past, and anyone auditing you will ask. The honest answer is that the completeness was traded, deliberately, for the ability to honour a deletion request at all.

Destroying is a separate authority from editing, and not held by the people who keep the list current. It is the one act here with no undo and nothing left behind to reconstruct from.

Retention on the change log is undecided. It has no expiry today, because an expiry would erase the evidence of who saw what. A busy Register writes an entry per lookup, so this is a real decision before a production deployment, and it has not been made.

What a flow can do with one

Four operations, reached from a flow’s Integration node: look up one row, list a page of rows, write a row, destroy a row.

The ordinary shape is an invoice arriving, the flow looking the supplier up, and the flow branching before an approver ever sees it.

Reads are governed by a per-column declaration called “may travel”, and it is off by default. This is the control to understand, because it is the one doing the work.

A flow run keeps a permanent record of what its nodes received. So handing a value to a flow and writing it into a record that cannot be deleted are the same act. A Register therefore declares, column by column, which values are allowed to make that trip, and a Register that has declared nothing hands a flow nothing.

“May travel” is a different question from “sensitive”, and a column can be either without the other. Sensitive is about who may see a value. May-travel is about where it may end up. The usual answer for a home address is sensitive off and travels off: everyone who works here can look it up, and it never goes anywhere permanent.

When a lookup does not return a column, the flow’s node says which columns it did not receive and why, rather than handing back a silent blank.

Writes are gated a second time, by the Register’s own switch, also off by default. Being able to add an Integration node is not the same as being able to write to your subcontractors list. A mis-authored loop needs two separate things to be wrong before it can empty one.

A flow cannot claim to be somebody. The identity on a flow’s write is stamped by the engine and cannot be supplied by whoever authored the flow, so the change log records the flow and the run rather than a person. A call arriving without the engine’s stamp is refused outright rather than attributed to whoever happened to be signed in.

Watched dates

A date column can declare how many days ahead it wants to be noticed. An insurance certificate that expires in sixty days can raise a case while there is still time to chase the broker.

That is the argument for keeping the list in Kiln rather than in a spreadsheet: not that it is a better table, but that it can speak up. A spreadsheet of expiry dates is only as good as somebody’s reminder to open it.

A watch fires once per row per date. Moving the date re-books it; moving it back to a date already past does not re-fire for a crossing that already happened.

Pinning the ones you use

A Register can be pinned to its own item in your Work menu, opening straight to it. An organisation with twenty Registers usually wants three of them one click away, and only that organisation knows which three, so it is declared rather than guessed from usage.

What this is not

It is not a bulk import. Rows arrive one at a time, by hand or written by a flow. Safe staging of a bulk load into a live, governed list is a decision we have not made, and doing it badly is how a reference list quietly acquires four thousand rows nobody has checked.

It is not a Dataset. A Dataset is test data, used to prove a flow or a document behaves before you publish it. A Register is the real list, and the real list is not a test fixture.

It is not a Connection. A Connection reaches a system you already run, somewhere else. A Register is the list Kiln holds for you, which is exactly why it is the one place a deletion request can actually be honoured.