Roles, Permissions, and States Reference

Separate role, permission, and state

Roles, permissions, and states answer different access questions. Use this reference to read them together and check what a visible status actually proves.

Role gives context

A role is a label for responsibility or the kind of work someone may handle. Owner, Admin, Manager, Finance, Member, Billing, and Viewer can describe duties. A role label alone does not authorize a person to open a source or change a setting.

Permission sets the boundary

A permission is a decision about an actor, capability, source, purpose, and condition. It answers whether a specific person or role may do a specific thing now.

Scope can include an organisation, team, device, resource, or time limit. The permission, not the label alone, makes a use eligible.

State shows what is current

A state is the recorded condition of an object or decision. It may say that a request is waiting, a connection is ready, or access is no longer active. State tells you what the record says now; it does not explain why the state is true or extend its scope.

Start with the single-Mac view

The current Team area shows the local path and plan or capability information available on this Mac. It does not provide a complete people roster or prove that a descriptive role is assigned elsewhere. A label in an example or old record is not evidence of a current assignment.

When you investigate access, do not treat a local plan card as permission. Inspect the source owner, selected audience, current permission, and visible evidence. Read the Team area guide for the observable product path.

Follow an access decision

Begin with the requester, capability, source, purpose, and conditions. A reviewer checks the current permission and records the outcome. If scope is missing, expired, narrowed, paused, denied, or revoked, stop; an absent affirmative decision is not permission.

Common states include pending, active, suspended, revoked, accepted, expired, approved, denied, connected, error, and disconnected. Each word belongs to its record. A connected state does not prove that every resource is in scope, and an approved state does not keep a later request approved.

Transitions show how a record moved. Ask who made the change, what scope was considered, when it occurred, and which record explains it. Do not infer a transition from a changed label alone.

Useful evidence is the smallest record that supports the conclusion. For a role, capture its source and intended responsibility. For permission, capture actor, capability, source, purpose, scope, decision, and review date.

For state, capture the object, value, time, reason, and visible next action.

When purpose changes, narrow the source, capability, audience, or time condition before continuing. If the boundary is unclear, pause and ask the responsible owner. When work ends, revoke the applicable grant and recheck the resulting state.

Keep private messages, credentials, tokens, and unrelated records out of screenshots and support notes. A citation helps someone check an answer; it does not grant access or prove freshness.

Verify before relying on a state

• Identify the object, actor, source, purpose, and environment.

• Read the current state and timestamp.

• Find the permission supporting the specific capability.

• Check scope, reviewer, transition reason, and revocation path.

• Stop when the answer depends on information this Mac does not receive.