Ticket Notes

Ticket notes: internal or shared

A note on a ticket is either a private remark between colleagues, or something the person who raised the ticket can read. FreeITSM now says which, on every note, and a shared note can carry files and — if you want it to — send an email.

---

The two kinds

When you add a note, there is a tickbox: Share this with the requester.

	Who sees it	Where
Internal (the default)	Only your colleagues	The ticket, in FreeITSM
Shared	The requester as well	The self-service portal, and their email if you have set that up

A note is internal unless you deliberately say otherwise. Leaving the box untouched is always the safe answer, and the box resets to unticked every time you open it — so a note can never inherit "shared" from the last one you wrote.

---

You can now see which is which

Reading a ticket back, each note carries a small label:

• Internal — quiet and grey. This is the ordinary case, so it does not shout.
• Visible to requester — green, with a green edge down the side of the note.

Both are labelled, not just the unusual one. If only shared notes were marked, then no label would have to mean internal by implication — and you would be relying on an absence to tell you something important.

Why not the red border other systems use? Because in FreeITSM internal is the normal case and the majority. Colouring the majority red makes an ordinary ticket read as a wall of alarms, and red here is reserved for things that are actually wrong. A colleague writing a private remark is not one of them. So the eye is drawn to the note that left the building instead.

A note imported from an external issue tracker carries no visibility label, because it is not ours to describe as either.

---

Files on a shared note

Attach whatever you like and share the note: the requester gets the note and the files, in the portal, alongside any email attachments already on the ticket.

This used not to work. Attaching a file meant the note had to stay internal, and the Attach button disappeared the moment you ticked Share. The portal had no way to hand a document back, so offering one would have promised something never delivered. It can now, so the restriction is gone rather than merely better explained.

A file on an internal note stays invisible to the requester — and not merely hidden from a list. The rule sits inside the same database lookup that decides who owns the ticket, so an internal note's files cannot be reached by guessing an address either.

---

Emailing a shared note

Sharing a note puts it in the portal. It does not email anybody by default — which matters if your requesters email you and never sign in to a portal, because then nothing reaches them at all.

To change that, go to Tickets → Settings → Email templates and add a template against the trigger Note shared with requester.

• Nothing is sent until you write one. No template, no email. An existing installation carries on exactly as before.
• The template decides how much it says. Include [note_text] and the email carries the note itself. Leave it out and it simply says there is an update, with [ticket_url] for them to go and read it.
• An internal note never triggers anything. That is why the trigger is called Note shared with requester rather than Note added — you should not have to know a hidden rule to predict what a setting does.
• Files are not emailed. The portal link reaches them.

Which to use: a note, or Reply?

You want to…	Use
Write to the customer	Reply — it composes and sends an email
Record something for colleagues	Note, left internal
Put something on the ticket the customer may read	Note, shared
…and have them told about it	Note, shared, plus the email template above

---

Related pages

• Tickets
• Self-Service Portal
• Email template sender rules — deciding which template applies to whom
• Attached documents
• Ticket notes — developer guide