Skip to main content
Mark Green
New Member ⭐
January 30, 2026
Question

SSP - Allowing users to log tickets on behalf of another Caller (anyone in GAL)

  • January 30, 2026
  • 6 replies
  • 128 views

Hi All, 

One major issue we hit with logging items via the SSP is the ability for staff to log a ticket on behalf of another individual..  Sometimes this could be a PA for a Director, or a colleague logging an item for someone that isn’t able to get on the system.  

Currently if we open this up to members of the same Branch(Office) or team - it allows everyone to see all tickets logged/open for that Branch (Office) or Team.  This is a major security breach for us as tickets could relate to personal items such as Workplace Adjustments etc or questions logged about a direct line reports activity. 

We really need this sorting, ideally anyone should be able to log a ticket against any other user, unless we specifically set the Caller field in an SSP form to not allow the value to be edited. 

Anyone have any thoughts on this?  
 

This topic has been closed for replies.

6 replies

Benjamin
Employee
Benjamin
Employee
January 30, 2026

Common work arounds for this limitation in form designer functionality are:

  1. Use custom forms
  2. Use an optional search list (dropdown) and populate it with person data using a custom import
    • Import it for example like “John Doe (johnd@company.com)” 
      • after form submission, use an action sequence to set the caller of the ticket to the affected person in the free searchlist (or link them / share the ticket with them)
Mark GreenAuthor
New Member ⭐
January 30, 2026

Common work arounds for this limitation in form designer functionality are:

  1. Use custom forms
  2. Use an optional search list (dropdown) and populate it with person data using a custom import
    • Import it for example like “John Doe (johnd@company.com)” 
      • after form submission, use an action sequence to set the caller of the ticket to the affected person in the free searchlist (or link them / share the ticket with them)

That has been a consideration but to try and maintain a list when staff are in 000’s is not that easy and it is crazy where the ‘Caller’ field can already be made editable. 

We just need to find a way to cleanly split the ability to log as others from the view of other callers tickets. 

Benjamin
Employee
Benjamin
Employee
January 30, 2026

​@Mark Green ,

In that scenario you don't maintain that list manually, it's synchronized nightly (or multiple times a day) directly from the TOPdesk person table.

Emerson Pedro Gonçalves
Emerson Pedro Gonçalves
New Member ⭐⭐⭐⭐
January 30, 2026

Are you able to create an Action Sequence to change the caller after the ticket is created? The idea is to use an email field in the SSP form as a key to identify the actual requester.

ACTION SEQUENCE FLOW:

Ticket created → GET PERSONS the person using the email provided → PATCH INCIDENT updating caller.id with the returned ID.

This way, the person who submitted the ticket will not see the real requester’s details. If I understood the problem correctly, this should solve the security issue without losing the ability to create tickets on behalf of someone else. 

I’m assuming that all requesters already exist in TOPdesk and have either an email address or another unique identifier that can be used to find them.

    Thomas Pastoors
    Thomas Pastoors
    Explorer ⭐⭐
    February 3, 2026

    I don’t get it.

    Why isn’t this a functionality “out of the box”?

    If I would use custom forms, why should I consult a TOPdesk advisor when I expect to be able to set up the feature myself?

    Why can't I design the form myself to meet my requirements? This is not an unusual or new application scenario.

     

    Currently, we are getting around this by asking reporters to enter the email address of the relevant person. With an automated action triggered by the operator we look up to the associated mail and its user.

    Unfortunately, this only works to a limited extent as I cannot specify a syntax for the input field (in this case, email).

    Due to human error, the automated action does not always run reliably.

     

    If you digitise a poor process, you end up with a poor digital process!
    Benjamin
    Employee
    Benjamin
    Employee
    February 4, 2026

    I don’t get it.

    Why isn’t this a functionality “out of the box”?

     

    Fair point, it should be. The form designer currently only covers the use case of a manager requesting for their subordinates, not peers for each other.

     

     

    If I would use custom forms, why should I consult a TOPdesk advisor when I expect to be able to set up the feature myself?

    Why can't I design the form myself to meet my requirements? This is not an unusual or new application scenario.

     

    Technically you can. Maybe get in touch with us to discuss the details.

     

    Currently, we are getting around this by asking reporters to enter the email address of the relevant person. With an automated action triggered by the operator we look up to the associated mail and its user.

    Unfortunately, this only works to a limited extent as I cannot specify a syntax for the input field (in this case, email).

    Due to human error, the automated action does not always run reliably.

    Human error can be eliminated using a drop-down field instead of a text field. (Importing your persons into a free drop-down field nightly).

     

     

      Terms & ConditionsAccessibility statement