There is one fixed role, the owner, who can do everything. You write the rest yourself: a name and a list of per module permissions, with two levels, read and write, and write implies read. What somebody can actually do is the intersection of what the workspace has bought and what their role grants.
Two questions that look like one
Can this person touch invoicing has two answers, and they have to be given separately. The first is whether the workspace has that module at all. The second is whether this person's role grants it. They belong to different owners: the plan answers the first, whoever runs the workspace answers the second.
The product keeps them apart on purpose and never folds one into the other. What somebody can do is the intersection, and the intersection is taken last. Two guarantees fall out of that, and both are appreciated on the day they matter: upgrading a plan does not quietly hand the new module to everybody, and taking a permission away from one person does not read like cancelling a module.
| The question | Who answers it | Where it changes |
|---|---|---|
| Does the workspace have this module? | The plan it pays for | The workspace subscription |
| May this person touch it? | Their role, and their exceptions | The roles and members screens |
| What can they do in practice? | Both at once | It is computed, not written |
There is no cache in between either. Permissions are resolved on every request, from rows that are already travelling with it, because a permission that lags is worse than an invoice that lags: no window of minutes is an acceptable answer to I removed their access at nine this morning.
The owner is the only role the product knows by name
Of all the parts people play, the product knows one: the owner. They can do everything, invite, remove, touch the fiscal record and the subscription, and their access is not computed from any list. It is not even read: an owner whose exceptions column is a mess is still the owner of their workspace.
That is not an exception made for convenience, it is the fire escape. The owner is the person who edits the roles, and a role able to take permissions away from the owner would be a lock with no key on the inside: the only person who could put it right is the one who just got shut out. Keeping the owner out of reach of the role system is exactly what guarantees there is always somebody who can undo a mistake made inside it.
Everybody else is a member, and that word says nothing on its own. What such a person can do comes out of their role, which is a row you write.
A role is a name and a list
A permission names a resource and a level: clients at editor, analytics at reader. There are two levels and write implies read, so there is no need to tick both. There is no third level and no none to switch on: a role says no to something by simply not naming it. Two ways of spelling nothing are two things to validate, two things to migrate, and one of them eventually wrong.
The resources are every module, plus four things that are not modules: the members, the roles, the workspace settings and the subscription. That last one deserves a second of attention, because the subscription and invoicing are two different resources with names that sit too close together. The subscription is what the workspace pays to use this. Invoicing is what the agency charges its own clients. Somebody keeping the books for your clients wants the second and should almost never hold the first.
A workspace does not start with an empty screen. It is created with two roles already written, one for editing and one for reading only, copied inside the workspace at the moment it is created. Being copies, renaming them or trimming them changes your workspace and nobody else's, which is the opposite of how a plan behaves.
The list of modules on that screen depends on the workspace kind, because a permission over a module your kind cannot hold would be a checkbox that opens nothing. Reports and the portal belong to agency workspaces, and quotes, contracts, invoicing, briefs, the CRM, the SOPs and the customisation to the agency plans that include them; approvals, tasks and chat reach the top creator plan as well; the calendar, social networks, analytics, ads, bio, Drive and workflows belong to everybody, and the MCP door comes with the top plan of each kind. Which kind yours is, and what changes with it, is in workspaces, brands and clients.
The permissions that are neither read nor write
Some things do not fit into reader or editor, and each one stands apart because somebody wants to hand it out without everything it would otherwise drag along, or withhold it without withholding the whole module.
| Permission | What it opens |
|---|---|
| Export data | Downloading as CSV or PDF what that person can already see on screen |
| Configure catalogues | The services, the preset texts of the documents, and the columns and labels of the task board |
| Delete permanently | The hard delete. Without it, the destructive path stops at archiving, which is reversible |
| Inbox | A brand inbox: messages, comments and reviews |
| See connection history | When, and for how long, each person on the team and at the clients has been connected |
| View the portal as a client | A client portal in read only, exactly as that client sees it |
Two of those rows make more sense read backwards. The inbox arrives switched on alongside social networks, and exists separately so that it can be taken away: a brand's private messages are its audience's conversations, and some people should be able to schedule and publish without reading them. The connection history is the opposite: nobody gets it by default, because who is at their desk and for how many hours has a shape the member list does not have. It should not be confused with the green dot for who is online right now, which is momentary, mutual and stored nowhere.
And one deserves a warning said out loud. Entering a client's portal to see it as they see it opens everything that client sees, their invoices, their contracts, their Drive and their chat room, even when the role of the person entering holds none of those modules. That is why it never switches itself on when the Clients row is raised, it has to be ticked by hand, and every entry is logged. What is on the other side of it is described in the client portal.
Everything in this article happens in one place in GoFeed.
Try it freeExceptions for one person
A role describes a job, and somebody will never quite fit it. Rather than creating Editor without invoicing and then, three months later, Editor without invoicing but with export, exceptions are written onto the person: this one adds a resource, that one drops another, and the role stays as it was for everybody else.
Exceptions replace what the role said rather than adding to it, and they are applied before the intersection with the plan, never after. That order is the whole safety of the column: applied last, whoever administers roles could write a module the workspace never bought and hand out through permissions what can only be paid for. How many seats a plan carries, and what happens at the ceiling, is on the pricing page, which reads the live catalogue.
For an outsider who needs to get in for a while, the tool is not an exception but an access request, with an expiry and a record, which is the subject of workspace access requests.
The client portal does not use this table
A portal contact holds none of these permissions, not one. They hold a part inside their own client, owner or reader, and they see what their agency lets them see of that client, which is a different set of screens from the one the team sees. The two systems are separate on purpose, because the question they answer is not the same: one distributes the internal work and the other decides what the agency shows.
The practical consequence is that inviting a client never consumes a team seat and never brings them closer to the internal screens, however much that person also works with you somewhere else. It runs the other way too: asking a client for access to their own accounts is a separate conversation with a checklist of its own, in how to request client access.
When somebody says they cannot see something
It is almost always one of three, and they are checked in this order.
- The wrong workspace. The same person can belong to several and hold a different role in each. If the address is not the one they think it is, the answer they are getting is the correct one.
- The plan. If the module is not paid for, no permission opens it, and the checkbox that would promise it is never drawn.
- The role. This one is fixed by ticking, and it is fixed by whoever holds the roles resource, which is rarely the person who asked for help.
There is a fourth case that is none of the three and looks worse: the whole workspace locked for want of a subscription, where no module and no permission counts and the only screen that answers is the subscription one. It is easy to tell apart, because it does not happen to one person, it happens to everybody at once.
