Setting up members with their own connector credentials

Most connectors use one shared credential for the whole team. Five connectors — HaloPSA, NinjaOne, N-able N-central, Microsoft Azure, and Microsoft Graph — can instead identify each team member individually, so actions show up in the vendor's audit logs under the real person's name. This page is the team-admin checklist for getting a member connected with their own identity.

Why some connectors need a personal sign-in and others do not

The rule turns on what the shared credential actually is, and it is worth understanding before you plan a rollout:

• An organization API key or service credential is shared by design. When a connector is configured with an API key, a client id and secret, or another tenant-level credential, that one credential is the organization's. Every member uses it, and the vendor's audit trail names the organization rather than a person. Nothing per-user is needed.
• A credential created by signing in carries one person's identity. For a delegated connector, the "shared" credential is really the authorizing person's own access, with their permissions. StackJack will not run one member's tool calls under another person's sign-in, so a non-owner member is refused rather than falling back to it. They get their own sign-in instead, which is what this page sets up.
• Effective owners keep the fallback. The primary owner and co-owners can use the organization's shared sign-in without authorizing personally. Everyone else cannot.
• A few connectors have no personal remedy at all. Reddit Ads is the standing example: it is authorized once for the whole organization and has no per-member sign-in. A non-owner member refused there cannot fix it themselves — their card reads Owner Sign-in Only, and either an owner runs those tools or the member is made an owner.

The mechanics behind all of this, and which identity applies to which connection, are in Who can use which identity.

Admin checklist

Before a member can create a per-user connection, make sure:

1. The connector has an active subscription — any tier, including Free, as long as it's active.

2. The shared connector is already configured on the Connectors page — a connector card only appears in the member's personal sign-ins after an admin has connected it. For HaloPSA / NinjaOne specifically, it must be configured in OAuth (Authorization Code) mode; members piggyback on that app registration and never need its secret. For Microsoft Azure / Microsoft Graph there is nothing to configure — the app registration is StackJack's own, so the card appears on any active subscription and each member's sign-in is the whole credential.

3. The member holds at least one of that connector's tools. A connector card appears in a member's personal sign-ins when their effective tool access covers it.

   Effective access counts a custom role. StackJack resolves what a member holds as the union of two things: any custom roles assigned to them, plus the extras picked for them individually. Either source unlocks the card. A member whose HaloPSA or NinjaOne tools arrive only through a role can start the connection — you do not need to hand them a redundant extra to make the card appear. That matters most when roles arrive from Entra groups through Directory sync, because the role arrives on its own.

   Assign either on the Team page: Edit Roles for a role, and Edit Tools — labelled Edit Extras once the person holds a role — for individual tools (Managing members).

   If a member sees "Your administrator has not assigned you any connector tools yet", they hold no roles and no extras covering any subscribed connector. Give them either one.

What the member does

Point the member at the Connectors page and their Your personal sign-ins section (there's no separate My Connectors item in the sidebar any more). Connectors that run entirely on the team-wide shared credential don't get an action card there — they're rolled up into a single "these work automatically" line — so the only cards shown are the ones that need the member's own sign-in:

The five connectors, and how each personal connection is made

For HaloPSA, NinjaOne, Microsoft Azure and Microsoft Graph, the first time a member signs in to a connection they land on a one-time credentials page showing a personal MCP Client ID and Secret (displayed exactly once, for a few minutes). They should paste these into their AI tool right away — see Your personal connector sign-ins for the member-facing walkthrough. A later sign-in (Re-authorize or Reconnect) keeps that client, updates its tool list to the member's current tools, and shows no credentials page. If a member missed the page, they select Revoke my key on their own card (or you revoke their client under Member credentials on their row); their next sign-in then creates a new one.

For the Microsoft pair, treat the personal sign-in as required for a non-owner, not a preference. Because the organization's credential carries one person's delegated identity — their Azure role assignments and every delegated administrative role they hold across customer directories — a member without their own connection is refused rather than inheriting it. Each member's own sign-in is the whole credential, which is why there is no shared app for an admin to set up.

For N-central, the member selects Set JWT (or Update JWT) on the N-central card and enters the N-central Server URL and their personal User-API Token (JWT). This is a token the member pastes in, not a browser consent flow. StackJack validates the token when they save, so a bad or under-permissioned JWT is caught right away; once connected, a Test button on the card re-checks the credential any time. No separate MCP credential is minted for N-central.

Two notes about owners: a co-owner sees every connector card regardless of what their own tool assignment says, and the primary owner never gets the per-connector cards at all — their view of the section is the tool-catalog card only. So if you are the primary owner, you can't preview or test this flow from your own account; have a member or Administrator walk through it.

How team changes interact with per-user credentials

• Changing what a member holds — through Edit Roles, or through Edit Tools / Edit Extras — immediately changes which connectors they can see and use, including on existing connections. Both sources count: removing a role can take a connector card away just as removing an extra can.
• Revoking a member's access disables their per-user connector credentials in the same step as everything else (Managing members); reactivating restores them unless a credential was disabled for a separate reason.
• A member connecting before being approved: if a self-registered, pending member tries the per-user OAuth flow, it completes their sign-in but bounces with a "Connector Not Assigned" message — approve them and assign tools first (Approving self-registered members).