Actions and activity

Break a record's treatment into steps that each have an owner, a date and their own thread — and read one running account of everything that happened to it.

A record says what is wrong. Actions are what you are doing about it, one step at a time, each with a person's name against it and a date. Below them, one activity thread carries both the conversation and everything the record did — in the order it happened.

Open any record under Risks and both are on the page, directly under the description — nothing sits between them any more. The linked-documents-and-evidence editor that used to occupy that space has been removed; where a record came from is a link in the properties rail now. See Risk records for the record itself.

Actions

An action is a step of the treatment. It has a title, a status, an assignee, a date, and a thread of its own.

Every action carries a code derived from its record'sRSK-014-A3 is the third action on record RSK-014. You can cite an action in a meeting, in a document or in an email and it points at exactly one step of exactly one record. The numbers are handed out by the workspace, never by the browser, so two people adding an action at the same moment can never mint the same code.

Adding one

Add action opens a composer as a row in the list rather than a dialog over it. Type what has to happen, and before you commit it you can also:

  • Assign it — click Assign and pick somebody. An action can be born already assigned, which is the normal case.
  • Give it a date — the Due control beside the assignee.

Enter commits the action and keeps the composer open, with the assignee still set. The reason somebody adds four actions in a row is usually that they are all for the same person, so you type, Enter, type, Enter. Escape closes the composer and throws away what you had typed.

A record with no actions yet says so and offers Add the first action rather than showing an empty table.

Working through them

Each row shows a state glyph, the action's code, its title, its date and its assignee.

  • Click the row to open the action in a side panel — its status, assignee and date as chips across the top, the full text, and its own conversation.
  • Click the assignee avatar to reassign it without opening anything. The avatar is its own target precisely so that putting names against a list of five steps does not mean opening five things. An unassigned action shows a dashed ring, which is an invitation rather than a badge that says nobody.
  • Change the status from the chip in the side panel: Todo, In Progress, Done or Canceled.

Progress, and what folds

Beside the Actions heading is the count — 2 of 5 done. The same number is the Actions column in the register list, so you can see how far a record's treatment got without opening it.

Canceled actions leave the count entirely. A plan that dropped two steps has not become two-fifths less finished; it has become a smaller plan, and a progress line that said otherwise would punish somebody for tidying up.

Finished actions fold behind a "N done" line in two situations: when the list has grown past about seven steps, and when every step is finished. A long list buries its live rows under its dead ones, and a short list of nothing but ticks is a result rather than a plan. Nothing is hidden permanently — one click brings all of it back, and canceled steps never fold, because a step somebody stopped is a decision and filing it under the word "done" would misfile it.

Dropping a step

A step you decided not to take is set to Canceled, not erased. It stays in the list with its own faded glyph, it leaves the progress count, and the moment somebody stopped it is in the thread — which is the answer to "why is this not on the plan any more?" months later.

The activity thread

Under the actions is one stream: what people said, and what the record did, in the order it happened.

They are together on purpose. The surface this replaced kept the record's versions on one tab and conversation on another, which meant the reason for a change and the change itself lived on different screens.

  • A comment is a card — an avatar, a name, what was said, and when.
  • A system event is one muted lineDana changed status Open → In Progress, Sam added RSK-014-A2, Priya moved RSK-014-A2 to Done.

A change to an action's wording is reported as a change to that action. Renaming a step reads renamed RSK-014-A2; rewriting the detail underneath it reads rewrote RSK-014-A2. Neither says "updated this record", which would name the wrong thing twice — nothing about the record changed, and the reader would not be told which step moved. A single edit that changes both the title and the text reports the rename, because that is the change somebody scanning the thread is looking for.

An event line about an action names the action by its code, and states, people and dates are written the way the rest of the screen writes them — moved RSK-014-A2 to Done, not to done; assigned RSK-014-A2 to Priya Nair, not to an account id. A line in the thread is something you can quote into an email without translating it first.

All · Comments at the top of the thread switches between the two readings. Comments drops the event lines and leaves the conversation alone — useful when a record has been open for months and you want to re-read what people actually agreed.

A thread with nothing in it says so and then asks you to start it, the same way an empty action list offers Add the first action — because the first comment on a record is usually the one that explains why it exists.

