Collaboration, Permissions, and Governance
Who can see and do what
Permissions govern visibility and action. At the workspace level, members, guests, and admins have different reach. At the project level, projects are public to the workspace, private to members, or shared with specific people. Guests are limited to projects they're explicitly added to and can't see the full workspace. Admins manage workspace-wide settings. Understand that task-level followers receive updates, and that commenting and assigning require appropriate access.
Governance practices
Good governance means consistent naming, controlled use of custom fields, clear ownership per project, and periodic review of automations and templates. Rules and automations should be documented so their effects are predictable. Avoid orphaned projects and duplicate fields. Use teams to group projects and manage membership at scale.
Traps in questions
Frequent traps: assuming a guest can browse all public projects (guests have narrower access), or that project membership grants workspace admin rights (it doesn't). Another is confusing follower (gets notifications) with assignee (responsible for completion). Questions may also test that deleting a user's access doesn't delete their tasks, and that permissions on custom fields are separate from project access.
Rule of thumb
Grant the least access needed to do the work, document automations, and keep field libraries curated. If a question describes someone seeing data they shouldn't, the answer usually involves project visibility or guest restrictions, not task settings.