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.
Personal notifications and workspace activity answer different questions
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 merges workflow alerts and mentions addressed to the signed-in user. One person marking items read does not affect anyone else's queue.
The Dashboard Activity section 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, actor, or date. Old Activity Feed links redirect here. The activity list is not a replacement for the live record itself.
Keeping these two surfaces separate gives each person a manageable queue while admins and owners retain a workspace-wide history for office triage.
Activity access and workspace boundaries
The server enforces the same policy as current navigation:
- 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.
The Activity section exposes cross-resource history, so a direct request does not bypass the role or organisation boundary. Use the linked resource to verify current state after finding the relevant event.
Why notification ownership is per user, not per workspace
Notifications in Deucalion are personal. The bell is not a shared organisation inbox.
Each workflow or mention notification has one recipient. Only that recipient can see it, mark it read, or clear it. This means:
- Clearing your notification queue is a safe operation — it does not affect your colleagues' queues.
- If two admins both need a mention notification, mention each account.
- Dashboard Activity is the right surface when an admin or owner needs the wider workspace history.
Use the activity filters
Filter by resource, event type, actor, or date to narrow the current workspace history. The available event labels are documented in the Collaboration event types reference.
Why workspace boundaries exist in collaboration
Activity history and collaboration links are anchored to the active workspace. The notification API is always scoped to the signed-in user, and its links are resolved against that user's current access.
This keeps admins from different client organisations out of each other's activity history and records. Switching workspace changes the operational and access context, so recheck the workspace before acting on a linked record.
If collaboration controls appear incomplete—for example, Dashboard Activity is missing or the notification bell does not populate—first confirm the signed-in user's workspace, role, and notification recipient.
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 Dashboard Activity (office-wide)?
- What role does the signed-in user have? Engineers cannot access Dashboard Activity. Admins and owners can, scoped to their own organisation.
- Is the workspace correct? Activity and linked-resource access use the active workspace.
- Do the filters include the event? Clear or narrow resource, event, actor, and date filters deliberately.
- Is the notification addressed to this user? Notifications are per-recipient. A missing bell item may have targeted a different account.