Teams
The Teams tab is where you manage the people in your organization: who's a member, what role each holds, how they report to one another, and what each person's account can access and sync. The first person to sign in for your domain is the Organization Owner.
Add people
Use Add member to invite teammates by email, or Import to bring a whole team in at once. For enterprises, roles and reporting lines can flow automatically from your identity provider via SSO & SCIM — add or remove a person there and their access here follows.
Assign roles
Each person holds one role, set from the Role column:
- Organization Owner — full control, including billing, ownership transfer, and the most sensitive settings.
- Manager — day-to-day use plus administration: configure pipelines and integrations, manage the team, and read the audit log.
- Member — day-to-day use: read the conversations in their scope, act on results, tune signals, and sweep tasks.
- IT Admin — runs the system (provisioning, SSO/SCIM, settings) but reads no conversation content.
Each role maps to a fixed, closed set of capabilities — one map for the whole product. For the full capability-by-role breakdown and the enterprise rationale, see Access control & roles.
Draw the reporting hierarchy
The Reports To column defines who reports to whom, and Visualize shows the resulting org chart. This hierarchy isn't just for display: in an organization using scoped visibility, it is the data-access policy — a manager automatically sees their team's conversations, and no one sees a peer's. See Least-privilege data access for the full model.
Access & sync, per person
Each row carries three switches so you control exactly how a person participates:
- ArcGlass access — whether the person can sign in and use the workspace at all.
- Sync meetings — whether their meetings are ingested and analyzed.
- Sync emails — whether their email threads are ingested and analyzed.
How permissions are enforced
There is one capability map for the whole product: routes and services are gated by the capability a role grants, not by ad-hoc role checks. Destructive actions require an explicit delete capability, content lists and details apply a row-visibility filter based on the viewer's scope, and identity always comes from the verified session — never from a value supplied by the caller. Role and scope are read at request time, so a change here takes effect on the next request.