docs
Concepts

People, identities and mentions

How nima links people's Slack, Jira, Linear and Notion accounts to workspace members, and how that decides who it answers, messages and tags.

nima links each external account (a Slack user, a Jira account, a Linear user, a Notion user) to a member of your workspace. That link decides who nima answers, who it may message, and whether it can tag someone by name.

Linking Slack accounts by email is on for every workspace. Real @mentions in outbound messages are off until a workspace owner or admin turns on outbound messages (dispatchEnabled) and sets dispatch.mentionsEnabled to true, both with PATCH /organizations/settings from a signed-in owner or admin session, or ask the nima team. Linking Jira, Linear and Notion accounts by an admin is on for every workspace; matching them automatically needs outbound messages on. Outbound messages themselves are covered in Outbound actions.

nima acts for a person, never as one

nima runs every answer and action as a linked person: the asker for a Slack answer, the rule owner for a watch or a rule. It uses that person's permissions and attributes cost to them. nima itself is a service identity (the Slack app or bot, a Jira writer credential), never a stand-in for a human.

Outbound messages nima sends for someone say so. The footer on a Slack DM or channel post, or on a Jira, Linear, Notion or GitHub comment, reads nima, on behalf of <name>, followed by a short reference to the action. Approval cards and digest notices are signed plain nima.

Two people in the same Slack thread get separate conversations with nima, each run as that person.

Linking Slack accounts by email

nima links a Slack account to a workspace member when the email on the Slack profile matches a live member of the workspace. Slack is the only integration where nima links people automatically in every workspace, whether or not outbound messages are on. It does so at three moments:

WhenWhat happens
Installnima checks every Slack user in the workspace, skipping bots, deleted users and Slackbot.
A person joins Slack (team_join)nima checks that one new user.
On demandAn unlinked person mentions nima, sends it a direct message, or runs an admin command, and nima tries to link them then.

The on-demand link needs a Slack profile email and a nima account with that email that is a live member of the workspace. Otherwise the link fails, and nima answers the person with this notice: it only answers members of the workspace and could not match the Slack account to one. The fix is to sign in to nima with the email on the Slack profile, or ask an admin to invite the person.

Guests, including people from Slack Connect, whose Slack email does not match a live member get the same notice and are not answered. nima sends the notice only in reply to a mention or a direct message; a follow-up in a thread from someone it cannot link is ignored.

Linking Jira, Linear and Notion accounts

nima links Jira, Linear and Notion accounts to members by email as well, looking the email up through the integration. There are three ways an account ends up linked.

  • Email auto-match. When nima sees a Jira account on an event, such as an assignee or reporter, it links the account if its email matches a live member. When nima needs to mention a member in Jira, Linear or Notion, it looks up that member's email in the tool and links the account it finds. Both give low assurance. Both kinds of auto-match happen only once outbound messages are on for the workspace. Matching Jira accounts seen on events needs dispatchEnabled, and the lookup for a mention also needs dispatch.mentionsEnabled. With both off, which is the default, only admin links and self links create links.
  • Admin link. An owner or admin links any account to any member with the link_external_identity tool (POST /v1/identities/link). This has high assurance.
  • Self link. A member links their own account with the link_my_identity tool (POST /v1/identities/link-me). The link applies only when the account's email matches the member's nima email. Otherwise nima records a pending claim, and an admin resolves it with link_external_identity. A member cannot take an account another member already holds, or one another member has a pending claim on (409).

The self-link tool also accepts a signed link token as proof, but nima does not issue link tokens yet. In practice a self link works by email match or becomes a pending claim.

GitHub has no identity linking. nima writes GitHub people as plain names.

Admin linking and the unlinked list need an integrations:write key, which a workspace owner or admin gets in Slack with /nima mcp-key integrations. Self linking needs identities:write, which nobody can mint yet, so ask an owner or admin to link the account. Slack linking by email needs none of this. See Outbound tools and Scopes.

Identity assurance: high and low

Every link carries an assurance level, high or low, and the level decides how far nima trusts the person.

AssuranceHow a link gets it
highAn admin link, or a Slack account linked by email match at install, on team_join or on demand.
lowAn account matched by email: a Jira, Linear or Notion account, or a Slack account nima looks up by a member's email while resolving a mention. Also a proven self link.

A low-assurance identity may receive nudges. It never raises how much nima does without asking, never grants read access, and does not count as a member when nima looks for someone to approve a message. A message that involves a low-assurance identity always waits for approval. Approvals and permission levels are in Outbound actions.

Mentions in outbound messages

nima can tag only people in the message's envelope: each by a handle: asker, assignee, reporter, spec_owner, and named_member (a member the asker named with an @ in Slack). The model writes a handle such as assignee, never an account id. nima resolves the handle to the person's linked account, for example a Slack <@U...> mention or an Atlassian account id. Raw mentions the model writes, and Slack broadcasts such as @here and @channel, are stripped.

Real mentions need dispatch.mentionsEnabled, which is false by default. With it off, or when the person has no linked account, nima writes their plain display name and adds a note for the approver, such as "The assignee is not linked to the tracker; shown as plain text." Nobody is pinged.

Non-members are never messaged

nima never messages or tags someone who is not a live member of the workspace. It refuses a direct message to a non-member or an unlinked person, and a rule that fires for one records no_recipient, and the rule owner's digest gets one line saying so. If the rule's recipient fallback is owner, the rule owner gets the message instead of that digest line. An unlinked assignee never receives the message.

Finding and fixing unlinked people

An owner or admin finds unlinked accounts with list_unlinked_identities (GET /v1/identities/unlinked, integrations:write key) and fixes each with link_external_identity. The list holds pending self claims, plus Jira accounts nima has seen on events while outbound messages are on for the workspace, newest first; a pending claim shows who made it. It returns ids and display names, never emails.

Use it when a rule fire or an approval card reports that someone is not linked. The tool parameters are on Outbound tools.

On this page