> ## Documentation Index
> Fetch the complete documentation index at: https://docs.guild.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Identity mapping

> Attribute webhook-started work to the organization member who started it, by mapping their Slack and GitHub accounts to their Guild user.

When a webhook starts an agent run, Guild knows the service's user — a Slack member id, a GitHub user id — but not who that is in your organization. An identity mapping ties the two together, so the run is attributed to that member rather than to whoever created the trigger.

Attribution decides who the run acts as: which member's credentials it can resolve, and the acting user recorded in the [audit log](/insights/audit-logs). See [Credentials](/platform/credentials#how-guild-chooses-a-credential) for the part that depends on who a run acts as.

Spend is not affected. A trigger's runs count toward its creator's [spend budget](/platform/workspaces#spend-budget) and [usage](/insights/usage) whether or not a mapping matches.

Mappings belong to an organization. Open **Access & setup > Identity mapping**; the page is admin-only.

## Add a mapping

Click **Add mapping** and fill in three fields.

| Field | What to enter |
| - | - |
| **Integration** | The integration's full name, owner included, as the audit log writes it — for example `guildai~slack`. |
| **Service user id** | The prefixed id the service uses, for example `slack:U09F7MV9XB3` or `github:14227368`. |
| **Guild member** | The member's Guild username. They must already belong to this organization. |

The service user id is the one Guild recorded, so the reliable way to get it is to copy it from a security event in the [audit log](/insights/audit-logs) for a run that service started.

Mapping the same service user again on the same integration replaces the earlier mapping rather than adding a second one, and sets it back to **Active** if it was inactive.

<Note>
  The member has to be in the organization when you save. Guild refuses a mapping to someone who is not, rather than storing one that could never resolve.
</Note>

## Import mappings from a CSV

Click **Import CSV** to add many at once, either by choosing a file or pasting the rows. Each row is three columns — integration, service user id, Guild username — and a header row is optional.

```csv theme={null}
guildai~slack,slack:U09F7MV9XB3,alice
guildai~github,github:14227368,bob
```

Guild shows how many rows it parsed before you commit them. An import fails as a whole, with nothing saved, if a row has the wrong number of columns, names an integration that doesn't exist or someone who isn't a member, or repeats a service user for the same integration. An import holds at most 1,000 rows.

## Review and retire mappings

The list shows one row per mapping:

| Column | Contents |
| - | - |
| **Service** | The integration the mapping covers |
| **Service user** | The prefixed service user id |
| **Guild user** | The member the run is attributed to |
| **Status** | **Active** or **Inactive** |

Only **Active** mappings are used. Switch a mapping to **Inactive** to stop attributing that service user without losing the record of who they were, and switch it back to resume.

## Slack mappings Guild adds for you

When a Slack user with no mapping starts a run, Guild may look up their email in Slack. If it matches exactly one member of the organization, Guild adds an **Active** mapping for them and attributes the run to that member. These mappings appear in the list like any other.

Guild looks up only Slack users with no mapping at all. To stop Guild from mapping someone, switch their mapping to **Inactive**; Guild leaves an inactive mapping alone.

## When a run is not attributed to a member

Guild falls back to the trigger's creator when no active mapping matches the service user and Guild can't add one. A trigger created by an API key has no creator to fall back to, so the run is attributed to no member at all.

A few events carry no person to attribute to and skip the creator fallback as well. A Slack message deletion is one: the event names no user, so a run it starts is attributed to the trigger rather than to anyone.

A mapping also stops applying when the member leaves the organization. Guild re-checks their standing on every run and ignores the mapping if they no longer belong, so removing someone from the organization withdraws the attribution without anyone having to delete the row.
