Accounts, organizations, and teams

MobSession gives your company a shared structure for the people who run sessions. An organization groups your members, teams group people inside it, and a session can belong to a team so only the right people can join. This builds on link-based joining, adding ownership, identity, and access on top.

Preview. This is in early access and rolling out to teams.

The model: organizations and teams

An organization represents your company. It is the top-level container for everyone who works together and the sessions they create. When you set one up, you become its owner and invite the rest of your company in.

A team is a group of people inside an organization, so you can mirror how your company works: a platform team, a frontend team, your on-call engineers. Someone can belong to one team or several, and teams are where session access gets specific.

Together they answer one question: who is allowed in this session, and who can see it afterward.

Roles

Roles stay deliberately simple in early access.

• Owner. Creates the organization, invites and removes members, manages teams, and sees the organization's sessions.
• Member. Belongs to the organization, joins sessions they have access to, and can be added to one or more teams.

Manage people from the organization switcher in the app header: open Manage organization to invite or remove members and edit organization details. Dedicated team pages for creating teams and assigning people arrive with the early-access rollout.

Inviting members

As an owner, invite people from the organization switcher's Manage organization panel. Send an invite, the person accepts, and they become a member. From there you add them to teams and give them access to team-scoped sessions.

Today, joining a live session doesn't require an account: a participant follows a link and they are in. In early access, organization membership and verified identity arrive with single sign-on, so the person joining a team session is a known, confirmed member of your company rather than just whoever holds the link. See SSO and access control for how that verification works.

Team-scoped sessions

A session can belong to a team. When it does, only members of that team can join. That is the difference between "anyone with the link can hop in" and "this session is for the platform team," and it is the main reason organizations and teams exist.

Reach for team scoping when a session should stay internal: a sensitive incident review, a hiring exercise, or work that shouldn't be reachable through a forwarded link. The team boundary sets the audience, and the owner can see these sessions from the organization view.

You can still create open, link-based sessions anytime. Team scoping is for sessions that should be limited, not a requirement on every session.

How this builds on link-based joining

Link-based joining stays the foundation. Everything above is additive.

• Open sessions keep working exactly as they do today. Share a link, people join.
• Organizations add a home for your company's members and a place to see your sessions.
• Teams add structure and a way to group people.
• Team-scoped sessions add a real boundary, limiting a session to the people who should be in it.

Adopt these layers gradually. Create an organization and invite a few people from /account, group them into a team, then scope a single session to that team to see how it feels.

What to expect in early access

Because this is in early access, the pages and behaviors here are still rolling out and may change. Identity and membership tighten as single sign-on becomes available to your organization. Treat team scoping as a way to organize and limit who joins, and plan your rollout accordingly.

To see where this fits the bigger picture, read the enterprise overview. For sign-in and access details, see SSO and access control.