Granting a permission, end to end

The flow#

1. Trigger — somebody's responsibilities change: they join, they leave, they take over a channel, or an audit finds a permission nobody needs.
2. User or external event — an administrator opens workspace administration and changes the member's permission.
3. Authentication and workspace resolution — the administrator's own session resolves to one workspace, and the change can only concern members of it.
4. Ingest — the change is submitted. Granting a permission an administrator does not themselves hold is refused rather than escalated.
5. Canonical record — the member's permission record is updated. It is a workspace record like any other, scoped and under the same policy.
6. Reasoning — none. This is an instruction, and treating it as anything else would be alarming.
7. Knowledge, memory and rules — unchanged. A permission is about a person, not about what Connect knows.
8. Autonomy and approval — untouched, and this is the distinction that matters most: autonomy is what Connect may do unattended, permission is what a person may do.
9. Action through a provider — none. Nothing leaves the workspace.
10. Result — the next request the member makes is decided against the new record. No sign-out, no waiting.
11. Relationship, timeline and memory — unaffected. Members are not the workspace's contacts.
12. Audit, usage and Needs You — an entry records who changed what for whom and when. Approvals made afterwards are attributed under the new permission.

Why it takes effect without signing out#

A session names a person and a workspace. It does not carry that person's permissions, which are decided against the record at the moment a request asks for something. The consequence is the one people want: removing a permission takes effect at the member's next action, not at their next sign-in, which would be an unbounded delay at exactly the moment urgency matters.

The visible exception is a screen already open. It shows the controls that existed when it loaded; pressing one of them now produces a refusal rather than an action. That is a stale page, not a permission that failed to apply.

What a permission does not do#

• It does not change what Connect may do unattended. That is autonomy, set per channel and per scope, and a person with every permission still works inside the workspace's autonomy rules.
• It does not widen the Assistant. The Assistant's rights are deliberately narrower than a person's — no pricing, and it cannot clear a do-not-contact entry — and granting a person a permission does not hand the Assistant one.
• It does not cross a workspace boundary. A permission is held inside one workspace; somebody who belongs to two holds two separate sets.
• It does not rewrite the past. Decisions already recorded keep the rule that was in force when they were made, which is what makes the trail readable later.

Doing it well#

1. Change one permission at a time when somebody's role changes.

   Result If something stops working afterwards, the cause is one line in the record rather than an afternoon of comparison.

2. Remove before you add, when responsibilities move between people.

   Result There is no window in which two people hold the same authority and each believes the other is handling it.

3. Ask the member to try the action rather than assuming it worked.

   Result Thirty seconds of confirmation, and a stale screen is caught before it becomes a support question.

4. Read the record when a behaviour changes unexpectedly.

   Result A permission change on the same date explains most surprises, and it is the cheapest thing to check first.

When it goes wrong#

The member still cannot act

The screen is stale, or the refusal is an audience boundary rather than a permission. See You do not have permission.

The grant was refused

An administrator cannot grant what they do not hold. That is a floor rather than an inconvenience: it stops permission being manufactured from below.

Nobody can administer the workspace

The last administrator was removed. This needs the operator rather than another attempt from inside.

A permission nobody remembers granting

The record answers it. Absence of an entry for a permission that exists is worth escalating rather than shrugging at.

Questions#

Related#

• Workspace administration
• Who may change what
• Adding a colleague, end to end
• You do not have permission
• Authorisation