Sharing along the hierarchy
Sharing decides which parts of a workspace a member can open: you share a folder, a list or a view with Read or Edit access, and that access flows down to everything inside it.
Share a branch once, and everything in it — now and later — is shared too.
Lists and folders you add to a shared branch later are shared automatically, so share the branch that belongs to one team or one area of work, at its top.
Access flow: down the tree, stopped by Private
flowchart TB
ANNA["Member: Anna"]
MK["Folder: Marketing"]
CP["List: Content plan"]
CA["Folder: Campaigns"]
SP["List: Spring launch"]
BU["List: Budget, Private"]
CFO["Member: Omar"]
ANNA -- "gets Edit on" --> MK
MK -- "passes access to" --> CP
MK -- "passes access to" --> CA
CA -- "passes access to" --> SP
CA -. "stops at" .-> BU
CFO -- "gets Read directly on" --> BU
Anna can edit every task in Marketing, including lists added to it next month — except Budget, which is Private. Omar sees only Budget, because it was shared with him directly.
Read and Edit: what a share opens
A share gives one member access to one folder, list or view:
- Read — the member sees the tasks and views there and can comment on the tasks.
- Edit — the member also changes the tasks themselves: creates, edits, moves and deletes them. Edit includes Read.
Tasks are never shared one by one: a task and its comments take their access from the list they live in. A new member joins with the Workerpermission set.
Who can share
Sharing a folder, list or view takes Share for that kind of item: List/Folder manager, Admin and Super Admin include it, and the owner always has it. You share only with workspace members: invite a new person first. The steps are in Share a folder or a list.
When you share a folder, access flows to its folders, lists and views. When you share a list, access flows to the list's views.
The share dialog tells you why someone has access: Provided by and the workspace owner's name for a direct share, Via and the folder's name for access that flows down.
Top-level views
Views outside any folder or list open for every member without a share, and show each person only the tasks from lists that person can open. Making one Private does not hide it: every member can still open it. Changing one takes an Edit share and Update in the Views block of your permission set.
Private branches: turning the flow off
Every folder, list and view has an Inherit access switch in its share dialog (Private branches); on a list's default view it stays on and greyed out, so that view always follows the list. With it on, the parent's audience gets access automatically. Turn it off and the item is marked Private: the parent's audience gets no access, and people you share it with directly keep theirs.
Private takes access away at once
Everyone who reached the item only through its parent loses it the moment you turn Inherit access off. Share it with them directly first if they still need it. Turning Inherit access off or on takes Share and Update for that kind of item, and Edit access to the item itself.
Three kinds of people still reach a private item:
- those it is shared with directly;
- the workspace owner;
- members whose permission sets include See all or Edit all (Permissions and access) for that kind of item (folders, lists and views each have their own).
Use Private for the one list inside a shared folder that not everyone should see, like Budget above.
Permission sets: what a member may do
Shares answer "which branches can this person open". Permission sets (Permissions and access) answer "what may this person do across the workspace". Hule has four system sets:
| Permission set | In short |
|---|---|
| Worker | works on tasks, comments and time logs in whatever is shared with them |
| List/Folder manager | also builds folders, lists and views, and shares them |
| Admin | manages the workspace and its configuration, but not permission sets |
| Super Admin | every permission, including See all and Edit all and managing permission sets |
You can also build your own with New set (Custom sets). A member can hold several sets, and their rights add up.
The two layers work together. Anna is a Worker with Edit on Marketing: she can change every task there, but she cannot create a new list, because that is not in her set. Give her List/Folder manager and she can build inside the branches shared with her.
Why sharing follows the tree
Access that flows down keeps a workspace understandable: to know who can see a list, look at the list and the folders above it, nothing else. The trade-off is that a share is broad — it covers the whole branch. When you need a narrower share:
- share a lower folder;
- share a single list;
- make one item Private.
Connections to the rest of the model
- Sharing rides on the folder tree: see Folders inside folders.
- A shared view shows only the tasks each person can open in its sources: see Views as lenses on tasks.
- An AI agent connected as you gets exactly your access: see Hule and AI.
- Personal views are never shared; they belong to you alone: see Personal and work tasks in one place.
Sharing guides and recipes
- Share a branch: Share a folder or a list.
- Bring people in: Invite members and grant permissions.
- Look up every permission: Permissions and access.
- Open one client's work to a contractor: Give a contractor one branch.