Visual Space manual, Spaces, Roles And Permissions

Roles let a Space divide responsibility without forcing every community into the same staff structure. A film collective might use `Producer` and `Review Lead`; a study group might prefer `Facilitator` and `Curriculum Maintainer`. Each name represents a bundle of capabilities that can be reused for several members and, when needed, limited to a particular part of the Space.

Roles let a Space divide responsibility without forcing every community into the same staff structure. A film collective might use Producer and Review Lead; a study group might prefer Facilitator and Curriculum Maintainer. Each name represents a bundle of capabilities that can be reused for several members and, when needed, limited to a particular part of the Space.

The Authority Model

Four layers work together, and each answers a different question:

•

Ownership provides the single recovery and final-authority position for the Space. It is not an ordinary role.

•

All members sets the default capabilities for ordinary members.

•

Named roles add capabilities for the people assigned to them.

•

Area rules can adapt those defaults and roles inside a Subspace or Activity.

Entry comes before authority. Someone must still be a member of the Space and, for a private area, have access to that area before a role can help them there. Membership explains the community relationship, while Privacy explains protected entry.

This separation is useful in real communities. You can welcome many members, admit a smaller group to sensitive work, and delegate only the capabilities each person needs without turning every trusted contributor into the owner.

Start With All members

All members is the Space-wide baseline. It appears on the Roles page so managers can decide what an ordinary member may do before any named role is considered.

New published Spaces begin with common participation actions available, such as creating posts and adding reactions, Awards, or comments. Broad management actions begin disabled. Because a change here affects everyone, keep the baseline conservative and move specialized authority into named roles.

Despite its placement in the role list, All members is not an assignable role:

•

It has no member list because every eligible member receives its baseline.

•

It cannot be renamed or deleted.

•

It should not carry an admin or moderator display identity.

•

It does not replace private-area membership.

Use it for behavior that genuinely belongs to ordinary participation. For example, allowing comments across the community is a good baseline decision; allowing every member to manage roles is not.

The role roster keeps the ordinary-member baseline visibly separate from named responsibilities and their current assignment counts.

Build Roles Around Work

A named role should describe a responsibility people recognize, then grant the capabilities needed to perform it. Familiar names such as Admin, Moderator, or Coordinator can be useful, but Visual Space does not require them.

The available capabilities cover several kinds of work:

•

Space structure and guidance, including settings, rules, Subspaces, and Activities.

•

Coordination surfaces such as Chat, Events, Goals, announcements, and Expo.

•

Participation actions such as creating posts, commenting, reacting, giving Awards, or awarding the rarer, lasting recognition of Medals.

•

Content stewardship, including reviewing and removing inappropriate content.

•

Role administration through Manage Roles.

Prefer several clear roles over one oversized role that grants every available capability. A role for event hosts can manage Events without changing Space structure; a moderation role can review content without controlling Roles. This makes access easier to review when responsibilities change.

Role names do not grant authority by themselves. A role called Admin only has the capabilities enabled for it, while a locally named role can be powerful if its permissions say so. Likewise, the role's position in a list is not a reliable access boundary. Grant high-impact capabilities explicitly and review them directly.

How Grants Combine

A member may hold more than one role. At a given scope, applicable grants combine with the ordinary-member baseline. If All members allows posts and an assigned role allows Event management, the member can do both where those grants apply.

Think through access in this order:

•

The Space owner retains recovery authority across the Space.

•

All members supplies the ordinary Space baseline.

•

Every applicable assigned role contributes its granted capabilities.

•

A Subspace can inherit, allow, or deny a capability for that area.

•

An Activity can make the most local decision for work inside that Activity.

The Roles interface represents area choices as allowed, denied, or inherited. Inherited keeps the broader decision. Allowed or denied creates a local override, so a narrower area can be more open or more restricted than its parent for that capability.

This means a Space-level grant should not be read as unconditional authority everywhere. If a member can create posts across most of the Space but a particular Activity denies that action, the Activity's local decision applies there. Conversely, a role can be attached to one Subspace or Activity and receive local capabilities without gaining the same authority across the rest of the Space.

Scope Roles To The Right Area

Create and name roles at the Space level, then attach the relevant role where it is needed in a Subspace or Activity. This preserves one recognizable responsibility while allowing its capabilities to fit the work.

