How Collaboration and Access Works in Deucalion
Understand why the collaboration model is designed the way it is — server-enforced role gates, personal notification ownership, workspace boundaries, and structured event types.
Expected outcome
Admins understand the reasoning behind collaboration behaviour and can diagnose access or visibility questions from first principles rather than treating them as bugs.
Why collaboration is split into two surfaces
Deucalion separates collaboration into two distinct surfaces because the questions each one answers are fundamentally different.
The notification bell answers a personal question: what happened that involves me? It is scoped to the signed-in user's own mentions and collaboration events. One person clearing their queue does not affect anyone else's. This is intentional — the alternative, a shared inbox, creates ambiguity about who is responsible for acting on a notification.
The Activity Feed answers an office question: what changed across the workspace during this period? It is a cross-resource event history, filtered by resource type, event type, or actor. It is an admin-facing desk, not a replacement for the live record itself.
Keeping these two surfaces separate means engineers are never overwhelmed by cross-workspace event history, and admins can use the feed for office triage without it appearing in every field account.
Why access is enforced at the server, not just the UI
Earlier in the product's history, the Activity Feed's access control was enforced only by the UI gate (access: "admin" on the page definition). This meant anyone who knew the server endpoint could query it directly, bypassing the role check entirely.
The server now enforces the same policy independently:
- Org admins and owners — can query events scoped to their own organisation only.
- Engineers — receive a 403 Forbidden response and cannot access the feed at all.
This matters because the Activity Feed exposes cross-resource event history for the whole workspace. If an engineer could query it directly, they could see changes to records they do not have normal access to in the product. Enforcing at the server ensures the access model is consistent whether the request comes from the Deucalion UI or an API call.
Why notification ownership is per user, not per workspace
Notifications in Deucalion are personal. The system does not expose a shared "organisation inbox" because doing so would create coordination overhead and ambiguity: if two admins both see the same mention notification, it is unclear who is expected to act.
Instead, each notification belongs to the user who was mentioned. Only they can see it, read it, or clear it. This means:
- Clearing your notification queue is a safe operation — it does not affect your colleagues' queues.
- If two admins both expect to see a notification for the same event, they each need to be mentioned separately.
- The Activity Feed is the right surface when you need a view of what happened across the workspace, regardless of who was mentioned.
Why event types are structured, not free-text
The Activity Feed allows filtering by event type. For that filter to work correctly, every event that enters the feed must carry one of a fixed set of type labels.
Earlier in the product's history, some events were emitted with legacy free-text strings ("commented", "resolved", "reopened"). These fell outside the structured whitelist, which meant they would either be excluded from event-type filters or cause the filter to return unexpected results.
The legacy strings were replaced with the canonical HistoryEventType constants. Users can rely on these filter labels matching what is actually in the feed. The full set of structured event types is documented in the Collaboration event types reference.
Why workspace boundaries exist in collaboration
Every collaboration surface in Deucalion is anchored to the active workspace. Notifications, activity history, and collaboration access are all tied to the workspace the user is currently signed into.
This is a deliberate design constraint, not a limitation. It ensures that admins from different client organisations cannot see each other's event history, mentions, or collaboration threads, even if they share the same platform infrastructure. It also means that when a user switches workspace, they are effectively moving into a different operational context with its own notification queue and activity history.
If collaboration controls appear incomplete — for example, the Activity Feed is missing or the notification bell does not populate — the first diagnostic step is always to confirm the signed-in user's workspace and role, not to assume the surface is broken.
How to use this understanding in practice
When a collaboration or notification issue is raised by your team, work through these questions in order:
- Which surface is involved? Notification bell (personal) or Activity Feed (office-wide)?
- What role does the signed-in user have? Engineers cannot access the Activity Feed. Admins and owners can, scoped to their own organisation.
- Is the workspace correct? All collaboration state is tied to the active workspace.
- Is the event type visible in the feed? Only structured event types appear. Legacy strings are not included.
- Is the notification actually addressed to this user? Notifications are per-user. A missing bell item usually means the mention targeted a different account.