How Project Access Works

Project access is three decisions stacked together: what someone may do in the organization, what they may do inside a workspace, and whether a single project, section, or task was shared with them. Mix those up and you will either lock out the people who run the work or show a client the wrong project.

This is not the same question as who may see employee records, pay, or leave. That is an HR permission problem. Project permissions decide who may see and change delivery work. Keep the two maps separate even when the same person shows up in both.

The three layers

Organization role. This role sits on the person for the whole company, not for one workspace. It is how you grant things that are not inside a single team: creating a workspace, seeing workspaces across the organization, archiving a workspace, or managing organization-level roles. Someone can hold this role and still not be a normal member of every workspace. Membership is a separate fact.

Workspace role. This role sits on the membership. It is the list of what that person can do in that workspace: manage members, create projects, edit tasks, comment, view all tasks, manage shares, and so on. A person can be in two workspaces with two different roles. The designer who runs one client workspace should not automatically run the internal one.

Item share. A share is narrower than a role. It grants view, comment, or edit on one project, one section, or one task. You use it when a role should stay weak and a single item should open. That is the usual shape for a client or a contractor.

Layer	Attached to	Typical question it answers
Organization role	The person in the company	May they create a workspace or administer roles?
Workspace role	Their membership in one workspace	May they create projects and edit tasks here?
Item share	One project, section, or task	May they open this item even if the role is limited?

A strong workspace role can make a share unnecessary. If the role already includes viewing every project, a “view” share does not hide the others. Set the role to match the smallest access you intend, then add shares for exceptions.

What the workspace role is deciding

Inside a workspace, permissions are specific. They are closer to verbs than to job titles.

• Workspace: change settings, manage members and invites, manage roles.
• Project: create projects, manage a project, view all projects.
• Section: manage sections.
• Task: create, edit, delete, assign, manage statuses, manage relationships, comment, view one’s own tasks, view all tasks.
• Sharing: manage who has a share.

“Project manager” is not a permission. It is a name you might give a role that includes several of those verbs. Two people with the same job title can have different roles. Read the verbs.

Viewing managed members’ tasks is its own permission. It is how a lead can see work for people they manage without turning on “view every task in the workspace.” It is not a copy of the HR org chart. The reporting line in the HR system and the role relationship in the project tool are different records. Do not assume one updates the other.

How a share changes the picture

Shares exist so you do not have to inflate a role. A reviewer who should comment on one project gets a workspace role with almost nothing, plus a comment share on that project. An editor on one section gets edit on that section, not “edit every task.”

The share levels are view, comment, and edit. Pick one. Comment does not imply they can change due dates. Edit is the level that includes changes. If you are unsure, choose the lower level and widen it when there is a real task they cannot complete.

Removing the share closes that item. It does not remove the person from the workspace. Removing the membership closes the workspace. Do the one you mean.

A short example

Northwind’s organization has an admin who can create workspaces and manage organization roles. The studio workspace has three memberships:

• Alex’s role can manage projects and edit any task.
• Sam’s role can edit tasks and comment, but cannot manage members.
• A client reviewer’s role cannot view all projects. A comment share on the “Spring campaign” project lets them discuss that project only.

Sam cannot invite another client, because member management is not on Sam’s role. The reviewer cannot open the internal tools project, because neither the role nor a share allows it. Alex can, because the workspace role includes broad project access.

If someone later pastes “view all projects” onto the reviewer role to “save time,” the share stops being the boundary. The role wins that argument.

Check the layer that actually failed

When someone sees too much, or cannot see enough, name the layer before you change a setting.

If they can open every project in the workspace, look at the workspace role first. “View all projects” or “view all tasks” on that role will defeat a careful share. Remove the broad verb. Then confirm the share still opens the one project they should see.

If they cannot open a project you thought you shared, confirm they are an active member of that workspace and that the share is on the right object. A share on a task does not invite them into a different workspace. An organization role that can create workspaces does not, by itself, place them inside one.

If a lead can edit tasks but cannot see a report’s work, you are in the “view managed members’ tasks” permission, not in a general edit right. Edit and visibility are different verbs. Granting edit does not automatically list another person’s tasks.

Write down the layer you changed. The next leak is usually someone reversing that change because the title on the role sounded too narrow.

What this article does not cover

Building a role field by field is a setup task. This page is the map. Dashboards, exports, and scheduled email are not part of this access model. Do not promise them from a role name.

HR access is documented separately. Who may see payroll or employee files is not decided on the project role. See how HR system permissions are framed and the security overview for the people-data side. Come back here for projects and tasks.

How this works in Dayzen

In Dayzen’s Project Management System, organization permissions come from an organization-level role on the person’s project profile. Workspace permissions come from the role on their workspace membership. The project permission system is independent of the HR role system. A share then adds view, comment, or edit on a project, section, or task for that member.

Check the role before you blame the share. Check the share before you widen the role. Those two moves solve different leaks.