When a TestRail-class case repository files a ticket from a failed run, what is the difference between attaching the evidence bytes and pasting a deep link back to the run, and how does each fail?

Evidence can cross the boundary two ways. Copying the bytes puts the screenshot or log into the tracker item, where it is readable by everyone who can read the item, survives whatever happens to the run, and needs no second login — at the cost of duplicated storage, a size ceiling the tracker imposes, and a copy frozen at filing time. A deep link costs nothing to store and always points at the live run with all its surrounding context, but it only resolves for someone who can authenticate to the repository and is allowed to see that project. A developer who lives in the tracker and has no repository account gets a login wall, not a screenshot. The workable policy is usually both: attach the small decisive artefact so the ticket stands alone, link the bulk so the depth is reachable.

Evidence can cross the boundary two ways. **Copying the bytes** puts the screenshot or log into the tracker item, where it is readable by everyone who can read the item, survives whatever happens to the run, and needs no second login — at the cost of duplicated storage, a size ceiling the tracker imposes, and a copy frozen at filing time. **A deep link** costs nothing to store and always points at the live run with all its surrounding context, but it only resolves for someone who can authenticate to the repository and is allowed to see that project. A developer who lives in the tracker and has no repository account gets a login wall, not a screenshot. The workable policy is usually both: attach the small decisive artefact so the ticket stands alone, link the bulk so the depth is reachable.

Two products, one boundary

A failed execution in a case repository usually carries evidence: a screenshot, a console log, a video, a captured payload. The defect, however, is worked in a tracker, which is a different product with a different user list — even for Jira-resident tools such as Xray and Zephyr, the run detail and the issue view are different surfaces with different audiences. So the question every filing feature has to answer is: do the bytes cross, or does only a pointer cross?

Both are legitimate. They fail in opposite directions, which is why mature teams use both deliberately rather than picking one.

What an attached copy buys and costs

Buys:

A self-contained ticket. Anyone who can read the item can see the failure. No second product, no second login, no request for access.
Durability. The copy outlives the run. If the cycle is archived, cleaned up, or the project's evidence is pruned under a retention policy, the ticket still shows what was seen.
Offline reading. It appears in tracker notifications, exports and printed reports the way any other attachment does.

Costs:

Duplicate storage, in two products, forever.
A ceiling. Trackers cap how large a single attachment may be, so a long video or a full log bundle may simply not fit; the filing action then either truncates, skips, or silently degrades to a link.
A frozen snapshot. The copy is whatever existed at filing time. Re-running the case and capturing better evidence does not update the ticket.
A wider blast radius for anything sensitive. Case-repository projects are often narrow; tracker projects are often wide. A screenshot with production customer data or a log with a token crosses into a much larger readership the moment it is attached.

What a deep link buys and costs

Buys:

Context, not a fragment. The reader lands on the execution, and gets the other steps, the previous attempts in that cycle, the environment, and the executor — not just one image.
No duplication and no size ceiling. A gigabyte of captured artefacts costs the ticket a single line of text.
Freshness. If the run's evidence is added to, the link shows the newer state.

Costs:

It resolves only for an authenticated, authorised reader. The developer who was handed the ticket and does not have an account in the case repository sees a login page. This is the single most common failure of link-only filing: the evidence exists, and the person who has to fix the defect cannot see it.
It depends on the run continuing to exist and remaining reachable. Archived, cleaned-up or reorganised runs turn the ticket into a dead end long after anyone remembers what it pointed at.
It hides the cost of looking. A reviewer triaging a queue will not open a second product to judge whether an item is worth reading. Link-only tickets get skimmed and deprioritised because the ticket alone shows nothing.

	Attached bytes	Deep link
Readable without a repository account	yes	no
Survives the run being archived	yes	no
Size limits apply	yes, tracker-side	effectively no
Shows evidence added after filing	no	yes
Exposure of sensitive captures	widened to the tracker's readers	stays behind the repository's access rules

The policy that actually works

Attach the one artefact that makes the ticket judgeable on its own — usually the failing screenshot or the stack fragment. If a triager cannot decide from the item alone, the item will sit.
Link the bulk — the full run, the video, the archive of captured files — so depth is one click away for whoever needs it.
Assume the link's audience is smaller than the ticket's. If the fixer typically has no repository account, a link-only ticket is not evidence transfer; it is an access request in disguise.
Sanitise before crossing. Whatever is attached inherits the tracker item's readership, which is often far wider than the run's.
Say in the ticket what the link points at. "Full run, five screenshots and a video" tells a reader without access what they are missing and whether to go asking for it.

The tell in an interview

