Open from the JSM ticket
The issue panel gives admins a direct path from the service request into the evidence workspace.
Request Evidence Control docs
Build and review a JSM evidence pack.
Use Request Evidence Control when a JSM request needs a durable handoff: what was reviewed, what evidence was used, what could not be verified, and what was accepted.
ReceiptManifestSource statusCaveats preserved
Step-by-step workflow
Use this path when a Jira Service Management request needs proof that can still be understood after the ticket is closed.
- Open the JSM request.Start from the Jira Service Management ticket and open Request Evidence Control from the issue context when a request needs an evidence handoff.
- Open the case workspace.Select the request, such as Maya Chen's offboarding case, to move from the ticket context into the full review workspace.
- Review the evidence status.Check the current focus, confidence, blockers, source status, and the evidence groups that are included or still need review.
- Keep limitations visible.If historical group membership or another source is outside the collected records, leave that limitation attached to the case instead of treating missing proof as a clean result.
- Accept or resolve the handoff warning.When the reviewer accepts a constrained handoff, record the reason so the warning is preserved with the pack.
- Build and deliver the pack.Generate the review-ready pack and export or deliver the receipt, manifest, source status, checksum metadata, and caveats for later review.
Screenshots
How the workflow looks
These screenshots show the ticket entry point, evidence review, and pack delivery states.
Review proof and limitations
Evidence coverage, review status, and missing source limitations remain visible before handoff.
Deliver the evidence pack
The final pack keeps the receipt, manifest, source status, checksum metadata, and caveats together.
Evidence-pack contents
A review-ready pack keeps the record understandable after the ticket is closed.
Receipt
Who accepted the handoff, when it was accepted, and which warning or limitation was included. It keeps the next review step clear without overstating what the available record proves.
Manifest
Pack metadata, export identifiers, checksum metadata, generated timestamps, and delivery status. It keeps the next review step clear without overstating what the available record proves.
Source status
Which source records were included, unavailable, outside scope, or carried forward for review. It keeps the next review step clear without overstating what the available record proves.
Caveats
Warnings and limitations remain visible so the reviewer does not overstate what was proven. It keeps the next review step clear without overstating what the available record proves.
Recommended workflow
Open the JSM request, review evidence coverage, resolve or acknowledge blockers, build the pack, then export or deliver the review record with preserved caveats. Do not remove a warning unless the underlying evidence gap has actually been resolved.
Limitations
If historical group membership or another source is not available from collected records, keep that limitation in the handoff. The app should not turn missing evidence into a positive proof claim.
Related pages
Continue to the product page, security statement, or support page for Marketplace evaluation.