Account mapping
Attribute every inbound edit to the person who made it — explicit mappings first, a matching rule second, and a hold, never a guess, when neither answers.
An edit that arrives from Jira or GitHub was made by an account in that tool. For the change to stand as a Part 11 record, it has to be attributed to an individual here. Account mapping is where that is decided.
How an account is matched
- An explicit mapping wins. A mapping is a person’s assertion that this external account is this traceunified user, recorded with who made it and when. It is consulted first.
- Then a matching rule. Where no mapping exists, an account whose identifier is an email address is matched to the user holding that address. Service accounts are never matched this way.
- Otherwise, the edit is held. There is deliberately no fallback user. An edit recorded against the wrong person is a record naming somebody who did not make the change, so an unmatched account’s edits wait until someone maps it.
Clearing the queue
- Open Account mapping from the unattributed-edits figure in Activity.
- Review each unresolved external account, and the suggested user where one exists.
- Map the account to the right person.
Result Edits from that account are attributed to the person you chose, and it no longer appears in the queue.
Who can open it
Mapping decides who a Part 11 record names, so it is available to organisation administrators and quality managers.