Evidence linking

Flow Relay already receives the activity of your connected tools. When a piece of that activity names a work item key – FR-12 in a commit message, a branch called fr-12-refund-flow, a pull request titled "FR-12 switch the invoice webhook" – Flow Relay links it to the item as evidence. The item then shows the work that actually happened on it, next to the status someone set by hand.

Linking is deterministic: an exact key, in a place where people write keys on purpose. No AI decides what belongs to which item. Everything else Flow Relay notices – a merged pull request, a deploy, a piece of work that names no key – arrives as a suggestion that a person accepts or dismisses.

Never read: code diffs, repository and board snapshots and anything posted by a bot (GitHub Apps, Slack and Discord bots). The first 4,000 characters of a message are scanned.

A key matches when it stands on its own and is written in capitals or in lowercase: FR-12, fr-12 and [FR-12] all name item 12, while FR-120 names item 120 and Fr-12 or FR-12-3 name nothing. Only the keys of the projects that could receive the event count, so UTF-8, SHA-256 or ISO-8601 never match anything unless a project happens to use that key.

Three more kinds of key point at an item:

• A former project key. Renaming the project key keeps the old one as an alias, so the branches and commits written before the rename still link.
• A tracker key. An item mirrored from Jira or Linear answers to the key the tracker gave it (PAY-123), linked with the origin external_mapping.
• A GitHub issue number. #42 in a commit or pull request of acme/web links to the mirrored GitHub issue acme/web#42.

An event reaches a project only when the project binds the resource it came from – the repository, channel, board or workspace connected to the project – and the key belongs to that project. A commit in a repository that is not connected to a project is never linked to that project's items, even when it names one of its keys: that would show the repository's activity to people who have no access to it.

When several people connect the same workspace (a GitHub installation, a Slack team), every project that binds the resource is considered, whichever connection delivered the event.

• Personal projects: on by default. Turn it off in Plan settings > Evidence > Link activity.
• Organization projects: an organization admin schedules the Evidence linking policy in the organization page. Every member receives a notice in the app and by email, and linking starts 24 hours later – never before. Turning the policy off is immediate. Each project can still opt out in its own plan settings.

Every member can see which policies are on, since when and what the notice said in Settings > Work visibility.

Linked activity can propose a status, never set one:

A deploy that ships a linked commit also adds a deploy entry to the item, so the trail shows when the work reached users. Deploys are recognized from GitHub deployments, GitLab, Vercel and Netlify, which report the commit they shipped.

A suggestion only ever moves an item forward, never touches a mirrored item (its tracker owns the status) and never repeats while the same one is pending. It goes first to the person assigned to the item, in their inbox and in the item panel. After three working days without a decision, project managers see it too, as a Proposed flag on the item. Accepting applies the change with the permissions of the person who accepts.

With Link activity set to "Item keys and suggested matches" (Starter plans and above), work that names no key is compared with the open items of the project. When one is a close match, the activity is suggested as evidence for it:

• Only work-bearing sources take part: code hosts, issue trackers, CI builds and incidents. Chat, email and meetings are never suggested.
• The suggestion goes to the person who did the work, when their account is linked and they can open the project. Nobody else sees it. When the work has no linked author, project managers see the suggestion instead.
• A suggestion is never accepted on its own. Accepting it links the activity like a key would; dismissing it removes it.
• Organizations need the Suggested evidence policy, scheduled with the same 24-hour notice.

Evidence names who did the work only through a linked account – never by matching a display name or an email address:

• Connecting your own GitHub, GitLab, Jira, Linear, Slack or other account links it to you automatically.
• An organization admin can propose a link in Member accounts on the organization page, and the member confirms it. A member can claim an account in Settings > Work visibility > Claim an account, and an admin confirms it. Nobody links activity to someone else alone.
• Every link is listed in Settings > Work visibility > Accounts linked to you. Disputing one removes the name from every item at once.

In organizations, the evidence of an item shows its author only when the Named authors on linked activity policy is on; otherwise it stays anonymous. Either way, nobody gets a list of the activity of a person.

Nudge about quiet items after (3, 5 or 10 working days) watches items that are In progress with no linked activity. The assignee gets a nudge first. Three working days later, project managers see the item flagged as Quiet – a fact about the item, not a score for anyone.

Fathom and Fireflies write the action items of a meeting into its summary. When such a transcript reaches a project through a meeting rule, each action item becomes a new item suggestion for the project, with the meeting named as its origin. A project member accepts one to create the item or dismisses it. Nobody is assigned: the suggestion carries the text of the action item, not a decision about who does it.

The Linked activity tab of the item panel lists the evidence with its source, kind, title, time, author (when allowed) and a link back to the tool, plus the handoffs and insights that cite it. A summary item shows the evidence of every item below it. Export trail downloads the whole trail of the item as Markdown or CSV. Bars in the timeline and cards on the board show how much evidence an item has.

You can also link work by hand from the same tab: search your own activity of the last 90 days in the resources connected to the project, or paste any https link through the API or the link_evidence MCP tool.

Evidence keeps its own record – source, kind, reference, title, link and time – so the trail survives when the original event is removed: a disconnected integration, a source purge or the 90-day cleanup of untracked events. An event that is linked to an item is also treated as referenced by those cleanups, like an event cited by a handoff, and is kept.

• GET /projects/{id}/work-items/{ref}/evidence and POST on the same path read and add evidence; GET /projects/{id}/suggestions and POST /projects/{id}/suggestions/{suggestionId} list and decide suggestions. See the API reference.
• The MCP tools list_suggestions and link_evidence do the same from an agent. See MCP server.

• Start work from the VS Code extension: Start Work Item names the branch after the item, so every commit on it is linked without typing the key, and the status bar shows the item while the branch is checked out.
• Put the key in the pull request title. Squash merges keep the title, so the merge commit is linked too.
• Pick Suggest done when to match how your team ships: "A pull request merges" for libraries, "A deploy ships it" for services.