A project has four different kinds of person on it, and conflating them is how the wrong person ends up on an email.
The four
| Who | What it means |
|---|---|
| Owner | One person, accountable for the project. |
| Groups | Whole teams. Every member joins the roster and can be assigned tasks. |
| Vendors | Outside suppliers brought onto this job. |
| Contacts | The client’s own people, beyond the customer record itself. |
Add groups, not names
Adding the design group puts everybody in it on the roster. Somebody joining that group next month can be assigned tasks on this project without anybody touching the project.
It is the same argument as sharing a folder with a group rather than three people: you are recording a rule rather than a snapshot of who happened to be here.
Only people on the roster can be assigned a task. If somebody’s name is not in the assignee list, they are not on the project — add them or their group, rather than assigning it to somebody else and telling them verbally.
Vendors on a project
The printer, the photographer, the contractor. Adding them records who is involved and makes the job findable from their vendor record.
A blocked vendor cannot be put on a project — the same check that refuses them a purchase order refuses them here. That is deliberate: committing somebody to a job is committing to them just as much as raising an order is.
Client contacts
The customer record is the company. Contacts are the actual people — the marketing manager who approves, the finance person who pays, the founder who changes their mind.
Naming them matters for the dull reason: when the approval is late, you need to know who has it.
What the client sees on their portal
A customer with a portal login has a Projects tab. It lists the projects whose customer is them, the ones they are named on as a contact, and any a login of theirs was put on. Each shows its status, how far along it is, how many tasks are done, the next milestone and the due date.
Opening one shows the dates, the owner as Your contact, the description, the milestones (cancelled ones left out) and the tasks with their status and due date. Subtasks are not shown: they are the working underneath a task, which is why a task is the thing you would mention in a client update.
It is read only, and it never shows the budget, what has been spent, hours, rates, notes or anybody’s contact details. A contact looking at somebody else’s project sees it under the name the identity rules give it, its nickname when the client is shielded. Who sees a project here is decided by the customer record alone; a sharing rule written for staff cannot add a project to a client’s list.
A sensible roster
- Owner — whoever would be asked if the client rang to complain.
- Groups — the teams actually doing the work.
- Vendors — anybody outside you are paying for this job.
- Contacts — who approves, and who pays.
Being on a project is not the same as having permission
Two separate things, and the usual cause of “why can they not see it”.
| Layer | Decides |
|---|---|
| Module permission | Whether somebody can use Projects at all, and what they may do. |
| The roster | Whether they can be assigned tasks on this project. |
Somebody with full project permissions still cannot be assigned a task on a project they are not on. Somebody on the roster still cannot open it if their role has no project access.
Why vendors belong on the record
- The job becomes findable from the vendor, which is how you answer “what have we used them for?”
- Their cost lands against the project’s spend.
- A blocked vendor is refused, so a dispute stops work being handed to them.
Adding a vendor to a project does not commit any money. The purchase order does. But recording them is what makes the spend figure honest later, when somebody asks why the job cost what it did.
Where to go next
Something missing or wrong here? Tell us. A question that needed asking usually means a page that needed writing.