Administer workspace access

Use this guide when a Member needs Workspace access or a refused action needs review. As an administrator, use Governance & Administration to check the grant and its result. Success means the intended access works and the decision can be traced.

Before you start

Confirm the Workspace, Member, intended action, and reason for access. Keep the request or refusal that started the review. You need authority for each change you make. A Role request needs a separate approver. Use the membership model to distinguish entry to the organization from access to its work.

For a failed writeback, retain its request or correlation identity. Confirm who may repair it before changing its state. The Console guide owns Workspace selection and sign-in. Use the API guide for authenticated calls outside the Console.

Check the Member

In the Console's Members page at /governance/members, inspect the person's current membership and any pending Join Request. Approve only the intended pending request. Confirm that the resulting Member belongs to the expected organization. Then inspect Groups at /governance/groups for the roster that grants access. An approved Join Request alone does not establish permission for the intended action.

Check the grant

In Roles at /governance/roles or Capability Bundles at /governance/bundles, inspect the actions granted and their scope. Choose the grant that matches the work. For temporary Role access, have the Member submit a Role request with the reason for use. The separate approver reviews it in Approvals at /governance/approvals.

Have the requester activate the approved request through the Role activation contract. Confirm the returned active grant and expiry before testing access. Check Field Access and the required Purpose if fields remain hidden. The Tag and field model explains why action permission can leave a field masked.

Checkpoints

The Workspace and Member must match the work being requested. The Group roster or Role grant must supply the intended action. A Role request must reach active access, not stop at approval. Test the intended action as the affected caller. Confirm that only the expected fields are visible. Record the request and decision so another reviewer can follow the change.

Success

The Member can perform the intended action in the intended Workspace. Required fields are visible under the approved Purpose and grants. Read the Audit Log at /governance/audit for the decision's actor and target. Keep the grant's expiry or review obligation with the access record. A screen that merely stops showing an error is insufficient proof of the intended scope.

When it fails

An access refusal identifies a check to resolve before the work proceeds. Keep the returned code and inspect the current state.

ROLE_ASSUME_FAILED

The Role request could not become active. Read its state, requester, expiry, Purpose, and any Role conflict. Resolve the named condition before requesting another activation.

WRITEBACK_REPAIR_DENIED

The caller lacks authority to override the writeback request. Have an authorized operator review the request. A denied repair leaves its state unchanged.

WRITEBACK_REPAIR_INVALID

The repair does not fit the request's current state. Read the request again and select a legal action. Repeating the refused repair cannot force the transition.

Recovery

For an access refusal, return to the missing membership, grant, Purpose, or control. Resolve that condition and test the same intended action again. Read the review and audit model when standing access or an earlier decision needs review. Do not widen a Role to hide an unresolved field or Purpose check.

For writeback repair, first read the writeback status for the original request. Have the authorized operator select the repair that fits its state and record the reason. The repair contract owns the call. Repair changes the request state and records its audit entry together. It does not call the external system.

After repair, read the same request again. Confirm its resulting state and the audit entry before closing the issue. A state change alone does not prove that the external system accepted the intended write. The Action run recovery workflow owns readback of that effect and any further recovery work.

Next steps

• The Access Review model explains how to revisit the grant and check removal when access should end.
• The controls model explains the review, Role conflicts, and spend checks that remain after access is granted.