Invite and manage your team

Once documents are in, the next move is bringing people in. The users tab at /admin/users handles every part of that lifecycle: inviting, resending lost invites, changing roles, resetting passwords, and removing people who leave. None of it is complicated, but a few of the defaults are worth knowing before you start clicking.

Three roles, in plain English

Employee. Chat only. Logs in, asks questions, sees source citations, thumbs up or down. Cannot see the admin panel at all.

Manager. Chat plus the admin tabs they need to keep the library current: Documents, Q&A log, and the unanswered events queue. Cannot change tenant settings. Cannot invite or remove other users.

Admin. Everything. Settings, billing, user management, everything Manager can see, plus the Danger Zone.

The default for a new invite is Employee. Promote someone to Manager or Admin only when they actually need the elevated access. The deeper reference at roles and permissions covers the exact matrix.

Who can invite

Admins only. Managers cannot invite or remove users. If you want to delegate user management, you have to make that person an Admin; there's no half-step.

Inviting someone

From /admin/users, click Add user. The dialog asks for two things: an email address and a role (radio buttons for Employee, Manager, Admin). Click Send invite.

You don't pick a name for the invitee. They tell us who they are when they finish setup.

What the invitee sees

An email from Muninnbase with a link to finish setting up their account. The link is single-use and time-limited; once they use it, the link no longer works. If the email gets caught in spam, the first place to check is the user's junk folder.

On the linked page, the invitee enters their full name, chooses a password, and accepts the Terms of Service. After they submit, Muninnbase signs them back out and asks them to sign in fresh with the password they just set. That extra round-trip is intentional. It confirms the password works before they reach the chat or admin surface.

In the users table, the row reads Pending until they sign in for the first time. Until they finish setup, the name column shows the invitee's email address as a placeholder. Once they finish, the row flips to Active and the column updates to their actual name.

The users table

Per row: name and email, role, status (Active / Pending / Disabled), last login (or "Never" if they haven't logged in yet), and a three-dot row menu. The search box at the top filters by name or email. The role and status badges make at-a-glance audits easy ("who in our company is currently an Admin?").

Resending an invite and resetting a password

Pending users have a Resend invite action in the row menu. Use this when someone says the email never showed up or they let the original link expire. The new email contains a fresh link; the previous one stops working.

Active users have a Reset password action. It sends a link the same way an invite does. Useful when an employee forgets their password and doesn't want to use the self-service forgot-password flow on the login page.

Both emails go out through Muninnbase's email pipeline. There's nothing to configure on your end and nothing to copy and paste; clicking the menu item triggers the send.

Changing roles

The three-dot menu has a Change role action. Pick the new role and confirm. Roles take effect immediately; the next time the affected user loads a page, they see the new permissions.

One guard: you can't demote the only Admin. Muninnbase won't let the tenant strand itself without anyone who can manage settings or users. If you need to swap who the primary Admin is, make the new person an Admin first, then demote the original.

Removing a user

The three-dot menu has a Remove action. Removing a user revokes their access immediately and deletes their account.

A note on the Q&A log: the log does not track who asked which question (logs are anonymous, as covered in review the Q&A log), so removing a user does not remove their past questions. Those rows stay in the log without a name attached, just as they were when they were created.

Who should be an Admin

Two people, typically. The owner-operator and one backup. Promoting everyone to Admin sounds collaborative but it makes destructive actions (deleting a doc, wiping the tenant) easier to do by accident. Managers can handle the day-to-day library upkeep without needing Admin access; that's the role's whole point.

What to do next

With your team in, the next thing worth doing is opening the Q&A log and seeing what they're asking. Do it in week one and you'll learn more about your knowledge base in five minutes than from a month of meetings.