Four things to control, and one of them decides what a client is charged.
The four
| Permission | Covers |
|---|---|
| Projects | Seeing, creating, editing and deleting projects. |
| Project tasks | The work inside them. |
| Timesheets | Logging time — plus approve, on its own. |
| Milestones | The stages, and the amounts attached to them. |
Approve is the one that matters
Timesheet approve is separate from create and edit for the same reason it is separate everywhere else: the person logging the hours should not be the person signing them off.
If everybody who logs time can also approve it, you have no check at all. Approval is not there because people are dishonest — it is there because descriptions need editing before a client reads them, and because “billable” gets left ticked by accident.
Milestones carry money
A milestone holds an amount and an invoiced flag. Somebody who can edit milestones can change what a stage is worth, which is closer to editing an invoice than to editing a task. Treat it that way.
Scope still applies
As everywhere, each permission carries a scope — own, team, all or none — and the highest across somebody’s roles wins.
For projects, team is usually right for people doing the work and all for whoever is running delivery. Scoping everybody to own sounds tidy and means nobody can see the job they are helping with.
A layout that works
| Role | Projects | Tasks | Time | Milestones |
|---|---|---|---|---|
| Team member | View | View, edit | Create own | View |
| Project owner | View, create, edit | All | All, plus approve | All |
| Accounts | View | View | View, approve | View |
| Owner | Everything | Everything | Everything | Everything |
Note that a team member can log their own time and cannot approve it, and that accounts can approve without being able to log any.
Test it, do not reason about it
Make a user on the role, sign in as them, and try to approve a timesheet. It is the one that costs money if it is wrong.
Two layers, again
As with documents, the usual confusion is between the permission and the record.
- The permission decides whether somebody can use Projects at all.
- The scope decides whose projects they see — own, team or all.
- The roster decides whether they can be assigned tasks on a particular one.
All three have to line up. When somebody says they cannot see a project, check the scope first and the roster second.
Own is usually the wrong scope here
Scoping projects to own sounds careful and means somebody cannot see the job they are working on, because they do not own it. For most businesses team is right for people doing the work and all for whoever runs delivery.
Projects are collaborative by nature. A permission model that hides them from the people delivering them produces a lot of screenshots being sent around, which is worse for confidentiality than the access you were trying to restrict.
Where to go next
Something missing or wrong here? Tell us. A question that needed asking usually means a page that needed writing.