Managing organisation-level access

Overview

Everything else in this course provisions structure. This lesson provisions reach.

Access on the platform is not one ladder. It is three separate things, and confusing them is how people end up with more access than anyone intended.

Those three are what grant access. Teams still exist at organisation level, but they grant nothing today and have no management interface — they are kept for organisation-wide features not yet built. A project's people are project members, added directly and individually; nothing is granted to a project through a team.

How a project gets its first member

An organisation and its projects are provisioned by the Org Admin, which is Kapitable. The customer does not create projects.

So each project starts with one deliberate act: the Org Admin invites one person as Project Admin. From there the customer runs itself — that Project Admin invites the rest of the team and manages their roles, without needing us again.

That shape matters for two reasons. It keeps project membership in the hands of the people who know who should be on the deal, and it means the first invitation is the one grant to get right: whoever receives it can extend access to anyone else.

What you'll learn

• Why Super Admin is not access to data

• What makes Org Admin qualitatively different from a project role

• Why removing access is the harder half

• What to review, and how often

Super Admin is not access to data

Worth stating first because it is counter-intuitive: Super Admin status does not by itself grant access to customer data. A Super Admin administers the platform. To see a customer's projects they must be deliberately added as an Org Admin of that organisation.

That separation is a feature. Do not treat Super Admin as an all-access role.

Org Admin is the grant to be careful with

An Org Admin has access to every project beneath the organisation — including, crucially, projects that do not yet exist. A grant made today covers deals signed next year.

Compare that to a project role, which reaches exactly one project and has to be granted again for the next. Org Admin is qualitatively different, not just broader — and the invite dialog gives no indication of that forward reach.

So:

• Grant it to few people, and to people whose role genuinely spans the firm's whole portfolio.

• Do not grant it to solve a project-level problem. Someone missing a button on one project needs a project role (A2.6), not organisation-wide reach.

• Review it. A project role becomes irrelevant when a project ends; an Org Admin grant does not expire.

The invite is a single email address, and the platform tells you if that person already holds the role.

Removing access is the harder half

Project roles are per project. Removing someone from one project does not remove them from another, and there is no single screen that removes a person everywhere.

So departures need a checklist, not memory. Write it down for your organisation: which projects, and which Org Admin grants.

User Accounts in the administration area lists the platform's users and when their accounts were created. It is a directory rather than a revocation tool, but knowing who exists is the first step in knowing who should not.

Be aware of the gap this leaves: there is no single view of a person's access. To answer "what can this person see?" you must check every project's members list, plus Org Admin grants. On an organisation with twenty projects, a checklist is the honest workaround.

Practical guidance

• Narrowest level that works, always.

• Org Admin deliberately and rarely.

• Never Super Admin as a shortcut to data.

• Departures need a checklist covering every project.

• Review Org Admin grants periodically — nothing else will prompt you.

Common problems

A Super Admin cannot see a customer's project. Intentional. Add them as Org Admin of that organisation if they need it.

Someone still has access after leaving a deal. Project roles are per project. Check each one.

You are about to grant Org Admin to fix one missing control. Do not. That is a project-level role question (A2.6).

Nobody knows who has access to what. There is no single view of a person's access across the organisation. Keep your own record.

Related

• C1.1 — Organisations · where Org Admin is granted

• A1.4 — Roles and what each can see · the project-level roles

• A2.6 — Access control in practice · resolving a project-level problem properly

• A5.10 — Traceability: what the platform records · the other half of a controls conversation