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.