Members & Access

#Purpose

Your organization is a single tenant on Opal — the top-level container that represents your company and holds its members, teams, roles, resources, and organization-wide settings. Members & Access is the part of it that deals with people: who is admitted, how they are grouped, what they are allowed to do, and how they prove who they are when they sign in.

Those are four separate decisions, and keeping them separate is what makes access manageable as an organization grows:

• Who is in — membership.
• How they are grouped — teams.
• What they can do — roles.
• How they sign in — security settings.

All four are managed in Organization Settings, the central area where an organization's profile and preferences, security, membership, teams and roles, billing, and credits are administered — so you are not moving between disconnected places to set up one person.

There is a reason to get this right early. As people and agents gain access to real information, real systems, and real decisions, Opal treats governance as foundational rather than as something added after deployment. Members & Access is the human, organization-level end of that: a small number of deliberate decisions about people and permissions, made once, that everything else in the organization then operates inside.

This page is the map. It introduces each of the four pages in this cluster, explains how they fit together, and tells you where to start.

#In This Section

• Members — How people join the organization: direct invitations, verified email domains that enable auto-discovery, and the join requests administrators approve. Members
• Teams — How to group members into teams and nested child teams, manage who belongs to each, and hand access to a team as a whole rather than person by person. Teams
• Roles & Permissions (RBAC) — How preset and custom roles work, and how they are assigned to individual members or to whole teams to determine what each can do across the organization. Roles & Permissions (RBAC)
• Security — The organization-wide controls over admission and sign-in: enforced multi-factor authentication, SAML single sign-on on the Enterprise plan, and the verified email domains that decide who can find their way in. Security

#Key Concepts

People join the organization. There are two routes in, and they work side by side. An administrator can invite someone directly, or add and verify the company's email domain — which enables auto-discovery, so people with a matching email address can join, or request to join, without waiting for an invitation. Administrators approve join requests, so self-service discovery does not become open access. See Members.

Teams group them. A team is a group of members, and teams can contain nested child teams — a team per department, with child teams for the functions inside it. Grouping people is not just tidiness: a team is a unit you can hand access to, so you describe the organization once instead of granting access one person at a time. See Teams.

Roles grant them permissions. Access across the organization is governed by role-based access control (RBAC). Administrators assign platform-wide preset roles or an organization's own custom roles to individual members or to whole teams. Assign to a member when only one or two people should hold that access; assign to a team when you want the access to follow the function. See Roles & Permissions (RBAC).

Security settings govern how they sign in. Three organization-wide controls sit here: enforced multi-factor authentication for all members, SAML single sign-on through the company's own identity provider on the Enterprise plan, and the email domains the organization has verified. Verified domains belong here as much as in membership, because they decide who can discover the organization in the first place. See Security.

Signing in and being allowed to act are different decisions. Security settings decide admission and authentication. Roles decide what a member can do once they are in. Neither substitutes for the other, so both are worth configuring deliberately.

Roles are not the whole access picture. Whether an action is available depends on three things: your organization's plan, the role permissions granted to you, and the permissions on the individual resource you are working with — a resource can be shared with specific members or with teams, each at a permission level, on the Business and Enterprise plans. This cluster covers the first two at organization level; the full model is documented once, in Access & Permissions, and the resource-level controls around sharing, versioning, and auditing are covered by Governance.

Short definitions of the terms used here are in one place: Glossary.

#Where to Start

If you are setting an organization up, work through the four pages in rollout order. Each one assumes the previous is in place.

1. Members — get the right people in, by invitation or by verifying your company's email domain. Members
2. Teams — build the structure those people sit in, so access can be granted to groups rather than individuals. Teams
3. Roles & Permissions (RBAC) — grant each member or team the access their work calls for, starting with the preset roles and defining custom roles only where the presets do not fit. Roles & Permissions (RBAC)
4. Security — align sign-in with your company's standards by enforcing MFA and, on the Enterprise plan, configuring SAML single sign-on. Security

If your organization is already running and you are here for one thing — adding a joiner, moving someone between teams, tightening sign-in — go straight to the page that covers it.

If you are reviewing how access has been granted, read Access & Permissions for the full model, then Governance for the audit log and the resource-level controls that sit alongside roles.

For the rest of organization-level administration — the organization's profile and preferences, billing and credits, platform configuration, and governance — start from Organization.