Users & roles

The Users page (/org/users) is where you manage who belongs to the organization and what each person can do. Creating a user does not generate a password or an API key: access is always via browser login, and the new user sets their own password through an invitation email.

The roles

The organization has three roles. They determine where you land after login and your administrative reach:

Role	Identifier	Can
Organization administrator	org_admin	Manage everything in the /app console.
Skill administrator	skill_admin	Manage the skills in the groups under their responsibility (My Groups).
User	member	Use the agent within the policy; goes straight to the chat.

Internal roles don't appear here

Platform roles (internal to NNumbers) are not part of this console and are neither listed nor assignable from the organization's administration.

The user list

The list shows every user in the organization. You can:

• Search by name or email.
• Filter by role (organization administrator / skill administrator / user).
• Filter by status (active / inactive).

Each row shows the name, email, role, and status, and leads to the user's detail view.

Create a user

Use Create user and fill in:

1. Name — the display name.
2. Email — the work address (also the login identifier).
3. Role — Organization administrator, Skill administrator, or User.

On confirmation, Imaginne:

• registers the user in the organization;
• triggers an email for the person to set their password;
• sends a welcome email.

No password and no key

Creation does not generate a password or an API key. Access is browser-login only. If the email is slow to arrive, you can resend it via Password reset in the user's detail view (see below).

User detail

Opening a user gives you access to editing and to account actions.

Edit

The edit form lets you adjust:

Field	What it does
Name	Display name.
Email	Login address.
Role	org_admin / skill_admin / member.
User type	premium or full — used by the user type policy layer.
Local skill execution	Override: inherit / force allow / force deny.
Writes outside the workspace	Override: inherit / force allow / force deny.

About user type

premium and full exist in the policy as a user type layer. Today both share an identical permissive baseline — the distinction is a hook for future evolution. Don't rely on behavioral differences between them for now. See Governance & policies.

Execution overrides

The two overrides above act on the person, within the combination of policies (which follows deny-wins: a more specific level can only restrict):

• Local skill execution — whether this user can run skills that execute code on their machine.
• Writes outside the workspace — whether the agent can write files outside the workspace for this user.

In both cases, inherit keeps what the policy defines; force deny closes it even if the policy allows; force allow opens it only within what the baseline already permits — it never expands beyond the platform/organization.

Account actions

Action	Effect
Activate / Deactivate	Turns the user's access on or off without removing them from the organization.
Password reset	Triggers an email for the person to reset their password. Useful when they've lost access or the initial email has expired.

There is no user deletion

The console does not delete users. To revoke access, use Deactivate — the account stops working, but the audit history stays consistent.

Legacy key

If an older user still has a legacy key associated, the detail view may display a read-only card noting it. There's no way to create a new key: access is exclusively through your organization login. See Identity & login.

See also

🎭Profiles

With no profile, the user opens the chat empty.

Open →📜Governance & policies

How overrides combine with the policy layers.

Open →🪪Identity & login

The browser login and the session that carries the organization.

Open →