Work A Ticket
This page covers the ticket screen: reading the ticket, writing a comment with the right audience, and handling files.
Before you start
- Open a ticket from the Agent Queue or a ticket link.
- You need Work access to the ticket's department to comment, upload, edit, or delete. View access lets you read only. If the ticket opens but the controls are missing, you have View and not Work.
- Decide before you write whether the message is for the requester or for colleagues.
Read the ticket
- Read the title, the current status, and the service-level agreement (SLA) signal.
- Read Current handling for who owns the ticket and who else is on it.
- Read What the requester submitted before asking for something already there.
- Read the Attachments in the request. Then open the Comments and History tabs.
- Read Project association if the ticket may be part of project work. Linking or clearing it is a separate action. It does not assign an owner, add a watcher, or change the workflow.
Public update or internal note
The comment box has a Visibility setting with two choices. It normally opens on Public update, but if the product offers back an unsent draft it opens on the visibility that draft was saved with. Check it every time rather than trusting the default.
Public update — the requester can read it. It can also be included in what external participants on the ticket see, and it can be included in email the product sends about the ticket. Not every public update sends an email. Anything you write here should be safe for the requester to read.
Internal note — the requester cannot read it. It is not sent to external participants and is not part of what the requester sees. Only internal colleagues who already have access to the ticket can read it.
Only a public update stops the first-response SLA clock. An Internal note does not mark the first-response target as met, so the countdown carries on after a private triage note. That is intended — the target measures whether the requester has been answered, not whether the ticket was picked up. If you triage privately and move on, the ticket stays on the first-response clock and will still warn and breach. See Service-level agreements.
Neither choice gives anyone access to the ticket who did not already have it. Nothing else on the screen changes who can see what.
- In Add comment, write the message.
- Check Visibility and set it deliberately.
- If you add rich text or an inline image, check that it contains nothing that should stay internal. A public update cannot safely point at an internal-only image.
- Post once.
- Check that the comment appears with the visibility label you chose.
Correcting a comment
- The product may offer back an unsent draft. Re-read both the text and its visibility before posting it.
- You can edit your own comment for 15 minutes after posting. After that, the edit control is gone. Check the result rather than assuming the edit saved.
- Editing does not erase anything, and editing a public update is not discreet. The product keeps the version from before your edit and shows it to anyone who can read the comment. On a public update, that includes the requester: they see both what you wrote first and what you changed it to.
- Only the one version immediately before your latest edit is kept and shown. If you edit the same comment three times, only the third edit's before-and-after is available; the first two are no longer reachable. Do not rely on the history to reconstruct a sequence of edits.
- An edited comment is marked Edited, with the time of the edit shown alongside the original recorded time. A toggle reading View changes — Hide changes once open — shows the comparison, labelled EARLIER VERSION and CURRENT VERSION.
- The comparison outlives the edit window. Once the 15 minutes pass the Edit control disappears, but View changes stays, and anyone who can read the comment can still see what it said before.
- If the edit window has closed, post a new comment that corrects the earlier one, with the right visibility. Do not try to rewrite the history.
- If you posted internal information as a public update, stop and follow your organisation's incident process. Do not tell anyone the comment can be recalled or erased.
Add a file
- In Attachments, choose a file of 10 megabytes (MB) or less. The ticket's active files must total 50 MB or less afterwards.
- Decide whether to turn on Mark this file safe for external participants on this ticket.
- Upload once.
- Check the badge on the file:
- Shared externally — external participants who already have access to the ticket can see it.
- Internal only — they cannot.
- Check the file name and size.
The product checks the size, the file type, and the contents. A file under 10 MB with an allowed extension can still be rejected.
Remove a file
- Check that the file is one an agent uploaded during work on the ticket.
- Select the delete control once.
- Check the result and refresh the file list.
You cannot routinely delete a file uploaded by a requester, a participant, or an external participant. The product treats those as evidence submitted to the ticket and refuses agent deletion of them. If you cannot tell who uploaded a file, leave it and ask the person who handles records for your organisation.
Deleting an agent file removes it from the ticket. It does not erase the stored copy. Colleagues with the right access can still see removed files in the ticket history. Requesters and external participants see active files only.
Redaction, and revealing an original after redaction, are administrator tasks. They are not part of working a ticket.
If it does not work
- You set the wrong visibility. Fix it before you post.
- A post or upload returns an unclear result. Refresh the ticket and look for the record before trying again.
- A file is rejected. Fix the size, type, or content problem the product reports. Do not rename the file to get past the check.
- Deletion is refused, or you cannot tell where a file came from. Leave it alone and escalate.