Activity Stream

Activity Stream Overview

The activity stream is the timeline attached to a record: what happened to it, in order, from creation to now.

Where to find it

Architect Panel → Data:

• Activity Stream — every entry in the system, filterable by record and type

Architect Panel → Activity:

• Activity Log — the separate technical log of who did what in the platform

What an entry holds

• Record — the datastore and record it belongs to.
• Type — system, status, note, call or email.
• Author — who or what created it.
• Subject and body — the content.
• Attachments.
• Visibility — internal or public.
• Created — the timestamp that orders the timeline.

The five types

• System — written automatically when something happens to the record.
• Status — a change of state, recorded as its own entry so the timeline shows progression.
• Note — somebody wrote something down.
• Call — a telephone conversation was logged.
• Email — correspondence attached to the record.

Why automatic and manual entries share a timeline

Because the question people actually ask is "what happened to this?", and the answer interleaves both. A status change at 10:04, a customer's email at 10:31, an agent's note at 10:35 and an automated assignment at 10:36 only make sense read together.

Split them into separate logs and reconstructing that sequence becomes a manual exercise with two timestamps columns, which is exactly the work the timeline exists to remove.

Not the same as the Activity Log

The Activity Log under the Activity section is a different thing: a technical record of actions taken in the platform, for security and audit. The activity stream is the business-facing history of one record.

Use the Activity Log to answer "who accessed this and when". Use the activity stream to answer "what is the story of this case".

System entries are the backbone

They are written without anybody remembering to, which makes them the reliable part of the timeline. Manual entries are richer but discretionary; a timeline of only manual entries has gaps wherever somebody was busy.

Attachments belong on the entry

Attaching a file to the entry rather than to the record puts it in context — the photograph attached to the note explaining the damage, rather than in a general pile of files where its significance is lost.

The timeline is the handover

The practical value shows when somebody else picks the record up. A well-kept timeline means a colleague can take over without a conversation, and a customer's "I spoke to someone last week" can be answered rather than apologised for.

Worked example

A complaint record's timeline reads: created from a web form (system), acknowledged (status), customer telephoned with more detail (call, with a note of what was agreed), investigation note with a photograph attached (note), response sent (email), closed (status). Six entries, and anybody can read the whole matter in under a minute.

Recommendations

• Keep one timeline per record rather than notes scattered across fields.
• Log calls at the time, not at the end of the day.
• Attach files to the entry that explains them.
• Do not use the stream for technical auditing — that is the Activity Log's job.

Public and Internal Entries

Every entry is either internal or public. That single flag decides whether somebody outside your organisation can see it.

Where to find it

Architect Panel → Data:

• Activity Stream — entries and their visibility
• Datastores — the record the timeline belongs to

What the two mean

• Internal — visible to your staff only. Working notes, assessments, anything not written for the subject of the record.
• Public — visible to the customer, resident, client or contact where they have access to the record.

System entries default to internal, which is the safe default: an automatically generated entry has not been written with an external reader in mind.

Filtering happens on the server

This is the part that matters technically. Internal entries are excluded before the data is sent, not hidden after it arrives.

A timeline that fetches everything and hides the internal entries in the interface has already delivered them to the browser, where they are one developer tools panel away from being read. Server-side filtering means the data was never sent.

If you build a custom view over the timeline, preserve this. It is the difference between a privacy control and the appearance of one.

Write internal notes as if they may be read

Visibility protects against casual disclosure, not against a subject access request. Anything held about an identifiable person is disclosable on request regardless of which flag it carries.

So the rule is not "internal means I can write anything" but "internal means this is working material rather than correspondence". Record judgements and evidence; do not record opinions about the person you would not want to read aloud.

Choosing when you write

Set visibility deliberately on each entry rather than accepting a default. The two failure modes are opposite and both bad: an internal assessment published to the customer, or an update the customer needed marked internal so they were never told.

The second is more common and less noticed. If your customers can see their records, a customer-facing update that nobody marked public is functionally an update that never happened.

Changing visibility afterwards

Treat making an entry public as a publication event, because it is one. Re-read it first. Text written for colleagues rarely reads well to the person it is about, even when it contains nothing improper.

Check what a customer actually sees

Before enabling external access to any record type, look at a real record through a customer's account. It is the only reliable way to confirm the boundary is where you think it is, and it takes five minutes.

Worked example

A housing case carries an internal note assessing whether a tenant qualifies for priority, and a public note confirming an appointment. The tenant sees the appointment and the status changes. The assessment is not sent to their browser at all — which is confirmed by opening the case as a test tenant before the portal goes live.

Recommendations

• Set visibility consciously on every entry.
• Verify with a real customer account before enabling external access.
• Write internal notes as disclosable, because they are.
• Preserve server-side filtering in any custom timeline view.

Getting the Best from Timelines

A timeline is only as useful as what people put in it. These are the habits that separate a timeline somebody can hand over from one nobody reads.

Where to find it

Architect Panel → Data:

• Activity Stream — the entries themselves
• Datastores — the record type whose timeline you are shaping

Architect Panel → Automation:

• Journeys — where automatic entries can be written as a process runs

Record the decision, not the activity

"Called customer" is nearly worthless. "Called customer; they confirmed access is available Tuesday morning and asked us not to call the landline" is a handover.

The test is whether a colleague reading it tomorrow would need to ask you anything. If they would, the note is not finished.

Do not duplicate what the system records

If a status change writes its own entry, a note saying "changed status to In Progress" adds nothing but length. Every redundant entry makes the genuinely informative ones harder to find, and a timeline people skim is a timeline people miss things in.

Write for the next person

Not for yourself, and not for the file. Avoid abbreviations only your team uses, name people rather than writing "spoke to the manager", and say what was agreed rather than what was discussed.

Log at the time

Notes written at the end of the day lose the detail that made them worth writing, and notes written the following morning are reconstruction. Where the timeline is a record of what was agreed with somebody, contemporaneous matters — an entry written during the call carries weight that one written later does not.

Use the right type

Logging a telephone call as a note works, but it loses the ability to answer "how many times have we called this customer" — a question that comes up in complaints more often than you would expect. Types cost nothing to use correctly and are impossible to reconstruct later.

Attach the evidence

The photograph, the signed form, the supplier's email. An entry describing a document is weaker than an entry carrying it, and the description will outlive somebody's ability to find the file.

Keep an eye on volume

A record accumulating hundreds of entries usually means either the process is genuinely long-running or something automated is writing far more than it needs to. The second is worth investigating: an integration writing an entry on every poll will bury the human record entirely.

Review timelines when you review the process

The entries a process generates are a good diagnostic of the process itself. Steps that always produce the same note are candidates for automation; steps that produce no entry at all are steps nobody can evidence.

Worked example

A team reviewing complaint handling reads twenty timelines. They find that every case carries a manual note duplicating the status change, and that the acknowledgement step leaves no entry at all. They remove the duplicate note from the guidance and add an automatic entry on acknowledgement — and the timelines get shorter and more informative at once.

Recommendations

• Write what was decided, not what was done.
• Never duplicate a system entry.
• Use the specific type — call, email, note.
• Read a sample of timelines whenever you review a process.