Module 1 — Getting Started · Lesson 1.5
Inviting Your Team
Invites, roles, the approval queue, and the two ways people arrive without an invite
~11 min
What you'll learn
- Invite a member and choose the right role for them
- Explain the difference between owner, admin and member
- Use the invite policy and the approval queue to control who can invite whom
- Recognize domain auto-join as an access decision, not a convenience setting
Adding people is the first irreversible-feeling thing you do in a new workspace, and it is where the difference between a personal notebook and a team system gets decided. The mechanics take a minute. The decisions behind them are worth thinking about for five.
The invite flow
Open People under the Workspace group. Use Invite, enter the email address, and pick a role. Kavanah sends them an email with a tokenized link; clicking it brings them into the workspace, creating an account first if they do not have one.
An invite is per-email-address and per-workspace. Inviting someone who already has a Kavanah account does not create a second account — it adds their existing account to this workspace, and they will see it in their workspace switcher.
Pending invites are visible in the directory, and their state is reconciled when the page is read, so an invite that has expired shows as expired rather than sitting there looking live. Re-inviting is the fix.
Owner, admin, member
Owner is the account that created the workspace. It can do everything an admin can, plus the workspace-ending things.
Admin can configure the workspace: integrations, agent settings, permissions, custom statuses and properties, API keys, directory sync, billing. Admins are also who can edit the KVN charter, manage deal-room stages and cadences, and turn on the opt-in agent features. If someone is going to set Kavanah up, they need admin.
Member can do the work: create and update tasks, comment, track time, chat, use the agent within whatever ceiling the admins have set. Members cannot change workspace configuration.
The useful heuristic is that admin is a configuration role rather than a seniority role. The person who will connect Gmail and write the charter needs it; a senior person who will only ever work tasks does not.
Who is allowed to invite
By default, letting every member invite anyone is a fine policy for a small team and a bad one for a growing company, because it is how a workspace ends up with people nobody remembers adding.
Kavanah has an invite policy setting for exactly this, plus an approval queue: when the policy requires it, a member's invite becomes a request that an admin approves or declines rather than an email that just goes out. The queue is the audit trail — you can see who wanted to add whom, and when.
Set this before you need it. Tightening the policy after fifteen people have already joined does not remove anyone.
The two ways people arrive without an invite
The first is directory sync. If your organization runs an identity provider — Okta, Azure AD / Entra, OneLogin, or any generic SCIM client — an admin can connect it under Settings → Directory sync, and the provider pushes users in and deprovisions them when they leave. This is the right answer at any real company size, and Module 11 covers it in full.
The second deserves a warning. Verified-domain auto-join means anyone who signs up with a matching email domain lands in your workspace automatically. It is genuinely convenient at a company where everyone with an @yourcompany.com address should be in. It is an access-control decision, not a convenience toggle, and the asymmetry is what to remember: auto-join adds people, and nothing removes them later. If someone leaves the company, their Kavanah membership persists until a human removes it.
So: turn it on deliberately, on a domain you actually control, at a company where the statement 'everyone with this domain should see this workspace' is true. Otherwise leave it off and invite people.
What a new member sees
A new member lands in a workspace where they can see the projects they have access to, the chat channels they are in, and their own empty My Work. What they cannot see is anything gated by per-project access — Kavanah has per-project and per-task ACLs, covered in Module 3, and a project someone is not on simply does not appear.
The common new-member complaint is 'I can't see the board' and the common cause is exactly that. It is not a bug and the fix is one click on the project's Team tab.
Get your team in
- 1
Whoever will help you configure the workspace. Doing setup alone is how a workspace ends up with exactly one person who knows where anything is.
- 2
Decide now whether members can invite freely or whether invites go to an approval queue. Settings → Permissions.
- 3
Decide about domain auto-join deliberately
Settings → Directory sync. Leave it off unless 'everyone with this email domain belongs here' is true, and remember nothing removes them later.
- 4
Check the directory after they accept
Open People and confirm roles are what you meant. This is also where you edit or deactivate a member later.
What to watch
- Invite acceptance rate
- Share of sent invites that are accepted within a week.
- Healthy signal: High. A low rate usually means the invite arrived with no context — a note in chat saying what the workspace is for fixes it faster than a second invite.
- Admin count
- How many members hold the admin role.
- Healthy signal: Our suggested shape: at least two (a single admin is a bus factor of one), and few enough that you could name them. Admin is a configuration role, not a seniority reward.
- Unattached members
- Members who belong to the workspace but are on no project and have no assigned work.
- Healthy signal: Near zero. A growing number here is the signature of auto-join running unattended.
Key takeaways
- ·Invite from People; an invite adds an existing account to this workspace rather than creating a second one.
- ·Admin is a configuration role, not a seniority role — give it to whoever will actually set things up.
- ·The invite policy plus the approval queue is how you stop a workspace filling with people nobody remembers adding.
- ·Directory sync provisions AND deprovisions; domain auto-join only ever adds.
- ·'I can't see the board' is almost always per-project access, fixed on the project's Team tab.
One lesson left in this module: the checklist that turns a workspace with people in it into a workspace that actually works.