Can a standard member watch an admin member?

The question came up during implementation of our watching system: can a standard member update or delete the watching of an admin member?

Our developer framed it specifically:

“Let say we have an admin member and they are watching an object of type checklist. Can a standard member remove this watch for the admin? Can the standard member also add a new watch for the admin e.g. a standard member adds a new watch that the admin should watch process_A?”

This gets at a fundamental question in permission system design: should organizational hierarchy affect feature access?

The core rule

My answer was brief:

“If you are able to edit an object - you are also able to edit watchers for it.”

One sentence. That was the entire permission model.

If you have edit rights on an object, you can manage who watches it. Standard member, admin member, does not matter. Edit access implies watcher management access.

The thinking was straightforward: why create a separate permission dimension for watchers when edit access already grants full control over an object? Adding watcher management complexity on top would require maintaining two parallel permission systems that could conflict.

Three types of watch ownership

Early in the design, we realized not all watches are created equal. The permission model distinguishes who created the watch:

“There’s 3 types of watches: Member-owned, Guest-owned, System-owned - our system created it as a default and it cannot be deleted.”

Member-owned - a member created it - and another member can turn it on/off, or delete the watch, subject to conditions.

Guest-owned - a guest created it - and either a member or a guest can turn it on/off, or delete the watch.

System-owned - our system created it as a default and it cannot be deleted, but it can be turned on/off.

System-owned watches came from migrating existing notification preferences. You cannot delete your “email me when I am assigned to something” notification. But you can turn it off.

Why we avoided role-based complexity

In discussions with operations teams over the years, we have seen permission complexity become the primary barrier to adoption. One legal firm told us their previous system had so many permission settings that they needed a two-page reference guide just to remember who could do what.

The alternative would have been a matrix. Admins can do X. Standard members can do Y. Guests can do Z. Cross those with four object types and three watch operations and you get a 36-cell table that nobody remembers.

We had already been through permission complexity elsewhere. Blueprints have three questions: Who can view? Who can edit? Who can launch? Processes ask similar questions. Adding another dimension for watchers would compound the confusion.

The documentation for managing members already explains these member types. The watching system needed to fit naturally.

The guest boundary

Guests are different. Our developer asked for explicit True/False answers:

“A guest can not add a watch for other members and guests. He can add/remove his own watch only.”

True.

“A guest can not watch any member (standard/admin).”

True.

“A guest cannot watch any kind of blueprint.”

True.

The expanded explanation:

“A guest can only remove themselves from watching something but not other guests or other members.”

Guests have a self-service boundary. They manage their own watches. Members with edit access manage everyone else.

The filtered visibility problem

Here is where it got interesting. What happens when a guest watches a process but can only see some tasks within it?

“If a guest watches process_A which contains task_A - the guest will only get updates from tasks visible to the guest.”

I expanded on this in the discussion:

“To clarify further - if a guest watches process_A which contains task_A (the only task the guest is assigned to) - the guest will only get updates from tasks visible to the guest i.e. task_A. If a guest is assigned task_A, task_B and task_C in process_A then watching the process gives the guest updates over all three tasks they are assigned to.”

Watching a process as a guest is filtered. You get updates only for tasks you can see. The watching system does not override task-level visibility - it works within it.

The top secret exception

We had another complication: top secret tasks. From the issue discussion:

“When top_secret = true, only assignees and admin users can see the task.”

This creates a visibility layer that watching must respect. If you are watching a process that contains a top secret task you are not assigned to, you do not get updates about that task. The watching system honors the underlying visibility model.

The member watching exception

There is one place where the standard rule breaks:

“The exception to this is member watching - you cannot remove someone from watching you - they control that watch.”

If a colleague watches you, you cannot stop them. They see your activity across the organization. You have no control over their decision to observe.

This felt right for transparency. In a business context, colleagues should be able to follow each other’s work without requiring permission from the watched person.

The edit rights chain

For member-owned watches, the rule is consistent:

