Understand Roles and Permissions

Learn how membership, roles, module access, and administrative controls shape an organization workspace.

Before you begin

Identify the organization and the responsibility the user needs to perform. Avoid choosing a role only because its name sounds appropriate; review the organization’s configured permissions and module access. Organization owners and administrators should use the smallest access that supports the person’s work.

How it works

Membership establishes that an account belongs to an organization. A role then groups access decisions, while enabled modules determine which product areas the organization uses. Some high-impact settings remain limited to owners or administrators even when a user can work in the related module.

CapitalOS applies these boundaries to pages, actions, and server-side data access. This means a person can see a module but still lack a particular administrative action, or can belong to multiple organizations with different roles in each.

Step-by-step

Open organization settings and review Members to confirm the user’s active membership.
Review Roles to understand the permissions associated with each configured role.
Review Modules to confirm the required product area is enabled for the organization.
Match the user’s responsibilities to the least-privileged suitable role.
Assign or update access through the supported member and role controls.
Ask the affected user to reload the organization and test the exact workflow they need.
Verify both the module entry point and the specific action, such as editing, importing, configuring, or sharing.
Revisit the assignment when the person’s responsibilities change.

Check your result

The user can open the intended organization and complete the required task without receiving unrelated administrative capabilities. Modules outside their responsibilities remain unavailable. The user’s access in other organizations is unchanged.

Common problems

The role was changed but the screen looks unchanged: reload the application and confirm the active organization. Cached navigation can lag behind an access update.

The module is absent for everyone: verify that the module is enabled for the organization, not only present in a role definition.

The user can view but cannot configure: operational access and administrative settings are intentionally separate in several areas.

A direct link fails despite visible navigation: the linked record or action can require an additional permission or organization relationship.

Permissions and data notes

Role management itself requires administrative access. Treat role changes as security changes: document the business reason, avoid broad grants for convenience, and verify the exact outcome. Never use another organization’s role configuration as proof of access in the current organization.