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. Alongside them the record carries its conversation (the 💬 Comments panel) and its event log (Activity) — what people said, and what the record did.

Open any record under Risks and the actions 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 panel now. Comments and Activity are each one button away, in the small group of panel buttons at the right of the record's top bar — the panel each opens still docks on the record's right edge, one at a time, as it always did. See Risk records for the record itself.

The column around them is now only the description. The large heading, the Opened … line under it and the small grey code line above it have all gone: the name is typed in the trail at the top of the page, where it is also read, and the code and the created date are rows in the Properties panel — where they read under the same five labels every record kind uses (Code, Owner, Created, Type, Status), the Opened wording having gone with the panel's unification. See Risk records. Nothing about actions or the thread moved with any of that; they simply start higher up the page.

Actions

Actions follow their record's review state: while the risk is in review, its actions are locked with it — nothing can be added, edited or dropped until the review is approved, sent back or withdrawn (see Asking for approval). The activity thread stays open — talking about the record is not editing it.

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

This is the only place work on a risk is assigned to a person. The record itself carries an Owner — who is accountable — and nothing else; it used to carry an assignee of its own too, and two names on one record only made a reader guess which of them to write to. An action names the step and whose it is, which is the pair somebody chasing the work actually needs.

Every action carries a code derived from its record's — RSK-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 — so does the Add button at the end of the row — 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. Once you open the composer the sentence steps aside: what you are looking at is the first action, not an empty list.

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, its title and full text (both editable), its own conversation, and the way to delete it.
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.
Click the state glyph to move the work along: Todo → In Progress → Done, in place, without opening anything. A list of five steps is five clicks. Clicking a finished step once more returns it to Todo, so a mis-click costs one click to undo. Canceled is not in the cycle — deciding not to do something is a decision, and you make it deliberately from the side panel rather than arriving at it by clicking once too often.
Click the date and your system's date picker opens. It works the same way in three places — the row, the side panel and the composer — so a date is never something you had one chance to get right while creating the step, and clearing it leaves the action undated. An action with no date keeps its control quiet until you reach for the row: a list of undated steps should read as a list of steps, not as a column of empty placeholders.
Change the status from the chip in the side panel: Todo, In Progress, Done or Canceled.
Rename it, or rewrite its detail, in the side panel. The title and the text under it are fields: click into either, change it, and click away or press Enter on the title to save. Escape throws your typing away and puts the saved words back without saving anything. The record's history reads a rename as renamed RSK-014-A2 and a rewrite as rewrote RSK-014-A2, and every chip that references the action follows the new title.
Delete it from the bin icon beside Close in the side panel. You are asked once; the action then leaves the list and the record's history says it was removed. Its comments stay in the history, so nothing anybody said disappears with it.

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.

Pointing at a step from somewhere else

An action can be referenced — from a risk's description, or from a governance document — by typing / and picking it by name. What lands is a chip carrying the step's current title: rename the action and every mention updates, cancel or delete it and every mention says so rather than going quietly stale. Clicking one opens the action's panel on the record it belongs to.

An action also has an address of its own now, so that panel can be linked to directly. Copy a chip and you get a link a colleague can open; paste such a link into a description or a document and it becomes a chip again. Which step it names is checked when it resolves, so a link that pairs a step with the wrong record shows nothing rather than the wrong thing.

An action is only findable by people who can already see the record it belongs to — it inherits the record's team, having none of its own.

The activity thread

Two panels on the record's right edge, each answering one question:

💬 Comments — the conversation. The same panel, with the same name and the same behavior, a document and a register record carry: one chronological list, write, edit your own words, @ a teammate. If you want to say something about the record, this is the place, on every record kind alike.
Activity (the clock icon, beside Versions) — the system's own account of what happened, one muted line per change: Dana changed status Open → In Progress, Sam added RSK-014-A2, Priya moved RSK-014-A2 to Done.

Comments used to be interleaved inside Activity, between the event lines. They moved to their own panel so that "where do I comment?" has one answer across the product — the record's story is still one stream underneath (the record keeps comments and events together in its own account), but the reading is now the conversation in one place and the paperwork in the other. The Versions tab is the formal field-level record — which fields changed, in which version — for when that is the question.

Both live and die with their record: deleting the record — from the ⋯ menu in its top bar, described in Risk records — removes its actions, its conversation and its history with it.

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.

Every assignment line on a thread names an action. The record used to carry an assignee of its own, which wrote lines naming nobody's step — assigned this to Priya Nair, with no code. Those lines were removed with the field, so an assignment in the history is always an assignment of a specific step you can go and read.

Attaching or removing what the record points at is a line too. Linking a document, a clause or a control — and unlinking one — reads as a change to the linked records. Re-saving a record without touching its links stays silent, so the line only ever appears when something actually moved. This was the last common edit the thread did not mention: the links changed and the thread said nothing, which left the record's own account of itself with a hole in exactly the place an auditor looks. Moving a corrective action forward is on the thread for the same reason — it used to be recorded only in the record's versions, one screen away from the story it belongs to.

A move between teams reads as history, not as something still on offer. Records used to be moved by a row in the Properties panel; that row is gone, because a record's team is settled where it is raised (see Risk records). Threads that already carry a move keep it, and it still names the team in words rather than as an id — withdrawing a control is not a reason to let an old line stop making sense.

A conversation 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.

Things the event log does quietly

The opening run of events folds. A record with a long preamble opens on what changed recently; Show N earlier events puts the setup back. The surface can never end up empty, because the last few lines are never folded.
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.
Rewriting the text is one line, not one line per save. A record saves as you type, so a sitting spent on the description used to leave a wall of identical lines. One sitting now reads as a single edited the description — and if you moved between the name and the body it names both. It says which wording moved, never what it now says: the thread points at the change, and the record itself is where you read it. Since sessions gained a way back, that line is the record's editing session — it carries Return to this, and the same sitting never appears twice (see Risk records); sittings from before then stay as the plain lines they were.
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 foot of the history panel for the rest — the list reads newest first, so earlier is downward. It pages by position rather than by page number, so lines arriving while you read can neither be skipped nor shown twice.

Every line names a person and a state in plain words. A record created outside this app's own form — by an import or an integration — can hold a status that is not one of the four in the picker; the activity and the properties both show what was actually stored rather than substituting a nearby option. A value nobody chose is still a fact about the record, and an audit reads better with it than with a guess.

Comments

Comment on the record from the box in its Comments panel, or on one action from the box inside its side panel. You can edit or delete your own words through the ⋯ menu — the risk carries the same comment surface as a register record or a document, so the gestures are the same everywhere. ⌘/Ctrl + Enter posts; so does Comment. Type @ and a list of your teammates opens — the same picker as on every comment box — and a name you pick reads as their name in the list, never as markup. See Comments.

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.

There is nothing else on a comment to operate. There is no Resolve, no Reopen and no reply nesting — a comment is a message in the record's conversation, in time order, and answering somebody is writing the next one. Remarks settled under the old model keep their place in the list like any other message.

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, and comment on it. 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; 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.

A risk carries no Approvals panel — while a review is pending, its properties show one status line and the decision is made on My Approvals, with the record's activity keeping the full trail. Requesting and deciding a review of the risk is described in Risk records.