Access control & roles

Your field conversations are among the most sensitive data your company holds — deal terms, pricing, personnel, legal, and strategy. An enterprise buyer needs a precise answer to two questions: who can do what, and who can see what. ArcGlass answers both with a model that is explicit, enforced in one place, and — crucially — requires almost no per-user configuration to keep correct.

Two orthogonal axes

Access in ArcGlass is governed on two independent axes. Keeping them separate is what keeps each one minimal and auditable:

• Roles gate verbs — may this person invite a member, configure a pipeline, delete an analysis, change billing?
• Data scope gates rows — which meetings and emails does this person actually see?

"Team manager" is not a special role. A manager is simply a member whose data scope follows the reporting tree. Verbs and visibility move independently, so a role never quietly carries more data access than it needs.

Roles — who can do what

Every member of an organization holds one role. Each role maps to a fixed set of capabilities from a single, closed list — there are no ad-hoc per-feature toggles to drift out of sync.

• Member — day-to-day use: read the conversations in their scope, act on results, tune signals, sweep tasks, and create lists.
• Manager — everything a member can do, plus delete, configure pipelines and integrations, manage members and reporting lines, and read the audit log and spend.
• IT Admin — runs the system (provisioning, SSO/SCIM, integrations, org settings, members and reporting lines, audit) but reads no conversation content and touches no billing. The people who administer the tenant don't have to be trusted with the deals inside it.
• Organization Owner — full control, including payment, ownership transfer, deleting the organization, and viewing restricted conversations.

Separation of duties, by design

The role set is built so that the most sensitive powers never travel together:

• The person who administers the tenant (IT Admin) cannot read a single conversation.
• The person who pays the bill needs no access to conversation data.
• Only the Owner can do the irreversible things — change payment, transfer ownership, delete the org.
• Destructive actions require an explicit delete capability — deleting is never an incidental side effect of "edit".

Data visibility

Roles decide the verbs; data scope decides which conversations each person sees. By default everyone with content access sees all conversations; turn on scoped visibility and access follows your org chart — you see your own and your team's conversations, never your peers'. The full model, including how the boundary is drawn, is in Least-privilege data access.

Separately, some internal conversations — HR, compensation, legal — shouldn't be in the shared picture at all. The sensitivity classifier restricts or sets those aside automatically; see Sensitive & restricted conversations.

Why this holds up under enterprise scrutiny

• One capability map, not scattered checks. A single closed set of capabilities is the only thing routes and the UI ever test, defined once on the backend and mirrored to the frontend. New features gate on a capability — there's no second place for permissions to drift.
• Least privilege and separation of duties are structural, as shown above — not conventions a reviewer has to trust.
• Changes take effect on the next request. Role and scope are read from your membership record at enforcement time, not baked into a long-lived token. Demotions, offboarding, and reporting-line changes apply immediately — no waiting for a session to expire.
• Provision and deprovision at scale with SSO & SCIM: roles and reporting lines flow from your identity provider, and removing someone there removes their access here.
• Everything sensitive is on the record — the audit log captures administrative and access-relevant events for review.