All articles

Editor vs viewer access: who should edit a project plan?

Editor vs viewer access decides who can change your project plan. Learn how to assign roles, keep one owner and avoid conflicting edits on a shared schedule.

5 min read

Editor vs viewer access sounds like a small settings question, but it decides whether a shared project plan stays trustworthy. If everyone can change every date, the schedule slowly turns into a negotiation. If only one person can touch it, that person becomes a bottleneck and the plan goes stale. This guide explains the roles, shows how to decide who gets which one, and gives a simple routine for keeping a shared plan accurate.

The three roles in a shared plan

ProGantt Flow uses three roles on every shared project:

  • Owner: the person who created the project. The owner controls who has access to it.
  • Editor: can change the plan. Editors add and move tasks, update progress, set dependencies and assign people.
  • Viewer: read-only. Viewers see the same live chart as everyone else, but cannot change anything.

The important point is that everyone looks at the same plan. There is no exported copy to go out of date: when an editor moves a task, viewers see the new dates the next time they look. If you need the background on sharing with someone outside your team, read how to share a Gantt chart with a client or team.

A quick rule for choosing the role

Ask one question about each person: will they ever need to change a date or a task?

If the answer is yes, they are an editor. If they only need to know what is happening, they are a viewer. Most people fall clearly on one side.

Person Typical role Why
Project lead Owner Responsible for the plan and its accuracy
Team member who owns a phase Editor Updates progress and dates for their own tasks
Client Viewer Needs visibility, not control
Executive sponsor Viewer Wants the status at a glance
Freelancer on one deliverable Editor or viewer Editor if they report their own progress, viewer if the lead does

When in doubt, start with viewer. Promoting someone to editor later takes seconds. Cleaning up after an accidental edit takes longer, and it also damages trust in the plan.

Example: a website relaunch with five people

Imagine a website relaunch with five people: Maria (project lead), Joe (designer), Sam (developer), Ana (content writer) and a client contact called Priya.

The plan has three phases: Design, Build and Launch.

  • Maria creates the project and is the owner.
  • Joe, Sam and Ana are editors. Each of them updates progress on the tasks in their own phase.
  • Priya is a viewer. She can open the plan whenever she wants and see where things stand, without needing a status email.

Now the design phase slips by three days. Joe pushes his tasks back. Because the Build phase depends on Design, the dependent tasks move with it, and everyone sees the new launch date immediately. Priya sees it too, without anybody having to tell her first. If you want a refresher on why those dependent tasks move, see our guide to task dependencies in a Gantt chart.

Why fewer editors is usually better

It is tempting to make everyone an editor "so it is easier". In practice, more editors means more ways for the plan to drift. Three problems come up again and again.

Silent changes

A date changes and nobody knows why. Stakeholders lose confidence because the plan no longer matches what they were told in the last meeting.

Conflicting edits

Two people adjust the same area of the plan for different reasons. Real-time sync means you both see each other's changes, but it cannot decide which change was the right one. That is a conversation, not a feature.

Edits made to look good

Under pressure, it is easy to shorten a duration or mark a task as done to make the chart look healthier. Keeping the editor list short makes this less likely and makes it easier to ask "who changed this?"

A good habit is to give editor access to the people who own the work, and viewer access to the people who need to know about it.

A routine for keeping a shared plan accurate

Roles only help if there is a rhythm around them. A light routine is enough:

  1. Editors update their own tasks at the end of each working week: progress, any date changes, any new tasks.
  2. The owner reviews the plan once a week, looking for tasks that are late, unassigned or missing dependencies.
  3. Changes that affect the deadline are discussed first. Moving a milestone is a decision, not an edit. Agree on it, then change it.
  4. Viewers get the link, not a screenshot. Anyone asking for a status gets the live plan.

For what to do when the review shows a slip, see how to handle project delays.

Roles and AI assistants

If you connect an AI assistant to your plan through MCP, it acts as you and sees exactly what you see. Shared projects keep their roles: if you are a viewer on a project, the assistant can read it but every write is refused. So the same rule applies to your agent as to you. If you want it to update a plan, you need to be an editor or the owner of that plan. The connector documentation at /mcp_doc.html explains this in the permissions section.

One more detail from the docs: there is no tool for changing who a project is shared with. Sharing and roles stay in the web app, so access decisions remain with a person.

Common mistakes to avoid

  • Making the client an editor. They rarely need to change anything, and it opens the door to scope arguments inside the plan itself.
  • Having no clear owner. Someone must be responsible for the plan as a whole, otherwise nobody notices when it drifts.
  • Never reviewing access. When a person leaves the project, remove their access. A shared plan is only as safe as its list of collaborators.
  • Using the plan as the only communication channel. A moved date still deserves a short message to the people affected.

Summary

Decide roles by one question: does this person need to change the plan? Keep a single owner, give editor access to the people who own the work, and give everyone else viewer access to the live chart. Add a weekly update and a weekly review, and your shared schedule stays accurate without a screenshot in sight.

You can try this with a small project in ProGantt Flow: create a plan, invite a colleague as a viewer, and see how little effort it takes to keep everyone looking at the same schedule.