Self-registration and approving new members

When someone in your company signs in to StackJack through an AI tool without having been invited first, they are not blocked — they are added to your team automatically in a pending approval state. Their AI tool connects, but with almost nothing enabled, until an admin approves them. This page explains both sides: what the new user experiences, and exactly how an admin approves (or denies) them.

A direct portal sign-in never self-registers: an uninvited coworker who signs in to the portal itself sees "No StackJack Account Found" there and needs an invite. And anyone Directory sync provisioned never appears pending at all — the sync creates them active, with their roles already assigned.

How self-registration happens

A user whose identity belongs to your organization signs in through an AI tool's "Sign in with StackJack" flow. If they have no invite and no existing membership, StackJack:

• Creates a team membership for them with the Member role, active immediately.
• Grants them only a placeholder status tool — no connector tools, no support tools.
• Lets the AI tool finish connecting normally.

The result: the connection works, but it is a waiting room, not access.

Only genuinely new, signed-in coworkers land in pending. A previously deactivated member who tries to reconnect is denied outright (they need you to reactivate or re-invite them), and someone with no connection to your organization can't self-register at all.

What the pending user sees

In their AI tool: the connection succeeds, but only a small set of read-only StackJack status tools is available (stackjack_session_info, stackjack_list_tools, stackjack_health_check, service status, advisories, release notes, tool guidance, and tool-list refresh). No connector tools appear. Asking the assistant to run stackjack_session_info returns a status of pending_approval with a message telling them to have their administrator go to the portal's Team page and assign them permissions.

In the portal: the main portal pages — Dashboard, Connectors, Endpoints, Team, Roles, Directory Sync, Billing, and Permissions — show an Awaiting Approval notice (support code SJ-ACCESS-AWAITING-APPROVAL): "Your identity is recognized, but your administrator still needs to approve your Portal access." It includes the workspace name, their signed-in email, and a pre-filled support email link.

The wording differs slightly between the two surfaces ("accept you to the team" in the AI tool, "approve your account" in the portal) — both mean the same thing, and the action an admin takes is the one below.

Tip for pending users: either of these is the fastest way to confirm you are in the pending state rather than misconfigured — run stackjack_session_info from your AI tool, or sign in to the portal and look for the Awaiting Approval panel.

How to approve a pending member (admins)

Who can approve: the account owner, co-owners, and Administrators.

The important thing to know up front: there is no "Approve" button. The actual approval action is giving them tools — and there are two ways to do it. Edit Roles assigns one of your organization's tool roles; Edit Tools hand-picks individual tools. A role's tools reach the member's AI tool on its next request exactly as hand-picked tools do — but Edit Roles alone does not clear the portal's Awaiting Approval panel: the placeholder status tool stays on their row (it reads "Role tools + 1 tools") until an explicit tool write lands. Edit Tools clears both. If you approve by role, follow up with an Edit Tools save (even of the extras) to release the portal notice.

1. In the left sidebar, select Team (/team).
2. Look in the Active Members list — the self-registered person appears there as an ordinary row: Member role badge, green Active dot, and a tool label of "1 tools". That "1 tools" label is the pending marker, and your only visual cue that they are pending. (They will not appear under Pending Invites — they were never invited — and the card's description about members who have "accepted their invite" does not quite fit self-registered rows. They still belong in this list.)
3. Select Edit Roles on their row and assign a role — or select Edit Tools to pick tools directly.
4. If you chose Edit Tools, the dialog opens looking empty — that is expected. Their one placeholder status tool is not part of the selectable catalog, so nothing appears ticked and the button initially reads "Save (1 tools)". Both are cosmetic.
5. In the Edit Tools dialog, select the tools to grant — use the quick actions (All Tools, Read Only, Write, Clear), narrow the list with the search box and connector chips and then use Select all shown / Deselect all shown (both stay disabled until something is actually filtering the list), tick a connector or category checkbox to take everything under it, or tick tools individually — then Save. Selecting everything normally saves as "All tools" (no restriction); Managing members has the exact rule, including the exception for anyone who holds a custom role.

Once a member holds a role, that same button is relabelled Edit Extras: their own tool list now holds only the extras you add on top of the role, and the row shows role name chips and a tool label starting with "Role tools". See Custom roles.

When approval takes effect

• Their AI tool: on its very next request. Tool permissions are re-read on every call — no re-login, no reconnect, no token refresh needed. Tell them to just ask their assistant to try again (or refresh the tool list).
• The portal: on their next page load or sign-in — and only on the Edit Tools path (or after Make Co-owner). A role-only grant leaves the Awaiting Approval notice up even though their AI tool already works; see above.

Roles and approval

Approval does not change their team role — they stay a Member. Promoting them (Make Administrator, Make Co-owner) is a separate action on the same row; see Managing members.

Make Co-owner (owner-only) counts as an implicit approval: it grants full management access and clears the member-level tool restriction, so connections they make by signing in resolve to every tool. A credential of theirs still applies its own tool list — one that carries its own custom roles serves only those roles' tools — and any role they hold stays assigned. Use it deliberately; see Co-owners and ownership.

Pitfalls to avoid

• Do not press Save with nothing selected. An untouched Save writes an empty list — exactly like Clear then Save — which moves them out of pending into a different blocked state ("No tools assigned", support code SJ-ACCESS-NO-TOOLS), changes the row label to "0 tools", and removes the "1 tools" pending cue for good. It does not approve them. If you opened the dialog to look rather than to grant, press Cancel. (A member who holds a role keeps that role's tools and stays working either way — an empty save just leaves them with no extras.)
• Do not re-invite them instead of assigning access. Sending a fresh invite from the Team page technically works, but the invite's permissions only apply at the person's next sign-in — until then they stay pending, and the invite sits unaccepted in Pending Invites. Edit Roles and Edit Tools are immediate; use those.

Denying a self-registered member

If the person should not have access at all, select Revoke Access on their row and confirm. This deactivates the membership and revokes every access path in one step — their AI-assistant credentials, sign-in authorizations, any per-user connector credentials, and portal access — effective on their next request. If they try to sign in again they are told access was revoked and to ask an admin for a new invite. See OIDC sessions and revoking AI access for the full effect.