Visual Space manual, Spaces, Create And Manage Roles

This walkthrough takes a role from a clear responsibility to a verified member assignment, then shows how to change or retire it without surprising the people who depend on it. Use it when a Space needs to delegate coordination, moderation, publishing, or administration without transferring ownership.

Before You Create A Role

You must be the Space owner or already have effective Manage Roles access. Decide what work the role owns, which Space members should receive it, and whether its authority belongs across the Space or only inside a Subspace or Activity.

Keep these distinctions in mind before changing permissions:

•

All members is the baseline - It applies to ordinary members and cannot be assigned to selected people. Change it only when the capability should apply broadly.

•

Named roles add grants - A member can hold several roles, and their applicable grants combine with the All members baseline.

•

Entry is separate from authority - A role does not join someone to the Space or admit them to a private area. Confirm membership and private access first; see Members and Invites and Space Privacy.

•

Local scope can change the result - A Subspace or Activity can inherit, allow, or deny a capability for that area.

Choose a responsibility-based name such as Event Host or Review Lead. A familiar title like Admin does not grant anything by itself, and a role's position in the list is not a dependable restriction on who may manage it.

Record the existing named roles, assignment counts, and separate All members baseline before creating or changing a responsibility.

Create And Configure The Role

•

Open Roles - Go to the Space administration area and open Roles. Review All members first so you know which capabilities every ordinary member already receives.

•

Add the role - Select Add role, enter a concise name in the Create role dialog, then choose Create. Select the new role when it appears in the role list.

•

Grant only the needed capabilities - In Permissions, enable the actions required for the responsibility. Group the decision around the actual job: Space structure, content stewardship, communication, Events or Goals, publishing, or role administration. Avoid enabling unrelated controls for convenience.

•

Treat Manage Roles as high impact - Grant it only when this responsibility genuinely includes creating roles, changing permission bundles, and managing assignments. Do not assume that a higher-looking role can safely control only roles beneath it; review explicit authority instead.

•

Configure staff display separately - Use List as admin or List as moderator only when members of this role should appear with the corresponding staff signal. These options do not grant administrative or moderation actions, and hiding the signal does not remove authority granted elsewhere.

Permission changes affect every member who holds the role wherever that version applies. Before moving on, leave and reopen Roles and confirm that the intended settings remain selected.

Apply The Right Scope

A role is created at the Space level. The Roles page for a Subspace or Activity lets you attach an existing Space role and decide how its capabilities behave in that narrower area.

•

Open the area's Roles page - Navigate to the administration area for the relevant Subspace or Activity rather than editing the Space root.

•

Attach the Space role - Select Add role, choose the existing named role, and confirm the action. This reuses the responsibility; it does not create a second unrelated role.

•

Review each local decision - Keep inherited when the broader choice is right for this area. Choose allowed or denied only when the local responsibility genuinely differs.

•

Check the most specific area - An Activity can make a more local decision than its parent Subspace or the Space. Verify access where the member will actually work instead of assuming the Space-level grant always wins.

Local overrides are useful for real differences in publishing, coordination, or moderation. If every area receives a different exception, effective access becomes hard to predict, so keep inheritance unless the work requires a deliberate change.

Assign A Space Member

•

Select the named role - Return to the Space-level Roles page and select the role. All members has no Members tab because it is not an assignable role.

•

Open Members - Choose the role's Members tab, then select Add member.

•

Find the person - Use Search space members... to find an existing Space member and select them. Choose Add to assign the role.

•

Confirm the assignment - Check that the person appears in the role's member list and that the displayed member count changes.

Assigning the role changes authority, not membership. If the person has not joined the Space, invite them first. If the work sits inside a private Subspace or Activity, make sure the person can enter that area before expecting its role permissions to help them there.

Verify Effective Access

Do not stop at the member count. The useful result is that the member can perform the intended action in the intended area—and does not receive unrelated power elsewhere.

•

Refresh the member's access - Ask the assigned member to reopen the Space or refresh their current view before checking the result.

•

Test the intended action - Have them open the relevant surface and complete a safe, reversible check, such as seeing the expected management control or opening Roles when their responsibility includes Manage Roles.

•

Test the intended boundary - If the role was attached only to a Subspace or Activity, confirm the same management action is unavailable outside that area unless another applicable role grants it.

•

Review combined grants - Remember that the result includes All members, every applicable named role, and any more local area decision. Removing or changing this one role may not remove an action that another role still grants.

If the member can enter an area but cannot perform the action, inspect the permission at the Space, Subspace, and Activity levels. If they cannot enter a private area at all, fix private membership rather than adding more role permissions.

Rename, Unassign, Or Delete Safely

Use the smallest change that matches the outcome. Renaming keeps the responsibility and its assignments. Removing one member ends that person's assignment while preserving the role for others. Deleting removes the permission bundle for everyone who holds it.

•

Rename for clarity - Select the role, choose Edit, update its name, then choose Save. Confirm the new name appears in both the role list and its details.

•

Remove one assignment - Open Members, find the person, and use the remove action beside their name. Confirm they disappear from the list, then recheck their effective access because another role or the ordinary baseline may still grant the action.

•

Review every affected scope - Before deleting, check the role's members and any Subspace or Activity where the role is attached or customized. Move ongoing responsibilities to another role when needed.

•

Delete the role - Select Delete, read the confirmation, and choose Delete again only when the role is no longer needed. Confirm it disappears from the role list and verify the affected workflows with the people who previously held it.

Deleting a role does not remove anyone from the Space. If the actual goal is to change membership, use Members and Invites. Ownership is also separate: creating, renaming, or deleting a role never changes the Space owner. Follow Transfer Space Ownership when final authority must move to another joined member.

Troubleshooting

Why is there no Members tab for All members?

It is the default capability baseline, not a named role. Create a named role when only selected people need the responsibility.

Why can the member still perform an action after I removed this role?

The All members baseline, another assigned role, or a local area decision may still grant it. Review all applicable sources of access at the place where the action occurs.

Why does the Space permission not match an Activity?

The Activity may inherit from or override its parent scope. Open that Activity's Roles page and inspect the local allowed, denied, or inherited decision.

Why does a staff badge not match the member's abilities?

List as admin and List as moderator are display choices. Enable or remove the operational capabilities separately.

Why can an authorized role manager not reach the expected control?

Ask the Space owner to verify that Manage Roles is effectively granted at the relevant scope and that no more local decision changes the result. Do not rely on role name, visual order, or an assumed rank rule.

For the complete authority model, including combined grants and area behavior, see Roles and Permissions.