Confidential Tickets

Confidential tickets

Added in 2.8.0 · Asked for in discussion #62 · Developer guide

Some tickets are nobody else's business. Someone emails HR about a diagnosis and asks what benefits they can claim. Someone asks how to raise a grievance, and the grievance is about their own manager. A ticket marked Confidential is kept from the requester's managers.

Why this exists now. Portal managers can see the tickets raised by the people they manage. Confidential had to exist first, so that on the day managers are switched on, the tickets that must never reach them are already marked.

---

What it does, and what it doesn't

• It keeps a ticket from the requester's managers. Exactly what a manager sees of one is set on System → Managers: nothing at all (the default, not even that a confidential ticket exists), only that it exists, or everything. See Portal managers.
• It does not hide the ticket from the service desk. Analysts see confidential tickets exactly as before. Who on the desk can see a ticket is still decided by teams, departments and companies.

---

Marking a ticket confidential

Analysts: set Sensitivity to Confidential in the ticket's properties, or on the new-ticket form. A confidential ticket shows:

• a red Confidential marker in the properties bar, even with the panel collapsed, so nobody works one without knowing;
• a padlock before its subject in the ticket list.

Requesters, in the self-service portal:

• turn on This is confidential when raising a ticket;
• or open one of their tickets and press Mark confidential.

They can make a ticket confidential, but never undo it. Only the service desk can make a ticket Normal again. Otherwise a requester could be talked into un-marking a grievance by the very manager it is about.

---

Tickets that become confidential on their own

The dangerous moment is before anyone has read the ticket. A grievance emailed to HR would otherwise sit unmarked until an analyst got to it. So a ticket becomes confidential automatically when:

When	Set up on
It arrives through a confidential mailbox, such as an HR mailbox	Tickets → Settings → Mailboxes → Tickets from this mailbox are confidential
It is in, or is moved into, a confidential department	Tickets → Settings → Departments → Tickets here are confidential
The requester turned on This is confidential	the portal
It is split from, or merged with, a confidential ticket	automatic

For an HR mailbox, use the mailbox setting. An emailed ticket arrives without a department, so the department setting can't protect it until somebody files it. The mailbox setting protects it the moment it lands.

Turning a department confidential also marks the tickets already in it. Those are exactly the tickets the setting is for. A message says how many were marked.

Every automatic change goes into the ticket's audit trail with its reason, for example Confidential - arrived through the HR inbox mailbox.

---

Nothing automatic ever makes a ticket Normal again

Moving a ticket out of HR leaves it confidential. Switching a department's setting off leaves its tickets confidential. Only a person choosing Normal on the ticket lowers it, and the audit trail records who.

The reasoning: marking something confidential by mistake costs nothing. Unmarking it by mistake can't be taken back once a manager has read it.

---

Keeping it inside FreeITSM

Confidential keeps a ticket from managers. It also keeps it from leaving FreeITSM - an AI provider, a Slack channel or a Jira project is somebody else's system.

Where it could go	What happens to a confidential ticket
AI features - the summary, Read it for me, reply clean-up, Ask AI, merge summaries, knowledge write-ups, WhatsApp/Slack channel summaries	Not sent. The feature says why instead. Tickets → Settings → General → Confidential tickets and AI can allow it (it is "never send" until changed).
AI that reads many tickets - problem root cause, suggested problems, knowledge gap analysis	Left out.
The war room bot	Still counted, but shown to the AI by number only - "Confidential ticket".
Webhooks, Slack, Teams (workflow Send webhook)	Always cut down to its number, status, priority, department and team; the subject reads "Confidential ticket", and the text and requester are not sent. Not a setting - a chat post cannot be taken back. The editor's Send test never uses a confidential ticket as its sample.
External trackers (Jira, Azure DevOps)	By hand: the escalation preview warns, and you must tick a box to say you mean it - the service desk may genuinely need a supplier's help. By a workflow: never - the action is skipped, and the run history says confidential.

| A workflow's Send email (3.0.0) | Sent only to the ticket's requester or to analysts. Any other address - a manager, a shared list, an outside contact - is skipped, and the run history says why. The requester already knows what they wrote, and confidential never restricts the service desk. | | Calendars (3.0.0) - tickets synced into Outlook or a CalDAV calendar, and the subscribe (.ics) link | The event shows the ticket number and "Confidential ticket", with its time, status and priority, so the day still reads as booked. The subject and the requester's name stay in FreeITSM. A scheduled ticket already in a calendar is updated as soon as it becomes confidential. |

Before 3.0.0 these last two were not covered: Send email went to whatever address the workflow named, and a synced calendar showed the ticket's subject.

Upgrading

Run System → Database Verification once. Until then, everything works as before, but choosing Confidential is refused with a message asking you to run Verification. FreeITSM will never quietly save a ticket as Normal that someone asked to be confidential.

REST API

GET /api/v1/tickets/{id} returns "sensitivity": "normal" or "confidential". Send sensitivity on create or update to set it. See REST API: Tickets.

---

See also

• Tickets
• Self-Service Portal
• Confidential tickets — Developer Guide