For example, an Event Host role might have no structural authority at the Space root, manage Events inside a program Subspace, and inherit that decision in most of its Activities. One sensitive Activity could deny Event changes locally, while another could add a related coordination capability.

Use a local override when an area has a real difference in responsibility, publishing rules, or moderation needs. Avoid customizing every Activity without a reason. Too many exceptions make it difficult for owners and managers to predict what a member can do.

Assign People Without Changing Membership

Each named role has a Members view. A manager can search among Space members, assign the selected role, review who currently holds it, and remove the role when that responsibility ends.

Assignment changes authority, not membership:

•

Adding a member to a role does not invite them to the Space or grant entry to a private area.

•

Removing a member from a role does not remove them from the Space.

•

Removing one role leaves the member's other roles and ordinary-member baseline in place.

•

Assigning several roles lets the member receive all applicable grants from those roles.

Before assigning a scoped responsibility, first confirm that the person can enter the relevant area. Then grant only the capabilities they need and verify the result from that area's normal surfaces. For the connected creation, permission, assignment, and verification flow, follow Create and Manage Roles.

Display Signals Are Not Permissions

List as admin and List as moderator control how members of a role may be presented in community surfaces. An admin listing can add a staff-style shield, while a moderator listing can place people in moderator-oriented displays.

These settings are visibility signals, not authority bundles. Turning on List as moderator does not grant content review, Chat management, or any other moderation action. Turning the signal off does not remove capabilities already granted elsewhere. Configure the operational permissions first, then choose whether the people carrying that responsibility should be visibly identified.

Who Can Manage Roles

New Spaces keep role management with the owner. The owner can delegate it by granting Manage Roles through a named role. Effective owner or Manage Roles access is required to create, rename, configure, assign, remove, or delete roles.

Treat Manage Roles as a high-impact capability. A person who can change permission bundles can affect several members and areas at once. Do not rely on role names, visual order, or an assumed higher-versus-lower ranking to contain this access. Give it only to trusted managers whose role-administration responsibility is clear.

The Space owner remains separate even when another member has broad management capabilities. There is only one owner, and ordinary role assignment cannot replace or remove that recovery boundary. Ownership changes through an explicit transfer, not through the Roles page; see Transfer Space Ownership.

For the wider set of customer-facing management surfaces, continue with Space Administration. Member invitations and joined-state changes belong in Members and Invites, not in role configuration.

Change And Remove Roles Carefully

Renaming a role keeps the same responsibility bundle and assignments while giving it a clearer local name. Changing a permission alters what every assigned member can do wherever that version of the role applies, so review its Space, Subspace, and Activity use before making a broad change.

Deleting a role removes that responsibility bundle for all assigned members. It can therefore take away several people's working authority at once. Before confirming deletion:

•

Check the role's member list and tell affected people when the change will interrupt their work.

•

Review Subspaces and Activities where the role has been attached or customized.

•

Move ongoing responsibilities to another role when they still need an owner.

•

After the change, verify the affected actions from the relevant area rather than assuming another role covers them.

If the goal is to remove responsibility from one person, remove that member from the role instead of deleting the role for everyone.

Common Questions

Can I assign All members to selected people?

No. It is the default permission baseline for eligible members, not a role with assignments. Create a named role for a selected group.

What happens when a person has two roles?

Applicable grants from both roles combine with the ordinary-member baseline. A more local Subspace or Activity decision can still change the result in that area.

Does a Space role automatically work in every Activity?

Not unconditionally. The role must apply to the relevant scope, and Subspace or Activity overrides can inherit, allow, or deny individual capabilities.

Does private-area access give someone role permissions?

No. Private membership grants entry. Roles decide what the person can do after entering.

Does List as admin make someone a Space Admin?

No. It changes how role members may be displayed. Actual authority comes from enabled capabilities.

Can a delegated manager change roles?

Yes, when their effective access includes Manage Roles. Because that capability can reshape authority for many people, the owner should grant it sparingly.

Can one role safely manage only roles shown below it?

Do not depend on visual ordering or presumed rank for protection. Use explicit capabilities and reserve Manage Roles for people trusted with the role system.

Does deleting a role remove members from the Space?

No. It removes the role and its permission bundle. The people remain Space members unless their membership is changed separately.

Can I have more than one owner by creating an Owner role?

No. A role named Owner is still an ordinary named role. The Space has one actual owner, changed only through the ownership-transfer flow.