Three things the thread does quietly

  • The opening run of events folds. A record created in March opens on its conversation rather than on its paperwork; Show N earlier events puts the preamble back. It only folds when there is a conversation to fold it behind — a record nobody has spoken on shows its events, because folding them would leave an empty screen behind a button.
  • Bursts of the same change collapse into the net change. Somebody adjusting a severity four times in a minute produces one line saying what it ended up as, marked with how many changes it stands for. A change that went out and came back — Medium → High → Medium — produces no line at all, because the net change is no change. Nothing is deleted; this is a reading of the record, and the underlying history is intact.
  • A comment breaks the run. Once somebody has said something about the state of the record, a change before the remark and a change after it are two different facts and are never folded together.

Reading further back

The thread loads the most recent stretch and offers Show earlier activity at the top for the rest. It pages by position rather than by page number, so lines arriving while you read can neither be skipped nor shown twice.

Comments

Comment on the record from the box at the foot of the thread, or on one action from the box inside its side panel. ⌘/Ctrl + Enter posts; so does Comment.

If you can see a record, you can comment on it. There is one commenting rule across the product and this is it. A comment is something you say about a record, not a change to it — and the person reading a record they have no permission to edit is very often the person who most needs to ask the question. So the box at the foot of the thread works for everybody with access to the record, including read-only access.

A comment on a risk is the same object as a comment on a document or a register row — one conversation system across the workspace, so the rules on this page are the rules everywhere. See Comments for the system itself.

A comment is attributed to you by the workspace, from your signed-in session — never from anything the browser sends. The name stays as it was when you said it.

Your own words

You can correct or withdraw your own comment. Nobody can rewrite or remove anybody else's, whatever their role — an owner cannot put words in your mouth, and neither can the assistant's comments be edited by a person. A withdrawn comment leaves the conversation; the record keeps it, because a thread that one person can quietly rewrite is not an account of anything.

Resolving

Every comment has Resolve on it. Resolving collapses it to a single line reading Resolved · who · when, and Reopen brings it back in full.

Resolving is not an author-only verb, and not an editor's one either: anyone who can read the record can settle a point or reopen it. That is what makes the button worth pressing — settling a question is managing the conversation, not changing the record. Nothing is deleted: a settled point is still part of the record, and the click is recorded in the thread.

People, machines and the workspace itself

Every line in the thread says what kind of thing produced it. A person's comment carries their name and their initials. A comment from the assistant is drawn as a card like anybody else's but marked Agent, with AI on the avatar, so what said it is never a guess. Lines the workspace wrote itself — a bulk change, a migration — are attributed to the workspace rather than to a person who did not do it.

Assistants are never offered as an assignee. Work goes to somebody who can be asked about it.

Notifications and permissions

The line under the comment box tells you who is notified.

Assigning an action tells the person it went to. They get a notice naming the action and the risk it belongs to, and it opens straight to the record — whether you assign it on an action that already exists or hand it over at the moment you add one. Two details are deliberate: taking an action off somebody notifies nobody, because "this is no longer yours" is not work; and assigning something to yourself tells you nothing.

Moving a due date tells the person holding the action, so a deadline never changes quietly underneath them. If the same edit both assigns the action and sets its date, only the assignment notice goes out — it already carries the work, and two rows for one handover is noise.

Naming somebody in a comment on an action reaches them too. The full list of what Alchex tells you about is on Your inbox.

Everyone with access to the record can read its actions and its whole thread, comment on it, and resolve or reopen a comment. Seeing the record is the permission to speak about it.

Changing the record is a different thing and keeps a different rule: adding an action, changing one, and editing the record itself all need author access to the record's team. A Reader can join the conversation and can settle a point; they cannot alter the plan or the record.

A Reader is not offered the controls they cannot use. With read-only access the composer is not on the page at all — no Add action, no Add the first action — and the assignee avatar and the status chip in the side panel are inert. The list, the codes, the dates, the progress count and the whole thread read exactly as they do for anybody else, and the comment box works. Offering a control and then refusing the click is a worse answer than not offering it: it teaches somebody their access is broken rather than that it is read-only.

The one thing role does not decide is authorship: you can edit or delete your own comment at any level of access, and nobody can edit or delete yours at any level of access. Detail in Permissions.