Candidates who have only configured a filing integration say "it attaches the screenshot". Candidates who have operated one say: the day a contractor with tracker access but no repository account picked up the defect, the link was worthless, and that is why the decisive artefact is copied even though the bytes are duplicated.

## Two products, one boundary A failed execution in a case repository usually carries evidence: a screenshot, a console log, a video, a captured payload. The defect, however, is worked in a **tracker**, which is a different product with a different user list — even for Jira-resident tools such as Xray and Zephyr, the run detail and the issue view are different surfaces with different audiences. So the question every filing feature has to answer is: **do the bytes cross, or does only a pointer cross?** Both are legitimate. They fail in opposite directions, which is why mature teams use both deliberately rather than picking one. ## What an attached copy buys and costs **Buys:** - **A self-contained ticket.** Anyone who can read the item can see the failure. No second product, no second login, no request for access. - **Durability.** The copy outlives the run. If the cycle is archived, cleaned up, or the project's evidence is pruned under a retention policy, the ticket still shows what was seen. - **Offline reading.** It appears in tracker notifications, exports and printed reports the way any other attachment does. **Costs:** - **Duplicate storage**, in two products, forever. - **A ceiling.** Trackers cap how large a single attachment may be, so a long video or a full log bundle may simply not fit; the filing action then either truncates, skips, or silently degrades to a link. - **A frozen snapshot.** The copy is whatever existed at filing time. Re-running the case and capturing better evidence does not update the ticket. - **A wider blast radius for anything sensitive.** Case-repository projects are often narrow; tracker projects are often wide. A screenshot with production customer data or a log with a token crosses into a much larger readership the moment it is attached. ## What a deep link buys and costs **Buys:** - **Context, not a fragment.** The reader lands on the execution, and gets the other steps, the previous attempts in that cycle, the environment, and the executor — not just one image. - **No duplication and no size ceiling.** A gigabyte of captured artefacts costs the ticket a single line of text. - **Freshness.** If the run's evidence is added to, the link shows the newer state. **Costs:** - **It resolves only for an authenticated, authorised reader.** The developer who was handed the ticket and does not have an account in the case repository sees a login page. This is the single most common failure of link-only filing: the evidence *exists*, and the person who has to fix the defect cannot see it. - **It depends on the run continuing to exist and remaining reachable.** Archived, cleaned-up or reorganised runs turn the ticket into a dead end long after anyone remembers what it pointed at. - **It hides the cost of looking.** A reviewer triaging a queue will not open a second product to judge whether an item is worth reading. Link-only tickets get skimmed and deprioritised because the ticket alone shows nothing. | | Attached bytes | Deep link | |---|---|---| | Readable without a repository account | yes | no | | Survives the run being archived | yes | no | | Size limits apply | yes, tracker-side | effectively no | | Shows evidence added after filing | no | yes | | Exposure of sensitive captures | widened to the tracker's readers | stays behind the repository's access rules | ## The policy that actually works 1. **Attach the one artefact that makes the ticket judgeable on its own** — usually the failing screenshot or the stack fragment. If a triager cannot decide from the item alone, the item will sit. 2. **Link the bulk** — the full run, the video, the archive of captured files — so depth is one click away for whoever needs it. 3. **Assume the link's audience is smaller than the ticket's.** If the fixer typically has no repository account, a link-only ticket is not evidence transfer; it is an access request in disguise. 4. **Sanitise before crossing.** Whatever is attached inherits the tracker item's readership, which is often far wider than the run's. 5. **Say in the ticket what the link points at.** "Full run, five screenshots and a video" tells a reader without access what they are missing and whether to go asking for it. ## The tell in an interview Candidates who have only configured a filing integration say "it attaches the screenshot". Candidates who have *operated* one say: the day a contractor with tracker access but no repository account picked up the defect, the link was worthless, and that is why the decisive artefact is copied even though the bytes are duplicated.

When a TestRail-class case repository files a ticket from a failed run, what is the difference between attaching the evidence bytes and pasting a deep link back to the run, and how does each fail?

answer

basics

solid answer

go deeper

Two products, one boundary

What an attached copy buys and costs

What a deep link buys and costs

The policy that actually works

The tell in an interview

Two products, one boundary

What an attached copy buys and costs

What a deep link buys and costs

The policy that actually works

The tell in an interview

When a TestRail-class case repository files a ticket from a failed run, what is the difference between attaching the evidence bytes and pasting a deep link back to the run, and how does each fail?

§ answer

basics

solid answer

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two products, one boundary

What an attached copy buys and costs

What a deep link buys and costs

The policy that actually works

The tell in an interview

▾common follow-ups2 questions

▾red flags5 flags

Two products, one boundary

What an attached copy buys and costs

What a deep link buys and costs

The policy that actually works

The tell in an interview

answer

go deeper