Authorisation
Five separate questions stand between a click and an action: who you are, whether your session may call this at all, which workspace answers, whether your role permits it, and whether the workspace is entitled to spend on it. A sixth — whether Connect may act without asking — is autonomy rather than permission. Each refuses in its own words, which is how you tell them apart.
The order the questions are asked#
| Question | Decided by | If the answer is no |
|---|---|---|
| Who are you? | The session, from Google sign-in | You are sent to sign in; nothing that acts is reached |
| May this session call this at all? | The customer surface, closed by default | A refusal saying the address is not part of your workspace |
| Which workspace answers? | Your membership, carried by the session | Nothing is refused — you simply see your own workspace's records |
| Does your role permit it? | The membership's role, checked explicitly on configuration | A refusal naming the administrator role as the requirement |
| May the workspace spend on it? | The plan and the day's counters | A plan or allowance message, naming the state or the reset |
| May Connect do it unasked? | The workspace's own autonomy rules | Nothing is refused; the action is held for a person |
Reading the wording tells you which question failed, and therefore who can fix it. That is the whole practical value of keeping them distinct: a role problem is solved by an administrator in seconds, an entitlement problem by money or by midnight, and a surface problem by JBRH.
Roles inside a workspace#
A membership carries a role as well as a workspace. Configuration that changes how a workspace behaves — connecting a carrier is the clearest example — checks for the administrator role explicitly and refuses anyone else with a sentence that names the requirement rather than a generic denial.
- Only an active membership counts. An inactive one is not a member with fewer rights; it is not a member.
- One person holds one membership per workspace, so two conflicting roles for the same person cannot exist.
- Working the queue — approving, editing, rejecting — is recorded against the individual, which is what makes a decision log worth reading months later.
- Belonging to several workspaces is normal and grants nothing extra in any of them.
Reaching across workspaces#
Some platform work legitimately has to read across every workspace: matching an incoming payment notice to whichever workspace is expecting it, a retention sweep, the operator's own platform console. That capability exists as one explicit mechanism rather than as a scattering of exceptions, and it is deliberately awkward to reach for — it will not run at all without a stated reason, so it is greppable, reviewable and obvious in a change.
What a refusal looks like, and what it never contains#
Refusals are written for the person who met them. They say what was refused and why in ordinary words, they name the requirement where there is one, and where the cause is a gap on our side they say so rather than implying the reader did something wrong.
- No stack trace, no internal path, no module name, no milestone or project code.
- No raw provider error containing identifiers.
- No hint about what else exists. A refusal is not a place to enumerate the surface.
- No blame. A screen that offered an action it should not have is a defect worth reporting, not a mistake by whoever pressed it.
There are also things nobody is authorised to do, whatever their role. The Assistant cannot clear a do-not-contact entry, for instance: that is a fixed gate rather than a permission anyone can be granted. Explicit gates lists them.
Questions#
Can I be given permission to see another workspace's records?
No. Membership is how anyone sees a workspace, and cross-workspace reading is a platform mechanism used by the control plane rather than a right that can be granted to a person. If you need to work in two workspaces, you need a membership in each.
Why does one screen say I need to be an administrator and another just refuses?
They are different questions. The first is your role inside a workspace you belong to, which an administrator can change. The second is the surface itself, which is not a permission at all — it is a decision about what belongs to a workspace and what belongs to the platform.
Is autonomy a permission?
No, and conflating the two causes real confusion. Permission decides whether a person may cause something. Autonomy decides whether Connect may do it without asking a person first. A held draft is not a refusal — it is the rule working.