Skip to main content
New Member ⭐⭐⭐
October 13, 2026
Question

Confidential tickets per operator, not per group.

We’re trying to enforce confidentiality at an individual operator level in TOPdesk, rather than at operator-group level.

We have already explored operator filters, including keeping sensitive areas such as HR within a filtered group and creating partial calls where another team needs to be involved.

The problem is that this becomes too restrictive. Once operators are separated using filters, normal 1-to-1 communication and collaboration with operators outside that filtered group is affected. While this protects the confidential tickets, it also creates barriers to everyday cross-team working.

Essentially, we’re trying to achieve:

  • A ticket can be assigned to an individual operator and remain confidential to that operator.
  • Other members of their operator group should not automatically gain visibility of that ticket.
  • The operator should still be able to communicate and collaborate normally with operators across other groups.
  • We want to avoid creating individual or dedicated operator groups for every person who may need to handle confidential tickets, as this would quickly become difficult to manage.

Operator filtering feels like using a very broad control to solve a much more specific problem. If we start filtering everyone simply to provide individual confidentiality, we eventually reach the point of: “And when everyone’s super… no one will be.”

Has anyone found a clean, scalable way of achieving ticket-level or individual-operator confidentiality in TOPdesk without restricting normal collaboration between operators?

Alternatively, is a "visible only to selected operator(s)" type of functionality something that already exists, or something others would find useful as a feature request?

2 replies

ArjanH
Contributor
October 14, 2026

​I completely understand the need for strict confidentiality, but what happens during illness, holidays, or unexpected absence? If only a single operator can access a ticket, work simply stops, creating a major single point of failure.


​Personally, I would opt for smaller operator groups (pairs or teams of three) who share visibility. This preserves confidentiality while ensuring business continuity and coverage.


​It’s also worth looking at what the GDPR actually requires here:
​Confidentiality vs. Availability (Art. 32 GDPR): While the Need-to-Know principle means restricting access, GDPR explicitly requires organizations to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems. If critical personal data becomes inaccessible because an individual is off sick, availability is compromised.
​Accountability & Access Control: Restricting access to a vetted, minimal group (e.g., 2–3 HR/confidential specialists bound by explicit NDAs/confidentiality clauses) fully satisfies the principle of data minimization and purpose limitation without crippling day-to-day operations.


​A micro-group setup is usually far more sustainable and audit-proof than absolute individual isolation.

Translate
Functioneel beheerder & AI‑specialist — 80% mens, 20% autocomplete.
Thomas Pastoors
Explorer ⭐⭐⭐
October 15, 2026

Hi Mahmed,

as we use TOPdesk as our ESM tool, we have a very similar scenario. We have resolved this using the operator filters, so that there are several filters for each operator, which reflect the scope of collaboration between the respective teams. A single filter cannot achieve this on its own, but several working together have worked quite well for us so far.

To be honest an as ​@ArjanH wrote before:

There needs to be a different level of confidentiality within a team than there is across disciplines. Otherwise, in my humble opinion, you end up with knowledge silos and one-way communication channels, which, in the event of absences, risk causing dissatisfaction. At any rate, that would be the case in our scenario.

Best regards

Thomas

Translate
If you digitise a poor process, you end up with a poor digital process!