Skip to main content
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. See Credentials 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 and 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. 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 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.
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.

​
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.
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: 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.