“For member-owned watches - anyone with edit rights over that object can add/remove other members on the watch list.”

The examples:

• If another member set me as watching a blueprint - I can remove myself from watching it
• If I set another member as watching a process - that member can remove themselves from watching it

Notice the symmetry. Someone can add you as a watcher. You can remove yourself. Nobody is trapped.

The detailed Q&A

During implementation, we went through explicit scenarios. The developer asked for True/False:

“Standard members can watch admin members.”

True.

This confirms the core rule. Admin status does not create a watching shield. Any member can watch any other member.

The questions continued:

“If a guest has been assigned task_A then he can add only his watch on this task_A as well as on the relevant process.”

True.

Guests can watch what they can see. If assigned to a task, they can watch that task and its containing process.

The tracking and tasks documentation explains more about task assignment and visibility.

The consensus requirement

An interesting case came up from our designer Pravina:

“As a single user who just joined, I need to be able to get consensus over a step from others involved.”

This is about assignment confirmation, not watching - but it shows the pattern. New users need visibility into what others are doing. The watching system enables this: you can watch someone to see their activity, even if you just joined and have no edit rights over them.

The debate we avoided

We could have built role escalation into watching. Maybe only admins can add watchers to blueprints. Maybe standard members cannot watch other members without approval.

Every additional rule would require:

1. Documentation explaining when it applies
2. UI that shows the rule is being enforced
3. Error messages when someone hits the boundary
4. Edge case handling when roles change

The simpler model - edit access implies watcher access - required none of that.

What we left out

Guests watching members - We explicitly blocked this. A guest has no business watching member activity across the organization. They see only what they are assigned to.

Guests watching blueprints - Same reasoning. Blueprints are organizational assets. Guests work on specific tasks within processes.

Cross-organization watching - Never considered. Organizations are isolated by design.

Role-specific watch restrictions - No limits based on admin vs standard status. The permission system treats watching as orthogonal to organizational hierarchy.

Approval workflows for watching - No “request to watch” pattern. If you can watch something, you can watch it immediately.

Watch quotas - No limits on how many things you can watch. We considered this for system load reasons but never implemented it.

Hierarchical watch inheritance - Watching a folder does not automatically watch everything in it. Each object is watched independently.

The resulting matrix

The final permission model fits in a small table:

Three rows. Three columns. Anyone can understand it.

The guest row captures all the restrictions: no watching members, no watching blueprints, no managing other people’s watches. Members - whether admin or standard - have equivalent watching capabilities.

Why this matters for workflow design

Based on hundreds of implementations, we have observed that permission complexity is the hidden cost that kills adoption. In our experience, teams spend 3-4x more time on permission troubleshooting than they budget for. Every rule you add requires:

• User education
• Support documentation
• Edge case handling
• Testing across combinations

The watching permission model demonstrates that simpler rules often handle real-world scenarios better than complex matrices. “If you can edit it, you can manage its watchers” covers almost every legitimate use case.

The few exceptions - guests cannot watch members, you cannot stop someone from watching you - are explicit and memorable. They do not require a lookup table.

Related questions

Can I watch something I cannot edit?

Yes. View access is sufficient to watch. The edit-implies-watcher-management rule applies to managing other people’s watches, not creating your own.

What happens when someone’s role changes?

Existing watches remain. If a member gets demoted to guest status, their member-owned watches become guest-owned with the associated restrictions. They can still remove themselves from watching but cannot manage others.

Can I see who is watching something?

Members with edit access to an object can see its watcher list. Guests can only see that they themselves are watching something, not who else is watching.

What about watching notifications - do permissions affect those?

No. Once you are watching something, you receive notifications according to your frequency preference (electric, mindful, or chilled). The permission system only affects who can add or remove watchers, not the notification delivery itself.

Does this work with nested permissions?

The watching system does not consider nested permissions. Watching a folder does not watch its contents. Watching a blueprint does not watch processes launched from it. Each watchable object is independent.