Redaction

Redacting ticket content hides it from ordinary presentation and changes how it is handled. This page covers the register of what has been redacted, and the two-person process for revealing one original item.

Redaction is not deletion

The original content stays in the database after redaction. What changes is that ordinary views, exports, and ticket history show a marker instead of the content, and the item becomes governed evidence.

If you need something gone rather than hidden, redaction is the wrong control.

What can be redacted

Four things, all of them ticket content:

a ticket description;
a ticket comment;
a ticket attachment; and
a ticket custom-field value.

Project descriptions, project custom-field values, and project history are not covered by this control.

A ticket being linked to a project gives nobody register or reveal authority. Customer Portal single sign-on (SSO) requesters cannot open either workspace; they continue to see the ordinary redacted view.

Review the register

Redaction Register at /admin/redactions needs SystemAdmin and a recent step-up.

Complete the step-up and open Redaction Register.
Filter by start and end date, ticket reference, target type, reason code, or who redacted it. Target type offers Ticket description, Ticket comment, Ticket attachment, and Ticket custom field — those four are the whole of what can be redacted.
Select Apply filters.
Read each entry. The register shows eight columns: Redacted, Ticket, Target, Reason, Evidence fingerprint, Actor, Audit, and Reveal. Between them they give you the target class, the reason code, the length in characters of the reason note if one was written, the retained length and fingerprint, who redacted it and when, and the link to the audit record.

A redaction carries at most one reason note. The register shows its length, never its text.
Export comma-separated values (CSV) or JSON Lines (JSONL) only into your approved private evidence location.

The register is metadata only. It never shows the original text, the filename, the custom-field value, or the body of a reason note. That is the point of it.

Reveal one original item

Reveal is exceptional. It needs two different people, and it produces one item — not access to the ticket, and not an undo of the redaction.

Before you start

An approved reason for exceptional use, and a private place to read the result.
One exact target identified: description, comment, attachment, or custom-field value.
A reason of 500 characters or fewer, written and ready.
A second approver who is not you. Preferably the owning department's manager of record; otherwise another active SystemAdmin. If nobody eligible exists, stop — you cannot self-approve.

Request

Find the exact redaction record in the register and select Break-glass.
Check the target preview and its retained fingerprint. If either is not the record you meant, stop here.
Select the Second approver.
Enter the Break-glass reason, 500 characters or fewer.
Acknowledge the exceptional-use warning.
Select Request reveal approval once. The request state becomes Pending.

Approve

The named approver does this, not the requester.

An approver who is not watching for it will not be told twice. Where a reveal is waiting on you, Approvals shows a cue with an Open redaction approvals link, so the ordinary approvals page an approver already visits leads to the reveal queue. That cue is the fallback for a notification that was suppressed, never configured, or simply missed — it is not a second notification, and it appears only while something is actually pending for you. If the ordinary approvals list is empty it says so separately, so an empty ticket queue is not mistaken for nothing to do.

Open Redaction Reveal Approvals at /redaction-reveal-approvals, or follow Open redaction approvals from Approvals.
Complete a current step-up, by credential or through the current single sign-on path.
Check the target fingerprint, who requested it, and the reason.
Acknowledge exceptional use and select Approve reveal once. The state becomes Approved.

Reveal

The requesting administrator does this.

Return to the approved request and complete a current step-up.
Select Reveal original evidence. For an attachment target, select Download original attachment evidence instead.
Read it only inside the approved private boundary.
Confirm the state is Revealed and stop. The approval is spent — it cannot be used again.

If the fingerprint no longer matches, the reveal is refused and nothing is disclosed. The same applies to a self-approval attempt, an expired step-up, or the wrong person attempting the final step.

Revealing does not unredact anything. The ordinary view of that ticket is exactly as it was before.

What to record

Record the target class, the state reached (Pending, Approved, or Revealed), whether the approver was distinct, and whether the reveal succeeded or was blocked.

Never record the original content, the reason text, the people involved, the identifiers, the fingerprint, the filename, or the notification content.

If it does not work

No eligible second approver exists. That is a stop condition, not an obstacle to route around. The requester cannot approve their own request.

The fingerprint does not match the record you expected. Stop. Something about the underlying content or the recovery point has changed. Find out what before requesting again.

The database was restored since the redaction was recorded. Check that the record, the retained attachment storage, and the fingerprint still describe the same recovery point before relying on any of them.

Revealed content went somewhere it should not have. Stop copying it and start your organization's evidence incident process.